Hi
在 2022/12/08 17:37, Jan Kara 写道:
So if this state happens, it would be indeed a problem. But I don't see how
it could happen. bics are associated with the process. So t1 will always
use bic1, t2 will always use bic2. In bfq_init_rq() we get bfqq either from
bic (so it would return bfqq3 for bic1) or we allocate a new queue (that
would be some bfqq4). So I see no way how bfqq2 could start pointing to
bic1...
Honza
Following is possible scenarios that we derived:
1) Initial state, two process with io.
Process 1 Process 2
(BIC1) (BIC2)
| Λ | Λ
| | | |
V | V |
bfqq1 bfqq2
2) bfqq1 is merged to bfqq2, now bfqq2 has two process ref, bfqq2->bic
will not be set.
Process 1 Process 2
(BIC1) (BIC2)
| |
\-------------\|
V
bfqq1 bfqq2(coop)
3) Process 1 exit, then issue io(denoted IOA) from Process 2.
Process 2
(BIC1)
| Λ
| |
V |
bfqq2(coop)
4) Before IOA completed, move Process 2 to another cgroup and issue
io.
Process 2
(BIC2)
Λ
|\--------------\
| V
bfqq2(coop) bfqq3
Now that BIC2 point to bfqq3, while bfqq2 and bfqq3 both point to BIC2.
5) If all the io are completed and Process 2 exit, BIC2 will be freed,
while bfqq2 still ponits to BIC2.
It's easy to construct such scenario, however, I'm not able to trigger
such UAF yet. It seems hard to let bfqq2 become in_service_queue again
and access bfqq2->bic in bfq_select_queue.
While I'm organizing the above procedures, I realized that my former
solution is wrong. Now I think that the right thing to do is to also
clear bfqq->bic while process ref is decreased to 0.
Thanks,
Kuai
