From: Ming Lei ming.lei@redhat.com
commit d36a9ea5e7766961e753ee38d4c331bbe6ef659b upstream.
For blk-mq, queue release handler is usually called after blk_mq_freeze_queue_wait() returns. However, the q_usage_counter->release() handler may not be run yet at that time, so this can cause a use-after-free.
Fix the issue by moving percpu_ref_exit() into blk_free_queue_rcu(). Since ->release() is called with rcu read lock held, it is agreed that the race should be covered in caller per discussion from the two links.
Backport-notes: Not a clean cherry-pick since a lot has changed, however essentially the same fix.
Reported-by: Zhang Wensheng zhangwensheng@huaweicloud.com Reported-by: Zhong Jinghua zhongjinghua@huawei.com Link: https://lore.kernel.org/linux-block/Y5prfOjyyjQKUrtH@T590/T/#u Link: https://lore.kernel.org/lkml/Y4%2FmzMd4evRg9yDi@fedora/ Cc: Hillf Danton hdanton@sina.com Cc: Yu Kuai yukuai3@huawei.com Cc: Dennis Zhou dennis@kernel.org Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Signed-off-by: Ming Lei ming.lei@redhat.com Link: https://lore.kernel.org/r/20221215021629.74870-1-ming.lei@redhat.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Saranya Muruganandam saranyamohan@google.com --- block/blk-core.c | 2 -- block/blk-sysfs.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c index d0d0dd8151f7..e5eeec801f56 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -414,8 +414,6 @@ void blk_cleanup_queue(struct request_queue *q) blk_mq_sched_free_requests(q); mutex_unlock(&q->sysfs_lock);
- percpu_ref_exit(&q->q_usage_counter); - /* @q is and will stay empty, shutdown and put */ blk_put_queue(q); } diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 8c5816364dd1..9174137a913c 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -726,6 +726,8 @@ static void blk_free_queue_rcu(struct rcu_head *rcu_head) { struct request_queue *q = container_of(rcu_head, struct request_queue, rcu_head); + + percpu_ref_exit(&q->q_usage_counter); kmem_cache_free(blk_requestq_cachep, q); }
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html/#opt...
Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree. Subject: [PATCH] block: fix use-after-free of q->q_usage_counter Link: https://lore.kernel.org/stable/20230921182012.3965572-1-saranyamohan%40googl...
On Thu, Sep 21, 2023 at 11:20:12AM -0700, Saranya Muruganandam wrote:
From: Ming Lei ming.lei@redhat.com
commit d36a9ea5e7766961e753ee38d4c331bbe6ef659b upstream.
For blk-mq, queue release handler is usually called after blk_mq_freeze_queue_wait() returns. However, the q_usage_counter->release() handler may not be run yet at that time, so this can cause a use-after-free.
Fix the issue by moving percpu_ref_exit() into blk_free_queue_rcu(). Since ->release() is called with rcu read lock held, it is agreed that the race should be covered in caller per discussion from the two links.
Backport-notes: Not a clean cherry-pick since a lot has changed, however essentially the same fix.
Reported-by: Zhang Wensheng zhangwensheng@huaweicloud.com Reported-by: Zhong Jinghua zhongjinghua@huawei.com Link: https://lore.kernel.org/linux-block/Y5prfOjyyjQKUrtH@T590/T/#u Link: https://lore.kernel.org/lkml/Y4%2FmzMd4evRg9yDi@fedora/ Cc: Hillf Danton hdanton@sina.com Cc: Yu Kuai yukuai3@huawei.com Cc: Dennis Zhou dennis@kernel.org Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Signed-off-by: Ming Lei ming.lei@redhat.com Link: https://lore.kernel.org/r/20221215021629.74870-1-ming.lei@redhat.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Saranya Muruganandam saranyamohan@google.com
block/blk-core.c | 2 -- block/blk-sysfs.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c index d0d0dd8151f7..e5eeec801f56 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -414,8 +414,6 @@ void blk_cleanup_queue(struct request_queue *q) blk_mq_sched_free_requests(q); mutex_unlock(&q->sysfs_lock);
- percpu_ref_exit(&q->q_usage_counter);
- /* @q is and will stay empty, shutdown and put */ blk_put_queue(q);
} diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 8c5816364dd1..9174137a913c 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -726,6 +726,8 @@ static void blk_free_queue_rcu(struct rcu_head *rcu_head) { struct request_queue *q = container_of(rcu_head, struct request_queue, rcu_head);
- percpu_ref_exit(&q->q_usage_counter); kmem_cache_free(blk_requestq_cachep, q);
}
Looks fine.
BTW, you should have provided target stable tree release info, otherwise how you expect people to review?
Thanks, Ming
On Thu, Sep 21, 2023 at 11:20:12AM -0700, Saranya Muruganandam wrote:
From: Ming Lei ming.lei@redhat.com
commit d36a9ea5e7766961e753ee38d4c331bbe6ef659b upstream.
For blk-mq, queue release handler is usually called after blk_mq_freeze_queue_wait() returns. However, the q_usage_counter->release() handler may not be run yet at that time, so this can cause a use-after-free.
Fix the issue by moving percpu_ref_exit() into blk_free_queue_rcu(). Since ->release() is called with rcu read lock held, it is agreed that the race should be covered in caller per discussion from the two links.
Backport-notes: Not a clean cherry-pick since a lot has changed, however essentially the same fix.
Reported-by: Zhang Wensheng zhangwensheng@huaweicloud.com Reported-by: Zhong Jinghua zhongjinghua@huawei.com Link: https://lore.kernel.org/linux-block/Y5prfOjyyjQKUrtH@T590/T/#u Link: https://lore.kernel.org/lkml/Y4%2FmzMd4evRg9yDi@fedora/ Cc: Hillf Danton hdanton@sina.com Cc: Yu Kuai yukuai3@huawei.com Cc: Dennis Zhou dennis@kernel.org Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Signed-off-by: Ming Lei ming.lei@redhat.com Link: https://lore.kernel.org/r/20221215021629.74870-1-ming.lei@redhat.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Saranya Muruganandam saranyamohan@google.com
block/blk-core.c | 2 -- block/blk-sysfs.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-)
What stable kernel(s) are you expecting this backport to be applied to?
thanks,
greg "not a mind reader" k-h
Apologies for leaving out the stable release info. This is for both 5.10 and patch applies cleanly for 5.15.
I just sent out a (different) modified patch for 6.1 LTS.
On Fri, Sep 22, 2023 at 2:26 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Sep 21, 2023 at 11:20:12AM -0700, Saranya Muruganandam wrote:
From: Ming Lei ming.lei@redhat.com
commit d36a9ea5e7766961e753ee38d4c331bbe6ef659b upstream.
For blk-mq, queue release handler is usually called after blk_mq_freeze_queue_wait() returns. However, the q_usage_counter->release() handler may not be run yet at that time, so this can cause a use-after-free.
Fix the issue by moving percpu_ref_exit() into blk_free_queue_rcu(). Since ->release() is called with rcu read lock held, it is agreed that the race should be covered in caller per discussion from the two links.
Backport-notes: Not a clean cherry-pick since a lot has changed, however essentially the same fix.
Reported-by: Zhang Wensheng zhangwensheng@huaweicloud.com Reported-by: Zhong Jinghua zhongjinghua@huawei.com Link: https://lore.kernel.org/linux-block/Y5prfOjyyjQKUrtH@T590/T/#u Link: https://lore.kernel.org/lkml/Y4%2FmzMd4evRg9yDi@fedora/ Cc: Hillf Danton hdanton@sina.com Cc: Yu Kuai yukuai3@huawei.com Cc: Dennis Zhou dennis@kernel.org Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Signed-off-by: Ming Lei ming.lei@redhat.com Link: https://lore.kernel.org/r/20221215021629.74870-1-ming.lei@redhat.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Saranya Muruganandam saranyamohan@google.com
block/blk-core.c | 2 -- block/blk-sysfs.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-)
What stable kernel(s) are you expecting this backport to be applied to?
thanks,
greg "not a mind reader" k-h
On Fri, Sep 22, 2023 at 11:21:10AM -0700, Saranya Muruganandam wrote:
Apologies for leaving out the stable release info. This is for both 5.10 and patch applies cleanly for 5.15.
I just sent out a (different) modified patch for 6.1 LTS.
All now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
kernel test robot -
Ming Lei -
Saranya Muruganandam