CVE-2024-47706

In the Linux kernel, the following vulnerability has been resolved:

block, bfq: fix possible UAF for bfqq->bic with merge chain

1. initial state, three tasks:

    Process 1       Process 2	Process 3
     (BIC1)          (BIC2)		 (BIC3)
      |  Λ            |  Λ		  |  Λ
      |  |            |  |		  |  |
      V  |            V  |		  V  |
      bfqq1           bfqq2		  bfqq3
   

process ref: 1 1 1

2. bfqq1 merged to bfqq2:

    Process 1       Process 2	Process 3
     (BIC1)          (BIC2)		 (BIC3)
      |               |		  |  Λ
      \--------------\|		  |  |
                      V		  V  |
      bfqq1--------->bfqq2		  bfqq3
   

process ref: 0 2 1

3. bfqq2 merged to bfqq3:

    Process 1       Process 2	Process 3
     (BIC1)          (BIC2)		 (BIC3)
   

   here -> Λ | | --------------\ -------------| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3

In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1.

bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2

__bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3

Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible):

================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in...