Files
ack-tegra/include/linux
Fengnan Chang 89e1fb7cef blk-mq: fix potential uaf for 'queue_hw_ctx'
This is just apply Kuai's patch in [1] with mirror changes.

blk_mq_realloc_hw_ctxs() will free the 'queue_hw_ctx'(e.g. undate
submit_queues through configfs for null_blk), while it might still be
used from other context(e.g. switch elevator to none):

t1					t2
elevator_switch
 blk_mq_unquiesce_queue
  blk_mq_run_hw_queues
   queue_for_each_hw_ctx
    // assembly code for hctx = (q)->queue_hw_ctx[i]
    mov    0x48(%rbp),%rdx -> read old queue_hw_ctx

					__blk_mq_update_nr_hw_queues
					 blk_mq_realloc_hw_ctxs
					  hctxs = q->queue_hw_ctx
					  q->queue_hw_ctx = new_hctxs
					  kfree(hctxs)
    movslq %ebx,%rax
    mov    (%rdx,%rax,8),%rdi ->uaf

This problem was found by code review, and I comfirmed that the concurrent
scenario do exist(specifically 'q->queue_hw_ctx' can be changed during
blk_mq_run_hw_queues()), however, the uaf problem hasn't been repoduced yet
without hacking the kernel.

Sicne the queue is freezed in __blk_mq_update_nr_hw_queues(), fix the
problem by protecting 'queue_hw_ctx' through rcu where it can be accessed
without grabbing 'q_usage_counter'.

[1] https://lore.kernel.org/all/20220225072053.2472431-1-yukuai3@huawei.com/

Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-11-28 09:09:19 -07:00
..
…
…
…
2025-09-24 17:09:47 +02:00
…
…
…
…
…
…
…
…
…
…
2025-06-15 21:19:08 +05:30
…
…
…
…
…
2025-09-05 15:06:03 +02:00
…
…
…
…
…
…
…
…
…
2025-07-21 18:18:51 +01:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-07-31 11:28:03 -04:00
2025-11-14 05:09:56 -07:00
…
…
…
…
…
…
…
…
2025-09-24 02:48:05 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-08-14 10:37:33 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-09-23 11:13:22 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-08-21 13:58:07 +02:00
…
2025-07-16 14:28:21 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-09-13 17:32:44 -07:00
…
…
…
…
…
2025-08-29 13:39:53 -07:00
…
…
…
…
…
…
…
…
…
…
2025-08-02 12:06:10 -07:00
…
…
…
…
…
…
…
…
…
2025-09-18 10:17:09 +02:00
…
…
…
…
…
…
…
2025-09-23 11:13:22 +02:00
…
…
…
…
…
…
…
…
…
2025-06-11 11:57:14 -07:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-07-02 17:18:01 +01:00
…
…
…
…
…
…
…
…
…
…
…
2025-07-17 06:01:16 -06:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-09-13 16:54:50 -07:00
…
…
…
…
…
2025-07-09 22:41:56 -07:00
…
2025-09-17 15:58:29 -04:00
…
…
…
…
2025-06-17 18:18:46 -07:00
…
…
…
…
…
…
…
…
…
…
…
2025-07-14 15:20:02 -07:00
2025-09-23 13:28:20 -04:00
…
…
…
…
2025-07-08 19:11:57 -04:00
…
2025-09-19 14:26:16 +02:00
2025-09-25 09:23:47 +02:00
…
…
…
…
…
…
…
…
2025-08-18 14:23:09 +02:00
2025-08-18 14:23:09 +02:00
…
…
…
…
…
…
…
…
2025-10-01 07:55:42 -05:00
…
…
…
…
…
…
…
…
…
…
2025-10-03 12:13:12 -05:00
…
…
…
2025-09-13 16:55:07 -07:00
…
2025-10-03 10:24:14 -07:00
2025-06-19 14:28:24 +02:00
2025-06-19 14:28:24 +02:00
…
…
…
…
…
2025-07-22 18:07:11 +02:00
…
…
…
2025-08-24 11:41:11 -06:00
…
2025-07-01 12:29:29 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-08-28 13:14:50 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-09-19 17:19:45 -07:00
…
…
…
…
…
…
…
…
2025-07-23 11:56:02 +02:00
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
…
2025-08-17 12:46:25 +02:00
…
…
…
2025-06-26 09:44:45 -07:00
…
…
2025-09-09 10:27:01 -06:00
…
…
…
…
…
…
…
2025-10-01 07:24:55 -04:00
…
…
…
…
…
…
…
…
2025-07-17 11:26:56 +02:00
…
…
…
…
…
2025-08-02 12:01:37 -07:00
…
…
…
…
…
…
…
…