* [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
@ 2023-01-12 11:38 Shinichiro Kawasaki
2023-01-12 11:47 ` Yu Kuai
0 siblings, 1 reply; 7+ messages in thread
From: Shinichiro Kawasaki @ 2023-01-12 11:38 UTC (permalink / raw
To: linux-block@vger.kernel.org; +Cc: Paolo Valente, Jan Kara, Yu Kuai
I observed another KASAN uaf related to bfq. I would like to ask bfq experts
to take a look in it. Whole KASAN message is attached below. It looks different
from another uaf fixed with 246cf66e300b ("block, bfq: fix uaf for bfqq in
bfq_exit_icq_bfqq").
It was observed first time during blktests test case block/027 run on kernel
v6.2-rc3. Depending on test machines, it was recreated during system boot or ssh
login occasionally. When I repeat system reboot and ssh-login twice, the uaf is
recreated.
I guess 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") could be
the trigger commit. I cherry-picked the two commits 64dc8c732f5c and
246cf66e300b on top of v6.1. With this kernel, I observed the KASAN uaf in
bic_set_bfqq.
BUG: KASAN: use-after-free in bic_set_bfqq+0x15f/0x190
device offline error, dev sdr, sector 245352968 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
Read of size 8 at addr ffff88811de85f88 by task in:imjournal/815
CPU: 5 PID: 815 Comm: in:imjournal Not tainted 6.2.0-rc3-kts+ #1
Hardware name: Supermicro Super Server/X10SRL-F, BIOS 3.2 11/22/2019
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x77
print_report+0x182/0x47e
? bic_set_bfqq+0x15f/0x190
? bic_set_bfqq+0x15f/0x190
kasan_report+0xbb/0xf0
? bic_set_bfqq+0x15f/0x190
bic_set_bfqq+0x15f/0x190
bfq_bic_update_cgroup+0x386/0x950
bfq_bio_merge+0x132/0x2c0
? __pfx_bfq_bio_merge+0x10/0x10
blk_mq_submit_bio+0xc5c/0x1b40
? __pfx_blk_mq_submit_bio+0x10/0x10
? find_held_lock+0x2d/0x110
__submit_bio+0x24d/0x2c0
? __pfx___submit_bio+0x10/0x10
submit_bio_noacct_nocheck+0x5b1/0x820
? __pfx_submit_bio_noacct_nocheck+0x10/0x10
? rcu_read_lock_sched_held+0x3f/0x80
ext4_io_submit+0x86/0x110
ext4_do_writepages+0xb97/0x2f70
? __pfx_ext4_do_writepages+0x10/0x10
? lock_is_held_type+0xe3/0x140
ext4_writepages+0x21c/0x4b0
? __pfx_ext4_writepages+0x10/0x10
? __lock_acquire+0xc75/0x5520
do_writepages+0x166/0x630
? __pfx_do_writepages+0x10/0x10
? lock_release+0x365/0x730
? wbc_attach_and_unlock_inode+0x3a3/0x780
? __pfx_lock_release+0x10/0x10
? __pfx_lock_release+0x10/0x10
? __pfx_lock_acquire+0x10/0x10
? do_raw_spin_unlock+0x54/0x1f0
? _raw_spin_unlock+0x29/0x50
? wbc_attach_and_unlock_inode+0x3a3/0x780
filemap_fdatawrite_wbc+0x111/0x170
? kfree+0x115/0x190
__filemap_fdatawrite_range+0x9a/0xc0
? __pfx___filemap_fdatawrite_range+0x10/0x10
? __pfx_ext4_find_entry+0x10/0x10
? __pfx___dquot_initialize+0x10/0x10
? rcu_read_lock_sched_held+0x3f/0x80
? ext4_alloc_da_blocks+0x177/0x210
ext4_rename+0x1123/0x23d0
? __pfx_ext4_rename+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
? lock_acquire+0x1a4/0x4f0
? down_write_nested+0x141/0x200
? ext4_rename2+0x88/0x200
vfs_rename+0xa6e/0x14f0
? __pfx_lock_release+0x10/0x10
? hook_file_open+0x780/0x790
? __pfx_vfs_rename+0x10/0x10
? __d_lookup+0x1fd/0x330
? d_lookup+0x37/0x50
? security_path_rename+0x111/0x1e0
do_renameat2+0x81c/0xa00
? __pfx_do_renameat2+0x10/0x10
? lock_release+0x365/0x730
? __might_fault+0xbc/0x160
? __pfx_lock_release+0x10/0x10
? getname_flags.part.0+0x8d/0x430
? lockdep_hardirqs_on_prepare+0x17b/0x410
__x64_sys_rename+0x7d/0xa0
do_syscall_64+0x5b/0x80
? lockdep_hardirqs_on+0x7d/0x100
? do_syscall_64+0x67/0x80
? do_syscall_64+0x67/0x80
? lockdep_hardirqs_on+0x7d/0x100
? do_syscall_64+0x67/0x80
? do_syscall_64+0x67/0x80
? lockdep_hardirqs_on+0x7d/0x100
? do_syscall_64+0x67/0x80
? do_syscall_64+0x67/0x80
? do_syscall_64+0x67/0x80
? lockdep_hardirqs_on+0x7d/0x100
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f8a2a5e3eab
Code: e8 ba 2a 0a 00 f7 d8 19 c0 5b c3 0f 1f 40 00 b8 ff ff ff ff 5b c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 52 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05
+c3 0f 1f 40 00 48 8b 15 51 8f 17 00 f7 d8
RSP: 002b:00007f8a213fcc28 EFLAGS: 00000206 ORIG_RAX: 0000000000000052
RAX: ffffffffffffffda RBX: 00007f8a1c00c640 RCX: 00007f8a2a5e3eab
RDX: 0000000000000001 RSI: 000055d94c238820 RDI: 00007f8a213fcc30
RBP: 00007f8a213fcc30 R08: 0000000000000000 R09: 00007f8a1c000130
R10: 0000000000000000 R11: 0000000000000206 R12: 00007f8a1c00b480
R13: 0000000000000067 R14: 00007f8a213fdce0 R15: 00007f8a1c00b180
</TASK>
Allocated by task 815:
kasan_save_stack+0x1c/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x88/0x90
kmem_cache_alloc_node+0x175/0x420
--
Shin'ichiro Kawasaki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
2023-01-12 11:38 [bug report] BUG: KASAN: use-after-free in bic_set_bfqq Shinichiro Kawasaki
@ 2023-01-12 11:47 ` Yu Kuai
2023-01-12 11:53 ` Yu Kuai
2023-01-12 13:14 ` Shinichiro Kawasaki
0 siblings, 2 replies; 7+ messages in thread
From: Yu Kuai @ 2023-01-12 11:47 UTC (permalink / raw
To: Shinichiro Kawasaki, linux-block@vger.kernel.org
Cc: Paolo Valente, Jan Kara, yukuai (C)
Hi,
在 2023/01/12 19:38, Shinichiro Kawasaki 写道:
> I observed another KASAN uaf related to bfq. I would like to ask bfq experts
> to take a look in it. Whole KASAN message is attached below. It looks different
> from another uaf fixed with 246cf66e300b ("block, bfq: fix uaf for bfqq in
> bfq_exit_icq_bfqq").
>
> It was observed first time during blktests test case block/027 run on kernel
> v6.2-rc3. Depending on test machines, it was recreated during system boot or ssh
> login occasionally. When I repeat system reboot and ssh-login twice, the uaf is
> recreated.
>
> I guess 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") could be
> the trigger commit. I cherry-picked the two commits 64dc8c732f5c and
> 246cf66e300b on top of v6.1. With this kernel, I observed the KASAN uaf in
> bic_set_bfqq.
>
>
> BUG: KASAN: use-after-free in bic_set_bfqq+0x15f/0x190
> device offline error, dev sdr, sector 245352968 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
> Read of size 8 at addr ffff88811de85f88 by task in:imjournal/815
>
Thanks for the report, is the problem easy to reporduce? If so, can you
try the following patch?
diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 1b2829e99dad..81d2f401fa3f 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
*bfqd,
* request from the old cgroup.
*/
bfq_put_cooperator(sync_bfqq);
- bfq_release_process_ref(bfqd, sync_bfqq);
bic_set_bfqq(bic, NULL, true);
+ bfq_release_process_ref(bfqd, sync_bfqq);
}
}
}
> CPU: 5 PID: 815 Comm: in:imjournal Not tainted 6.2.0-rc3-kts+ #1
> Hardware name: Supermicro Super Server/X10SRL-F, BIOS 3.2 11/22/2019
> Call Trace:
> <TASK>
> dump_stack_lvl+0x5b/0x77
> print_report+0x182/0x47e
> ? bic_set_bfqq+0x15f/0x190
> ? bic_set_bfqq+0x15f/0x190
> kasan_report+0xbb/0xf0
> ? bic_set_bfqq+0x15f/0x190
> bic_set_bfqq+0x15f/0x190
> bfq_bic_update_cgroup+0x386/0x950
> bfq_bio_merge+0x132/0x2c0
> ? __pfx_bfq_bio_merge+0x10/0x10
> blk_mq_submit_bio+0xc5c/0x1b40
> ? __pfx_blk_mq_submit_bio+0x10/0x10
> ? find_held_lock+0x2d/0x110
> __submit_bio+0x24d/0x2c0
> ? __pfx___submit_bio+0x10/0x10
> submit_bio_noacct_nocheck+0x5b1/0x820
> ? __pfx_submit_bio_noacct_nocheck+0x10/0x10
> ? rcu_read_lock_sched_held+0x3f/0x80
> ext4_io_submit+0x86/0x110
> ext4_do_writepages+0xb97/0x2f70
> ? __pfx_ext4_do_writepages+0x10/0x10
> ? lock_is_held_type+0xe3/0x140
> ext4_writepages+0x21c/0x4b0
> ? __pfx_ext4_writepages+0x10/0x10
> ? __lock_acquire+0xc75/0x5520
> do_writepages+0x166/0x630
> ? __pfx_do_writepages+0x10/0x10
> ? lock_release+0x365/0x730
> ? wbc_attach_and_unlock_inode+0x3a3/0x780
> ? __pfx_lock_release+0x10/0x10
> ? __pfx_lock_release+0x10/0x10
> ? __pfx_lock_acquire+0x10/0x10
> ? do_raw_spin_unlock+0x54/0x1f0
> ? _raw_spin_unlock+0x29/0x50
> ? wbc_attach_and_unlock_inode+0x3a3/0x780
> filemap_fdatawrite_wbc+0x111/0x170
> ? kfree+0x115/0x190
> __filemap_fdatawrite_range+0x9a/0xc0
> ? __pfx___filemap_fdatawrite_range+0x10/0x10
> ? __pfx_ext4_find_entry+0x10/0x10
> ? __pfx___dquot_initialize+0x10/0x10
> ? rcu_read_lock_sched_held+0x3f/0x80
> ? ext4_alloc_da_blocks+0x177/0x210
> ext4_rename+0x1123/0x23d0
> ? __pfx_ext4_rename+0x10/0x10
> ? __pfx___lock_acquire+0x10/0x10
> ? lock_acquire+0x1a4/0x4f0
> ? down_write_nested+0x141/0x200
> ? ext4_rename2+0x88/0x200
> vfs_rename+0xa6e/0x14f0
> ? __pfx_lock_release+0x10/0x10
> ? hook_file_open+0x780/0x790
> ? __pfx_vfs_rename+0x10/0x10
> ? __d_lookup+0x1fd/0x330
> ? d_lookup+0x37/0x50
> ? security_path_rename+0x111/0x1e0
> do_renameat2+0x81c/0xa00
> ? __pfx_do_renameat2+0x10/0x10
> ? lock_release+0x365/0x730
> ? __might_fault+0xbc/0x160
> ? __pfx_lock_release+0x10/0x10
> ? getname_flags.part.0+0x8d/0x430
> ? lockdep_hardirqs_on_prepare+0x17b/0x410
> __x64_sys_rename+0x7d/0xa0
> do_syscall_64+0x5b/0x80
> ? lockdep_hardirqs_on+0x7d/0x100
> ? do_syscall_64+0x67/0x80
> ? do_syscall_64+0x67/0x80
> ? lockdep_hardirqs_on+0x7d/0x100
> ? do_syscall_64+0x67/0x80
> ? do_syscall_64+0x67/0x80
> ? lockdep_hardirqs_on+0x7d/0x100
> ? do_syscall_64+0x67/0x80
> ? do_syscall_64+0x67/0x80
> ? do_syscall_64+0x67/0x80
> ? lockdep_hardirqs_on+0x7d/0x100
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
> RIP: 0033:0x7f8a2a5e3eab
> Code: e8 ba 2a 0a 00 f7 d8 19 c0 5b c3 0f 1f 40 00 b8 ff ff ff ff 5b c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 52 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05
> +c3 0f 1f 40 00 48 8b 15 51 8f 17 00 f7 d8
> RSP: 002b:00007f8a213fcc28 EFLAGS: 00000206 ORIG_RAX: 0000000000000052
> RAX: ffffffffffffffda RBX: 00007f8a1c00c640 RCX: 00007f8a2a5e3eab
> RDX: 0000000000000001 RSI: 000055d94c238820 RDI: 00007f8a213fcc30
> RBP: 00007f8a213fcc30 R08: 0000000000000000 R09: 00007f8a1c000130
> R10: 0000000000000000 R11: 0000000000000206 R12: 00007f8a1c00b480
> R13: 0000000000000067 R14: 00007f8a213fdce0 R15: 00007f8a1c00b180
> </TASK>
>
> Allocated by task 815:
> kasan_save_stack+0x1c/0x40
> kasan_set_track+0x21/0x30
> __kasan_slab_alloc+0x88/0x90
> kmem_cache_alloc_node+0x175/0x420
>
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
2023-01-12 11:47 ` Yu Kuai
@ 2023-01-12 11:53 ` Yu Kuai
2023-01-12 13:18 ` Shinichiro Kawasaki
2023-01-12 13:14 ` Shinichiro Kawasaki
1 sibling, 1 reply; 7+ messages in thread
From: Yu Kuai @ 2023-01-12 11:53 UTC (permalink / raw
To: Yu Kuai, Shinichiro Kawasaki, linux-block@vger.kernel.org
Cc: Paolo Valente, Jan Kara, yukuai (C)
Hi,
在 2023/01/12 19:47, Yu Kuai 写道:
> Thanks for the report, is the problem easy to reporduce? If so, can you
> try the following patch?
>
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 1b2829e99dad..81d2f401fa3f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> *bfqd,
> * request from the old cgroup.
> */
> bfq_put_cooperator(sync_bfqq);
> - bfq_release_process_ref(bfqd, sync_bfqq);
> bic_set_bfqq(bic, NULL, true);
> + bfq_release_process_ref(bfqd, sync_bfqq);
> }
> }
> }
>
Just in case you hit the problem in another place, please using the
following patch:
diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
index 1b2829e99dad..81d2f401fa3f 100644
--- a/block/bfq-cgroup.c
+++ b/block/bfq-cgroup.c
@@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
*bfqd,
* request from the old cgroup.
*/
bfq_put_cooperator(sync_bfqq);
- bfq_release_process_ref(bfqd, sync_bfqq);
bic_set_bfqq(bic, NULL, true);
+ bfq_release_process_ref(bfqd, sync_bfqq);
}
}
}
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 16f43bbc575a..687285612e57 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5425,9 +5425,10 @@ static void bfq_check_ioprio_change(struct
bfq_io_cq *bic, struct bio *bio)
bfqq = bic_to_bfqq(bic, false);
if (bfqq) {
- bfq_release_process_ref(bfqd, bfqq);
+ struct bfq_queue *old_bfqq = bfqq;
bfqq = bfq_get_queue(bfqd, bio, false, bic, true);
bic_set_bfqq(bic, bfqq, false);
+ bfq_release_process_ref(bfqd, old_bfqq);
}
bfqq = bic_to_bfqq(bic, true);
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
2023-01-12 11:47 ` Yu Kuai
2023-01-12 11:53 ` Yu Kuai
@ 2023-01-12 13:14 ` Shinichiro Kawasaki
1 sibling, 0 replies; 7+ messages in thread
From: Shinichiro Kawasaki @ 2023-01-12 13:14 UTC (permalink / raw
To: Yu Kuai; +Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)
On Jan 12, 2023 / 19:47, Yu Kuai wrote:
> Hi,
>
> 在 2023/01/12 19:38, Shinichiro Kawasaki 写道:
> > I observed another KASAN uaf related to bfq. I would like to ask bfq experts
> > to take a look in it. Whole KASAN message is attached below. It looks different
> > from another uaf fixed with 246cf66e300b ("block, bfq: fix uaf for bfqq in
> > bfq_exit_icq_bfqq").
> >
> > It was observed first time during blktests test case block/027 run on kernel
> > v6.2-rc3. Depending on test machines, it was recreated during system boot or ssh
> > login occasionally. When I repeat system reboot and ssh-login twice, the uaf is
> > recreated.
> >
> > I guess 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'") could be
> > the trigger commit. I cherry-picked the two commits 64dc8c732f5c and
> > 246cf66e300b on top of v6.1. With this kernel, I observed the KASAN uaf in
> > bic_set_bfqq.
> >
> >
> > BUG: KASAN: use-after-free in bic_set_bfqq+0x15f/0x190
> > device offline error, dev sdr, sector 245352968 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
> > Read of size 8 at addr ffff88811de85f88 by task in:imjournal/815
> >
> Thanks for the report, is the problem easy to reporduce? If so, can you
> try the following patch?
>
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 1b2829e99dad..81d2f401fa3f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> *bfqd,
> * request from the old cgroup.
> */
> bfq_put_cooperator(sync_bfqq);
> - bfq_release_process_ref(bfqd, sync_bfqq);
> bic_set_bfqq(bic, NULL, true);
> + bfq_release_process_ref(bfqd, sync_bfqq);
> }
> }
> }
Thanks for the quick response. Yes, I can recreate the problem reliably using
one of my test machines. With your fix patch above, the problem disappeared :)
I repeated system reboot and ssh login 6 times and the problem was not observed.
--
Shin'ichiro Kawasaki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
2023-01-12 11:53 ` Yu Kuai
@ 2023-01-12 13:18 ` Shinichiro Kawasaki
2023-01-13 1:04 ` Shinichiro Kawasaki
0 siblings, 1 reply; 7+ messages in thread
From: Shinichiro Kawasaki @ 2023-01-12 13:18 UTC (permalink / raw
To: Yu Kuai; +Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)
On Jan 12, 2023 / 19:53, Yu Kuai wrote:
> Hi,
>
> 在 2023/01/12 19:47, Yu Kuai 写道:
> > Thanks for the report, is the problem easy to reporduce? If so, can you
> > try the following patch?
> >
> > diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> > index 1b2829e99dad..81d2f401fa3f 100644
> > --- a/block/bfq-cgroup.c
> > +++ b/block/bfq-cgroup.c
> > @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> > *bfqd,
> > * request from the old cgroup.
> > */
> > bfq_put_cooperator(sync_bfqq);
> > - bfq_release_process_ref(bfqd, sync_bfqq);
> > bic_set_bfqq(bic, NULL, true);
> > + bfq_release_process_ref(bfqd, sync_bfqq);
> > }
> > }
> > }
> >
> Just in case you hit the problem in another place, please using the
> following patch:
>
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index 1b2829e99dad..81d2f401fa3f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> *bfqd,
> * request from the old cgroup.
> */
> bfq_put_cooperator(sync_bfqq);
> - bfq_release_process_ref(bfqd, sync_bfqq);
> bic_set_bfqq(bic, NULL, true);
> + bfq_release_process_ref(bfqd, sync_bfqq);
> }
> }
> }
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 16f43bbc575a..687285612e57 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -5425,9 +5425,10 @@ static void bfq_check_ioprio_change(struct bfq_io_cq
> *bic, struct bio *bio)
>
> bfqq = bic_to_bfqq(bic, false);
> if (bfqq) {
> - bfq_release_process_ref(bfqd, bfqq);
> + struct bfq_queue *old_bfqq = bfqq;
> bfqq = bfq_get_queue(bfqd, bio, false, bic, true);
> bic_set_bfqq(bic, bfqq, false);
> + bfq_release_process_ref(bfqd, old_bfqq);
> }
>
> bfqq = bic_to_bfqq(bic, true);
>
Ah, I've just noticed this e-mail. Will test this patch tomorrow.
--
Shin'ichiro Kawasaki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
2023-01-12 13:18 ` Shinichiro Kawasaki
@ 2023-01-13 1:04 ` Shinichiro Kawasaki
2023-01-13 1:11 ` Yu Kuai
0 siblings, 1 reply; 7+ messages in thread
From: Shinichiro Kawasaki @ 2023-01-13 1:04 UTC (permalink / raw
To: Yu Kuai; +Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)
On Jan 12, 2023 / 22:18, Shin'ichiro Kawasaki wrote:
> On Jan 12, 2023 / 19:53, Yu Kuai wrote:
> > Hi,
> >
> > 在 2023/01/12 19:47, Yu Kuai 写道:
> > > Thanks for the report, is the problem easy to reporduce? If so, can you
> > > try the following patch?
> > >
> > > diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> > > index 1b2829e99dad..81d2f401fa3f 100644
> > > --- a/block/bfq-cgroup.c
> > > +++ b/block/bfq-cgroup.c
> > > @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> > > *bfqd,
> > > * request from the old cgroup.
> > > */
> > > bfq_put_cooperator(sync_bfqq);
> > > - bfq_release_process_ref(bfqd, sync_bfqq);
> > > bic_set_bfqq(bic, NULL, true);
> > > + bfq_release_process_ref(bfqd, sync_bfqq);
> > > }
> > > }
> > > }
> > >
> > Just in case you hit the problem in another place, please using the
> > following patch:
> >
> > diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> > index 1b2829e99dad..81d2f401fa3f 100644
> > --- a/block/bfq-cgroup.c
> > +++ b/block/bfq-cgroup.c
> > @@ -771,8 +771,8 @@ static void __bfq_bic_change_cgroup(struct bfq_data
> > *bfqd,
> > * request from the old cgroup.
> > */
> > bfq_put_cooperator(sync_bfqq);
> > - bfq_release_process_ref(bfqd, sync_bfqq);
> > bic_set_bfqq(bic, NULL, true);
> > + bfq_release_process_ref(bfqd, sync_bfqq);
> > }
> > }
> > }
> > diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> > index 16f43bbc575a..687285612e57 100644
> > --- a/block/bfq-iosched.c
> > +++ b/block/bfq-iosched.c
> > @@ -5425,9 +5425,10 @@ static void bfq_check_ioprio_change(struct bfq_io_cq
> > *bic, struct bio *bio)
> >
> > bfqq = bic_to_bfqq(bic, false);
> > if (bfqq) {
> > - bfq_release_process_ref(bfqd, bfqq);
> > + struct bfq_queue *old_bfqq = bfqq;
> > bfqq = bfq_get_queue(bfqd, bio, false, bic, true);
> > bic_set_bfqq(bic, bfqq, false);
> > + bfq_release_process_ref(bfqd, old_bfqq);
> > }
> >
> > bfqq = bic_to_bfqq(bic, true);
> >
>
> Ah, I've just noticed this e-mail. Will test this patch tomorrow.
This second trial patch also avoided the KASAN uaf message. I repeated the
system boot and ssh login 6 times and did not observe the failure. Looks good.
--
Shin'ichiro Kawasaki
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug report] BUG: KASAN: use-after-free in bic_set_bfqq
2023-01-13 1:04 ` Shinichiro Kawasaki
@ 2023-01-13 1:11 ` Yu Kuai
0 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2023-01-13 1:11 UTC (permalink / raw
To: Shinichiro Kawasaki, Yu Kuai
Cc: linux-block@vger.kernel.org, Paolo Valente, Jan Kara, yukuai (C)
Hi!
在 2023/01/13 9:04, Shinichiro Kawasaki 写道:
> This second trial patch also avoided the KASAN uaf message. I repeated the
> system boot and ssh login 6 times and did not observe the failure. Looks good.
>
Thanks for the feedback! I'll send a patch soon.
Kuai
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-01-13 1:11 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-12 11:38 [bug report] BUG: KASAN: use-after-free in bic_set_bfqq Shinichiro Kawasaki
2023-01-12 11:47 ` Yu Kuai
2023-01-12 11:53 ` Yu Kuai
2023-01-12 13:18 ` Shinichiro Kawasaki
2023-01-13 1:04 ` Shinichiro Kawasaki
2023-01-13 1:11 ` Yu Kuai
2023-01-12 13:14 ` Shinichiro Kawasaki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).