| Message ID | 20240202121531.2550018-1-lizhi.xu@windriver.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [next] fs/9p: fix uaf in in v9fs_stat2inode_dotl | expand |
On Fri, Feb 02, 2024 at 08:15:31PM +0800, Lizhi Xu wrote: > The incorrect logical order of accessing the st object code in v9fs_fid_iget_dotl > is causing this uaf. > > Fixes: 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths") > Reported-and-tested-by: syzbot+7a3d75905ea1a830dbe5@syzkaller.appspotmail.com > Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com> Tested-by: Breno Leitao <leitao@debian.org>
Lizhi Xu wrote on Fri, Feb 02, 2024 at 08:15:31PM +0800: > The incorrect logical order of accessing the st object code in v9fs_fid_iget_dotl > is causing this uaf. Thanks for the fix! Eric, this is also for your tree. > > Fixes: 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths") (careful if you rebase your tree as this commit isn't merged yet) > Reported-and-tested-by: syzbot+7a3d75905ea1a830dbe5@syzkaller.appspotmail.com > Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com> Reviewed-by: Dominique Martinet <asmadeus@codewreck.org>
On Mon, 4 Mar 2024 22:02:29 +0900 asmadeus@codewreck.org wrote: > Lizhi Xu wrote on Fri, Feb 02, 2024 at 08:15:31PM +0800: > > The incorrect logical order of accessing the st object code in v9fs_fid_iget_dotl > > is causing this uaf. > > Thanks for the fix! > > Eric, this is also for your tree. > > > Fixes: 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths") > > (careful if you rebase your tree as this commit isn't merged yet) > > > Reported-and-tested-by: syzbot+7a3d75905ea1a830dbe5@syzkaller.appspotmail.com > > Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com> > > Reviewed-by: Dominique Martinet <asmadeus@codewreck.org> Looks like this UAF is in Linus's tree now, and possibly getting hit by anyone using virtme to test the kernel? I can't vouch for the correctness of the fix but it does make the KASAN splat go away for me. [ 12.474676][ T1] ================================================================== [ 12.474870][ T1] BUG: KASAN: slab-use-after-free in v9fs_stat2inode_dotl+0x9d6/0xb80 [ 12.475060][ T1] Read of size 8 at addr ffff888002bdbad8 by task swapper/0/1 [ 12.475248][ T1] [ 12.475314][ T1] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.8.0-virtme #1 [ 12.475503][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 12.475811][ T1] Call Trace: [ 12.475908][ T1] <TASK> [ 12.475976][ T1] dump_stack_lvl+0x82/0xd0 [ 12.476133][ T1] print_address_description.constprop.0+0x2c/0x3b0 [ 12.476295][ T1] ? v9fs_stat2inode_dotl+0x9d6/0xb80 [ 12.476425][ T1] print_report+0xb4/0x270 [ 12.476552][ T1] ? kasan_addr_to_slab+0x4e/0x90 [ 12.476679][ T1] kasan_report+0xbd/0xf0 [ 12.476775][ T1] ? v9fs_stat2inode_dotl+0x9d6/0xb80 [ 12.476903][ T1] v9fs_stat2inode_dotl+0x9d6/0xb80 [ 12.477053][ T1] v9fs_fid_iget_dotl+0x18c/0x210 [ 12.477180][ T1] v9fs_mount+0x3fe/0x7d0 [ 12.477281][ T1] ? __pfx_v9fs_mount+0x10/0x10 [ 12.477406][ T1] ? vfs_parse_fs_string+0xdb/0x130 [ 12.477533][ T1] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 12.477660][ T1] ? __pfx_v9fs_mount+0x10/0x10 [ 12.477786][ T1] legacy_get_tree+0x107/0x200 [ 12.477912][ T1] vfs_get_tree+0x8a/0x2e0 [ 12.478042][ T1] do_new_mount+0x27d/0x5e0 [ 12.478170][ T1] ? __pfx_do_new_mount+0x10/0x10 [ 12.478294][ T1] ? __pfx___debug_check_no_obj_freed+0x10/0x10 [ 12.478453][ T1] ? __virt_addr_valid+0x227/0x420 [ 12.478583][ T1] path_mount+0x271/0x14f0 [ 12.478713][ T1] ? __pfx_path_mount+0x10/0x10 [ 12.478840][ T1] ? kmem_cache_free+0xd7/0x220 [ 12.478970][ T1] ? kern_path+0x3d/0x50 [ 12.479068][ T1] init_mount+0x9d/0xf0 [ 12.479164][ T1] ? __pfx_init_mount+0x10/0x10 [ 12.479292][ T1] do_mount_root+0xbc/0x330 [ 12.479419][ T1] mount_root_generic+0x22c/0x470 [ 12.479550][ T1] ? __pfx_mount_root_generic+0x10/0x10 [ 12.479680][ T1] ? mount_root+0x25b/0x2f0 [ 12.479807][ T1] prepare_namespace+0xa5/0x2d0 [ 12.479933][ T1] ? __pfx_prepare_namespace+0x10/0x10 [ 12.480061][ T1] ? __pfx_kernel_init+0x10/0x10 [ 12.480188][ T1] kernel_init+0x20/0x200 [ 12.480285][ T1] ? __pfx_kernel_init+0x10/0x10 [ 12.480410][ T1] ret_from_fork+0x31/0x70 [ 12.480543][ T1] ? __pfx_kernel_init+0x10/0x10 [ 12.480670][ T1] ret_from_fork_asm+0x1a/0x30 [ 12.480807][ T1] </TASK> [ 12.480904][ T1] [ 12.480969][ T1] Allocated by task 1: [ 12.481063][ T1] kasan_save_stack+0x24/0x50 [ 12.481191][ T1] kasan_save_track+0x14/0x30 [ 12.481323][ T1] __kasan_kmalloc+0x7f/0x90 [ 12.481449][ T1] p9_client_getattr_dotl+0x4c/0x1a0 [ 12.481576][ T1] v9fs_fid_iget_dotl+0xca/0x210 [ 12.481706][ T1] v9fs_mount+0x3fe/0x7d0 [ 12.481801][ T1] legacy_get_tree+0x107/0x200 [ 12.481927][ T1] vfs_get_tree+0x8a/0x2e0 [ 12.482053][ T1] do_new_mount+0x27d/0x5e0 [ 12.482178][ T1] path_mount+0x271/0x14f0 [ 12.482303][ T1] init_mount+0x9d/0xf0 [ 12.482397][ T1] do_mount_root+0xbc/0x330 [ 12.482523][ T1] mount_root_generic+0x22c/0x470 [ 12.482649][ T1] prepare_namespace+0xa5/0x2d0 [ 12.482779][ T1] kernel_init+0x20/0x200 [ 12.482876][ T1] ret_from_fork+0x31/0x70 [ 12.483002][ T1] ret_from_fork_asm+0x1a/0x30 [ 12.483128][ T1] [ 12.483191][ T1] Freed by task 1: [ 12.483283][ T1] kasan_save_stack+0x24/0x50 [ 12.483409][ T1] kasan_save_track+0x14/0x30 [ 12.483535][ T1] kasan_save_free_info+0x3b/0x60 [ 12.483662][ T1] __kasan_slab_free+0xf4/0x180 [ 12.483788][ T1] kfree+0xd3/0x230 [ 12.483886][ T1] v9fs_fid_iget_dotl+0x15e/0x210 [ 12.484017][ T1] v9fs_mount+0x3fe/0x7d0 [ 12.484112][ T1] legacy_get_tree+0x107/0x200 [ 12.484238][ T1] vfs_get_tree+0x8a/0x2e0 [ 12.484365][ T1] do_new_mount+0x27d/0x5e0 [ 12.484492][ T1] path_mount+0x271/0x14f0 [ 12.484619][ T1] init_mount+0x9d/0xf0 [ 12.484713][ T1] do_mount_root+0xbc/0x330 [ 12.484846][ T1] mount_root_generic+0x22c/0x470 [ 12.484974][ T1] prepare_namespace+0xa5/0x2d0 [ 12.485100][ T1] kernel_init+0x20/0x200 [ 12.485196][ T1] ret_from_fork+0x31/0x70 [ 12.485324][ T1] ret_from_fork_asm+0x1a/0x30 [ 12.485449][ T1] [ 12.485512][ T1] The buggy address belongs to the object at ffff888002bdbad8 [ 12.485512][ T1] which belongs to the cache kmalloc-192 of size 192 [ 12.485825][ T1] The buggy address is located 0 bytes inside of [ 12.485825][ T1] freed 192-byte region [ffff888002bdbad8, ffff888002bdbb98) [ 12.486131][ T1] [ 12.486194][ T1] The buggy address belongs to the physical page: [ 12.486347][ T1] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888002bdbc10 pfn:0x2bda [ 12.486600][ T1] head: order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 12.486795][ T1] flags: 0x80000000000a40(workingset|slab|head|node=0|zone=1) [ 12.486989][ T1] page_type: 0xffffffff() [ 12.487088][ T1] raw: 0080000000000a40 ffff888001042c40 ffff888001040a88 ffff888001040a88 [ 12.487315][ T1] raw: ffff888002bdbc10 00000000001a0017 00000001ffffffff 0000000000000000 [ 12.487538][ T1] head: 0080000000000a40 ffff888001042c40 ffff888001040a88 ffff888001040a88 [ 12.487765][ T1] head: ffff888002bdbc10 00000000001a0017 00000001ffffffff 0000000000000000 [ 12.487992][ T1] head: 0080000000000001 ffffea00000af681 dead000000000122 00000000ffffffff [ 12.488213][ T1] head: 0000000200000000 0000000000000000 00000000ffffffff 0000000000000000 [ 12.488436][ T1] page dumped because: kasan: bad access detected [ 12.488590][ T1] [ 12.488653][ T1] Memory state around the buggy address: [ 12.488797][ T1] ffff888002bdb980: fc fc fc fc 00 00 00 00 00 00 00 00 00 00 00 00 [ 12.488986][ T1] ffff888002bdba00: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 12.489168][ T1] >ffff888002bdba80: fc fc fc fc fc fc fc fc fc fc fc fa fb fb fb fb [ 12.489353][ T1] ^ [ 12.489506][ T1] ffff888002bdbb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 12.489688][ T1] ffff888002bdbb80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc [ 12.489873][ T1] ==================================================================
Patch is in the unapplied portion of my for-next tree along with another one. I was hoping to hear some feedback on the other one before i did a pull request and was torn on whether or not I wait on -rc1 to send since we are so close.
-eric
March 21, 2024 at 8:28 PM, "Jakub Kicinski" <kuba@kernel.org> wrote:
>
> On Mon, 4 Mar 2024 22:02:29 +0900 asmadeus@codewreck.org wrote:
>
> >
> > Lizhi Xu wrote on Fri, Feb 02, 2024 at 08:15:31PM +0800:
> >
> > The incorrect logical order of accessing the st object code in v9fs_fid_iget_dotl
> >
> > is causing this uaf.
> >
> >
> >
> > Thanks for the fix!
> >
> >
> >
> > Eric, this is also for your tree.
> >
> >
> >
> > Fixes: 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths")
> >
> >
> >
> > (careful if you rebase your tree as this commit isn't merged yet)
> >
> >
> >
> > Reported-and-tested-by: syzbot+7a3d75905ea1a830dbe5@syzkaller.appspotmail.com
> >
> > Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
> >
> >
> >
> > Reviewed-by: Dominique Martinet <asmadeus@codewreck.org>
> >
>
> Looks like this UAF is in Linus's tree now, and possibly getting hit
>
> by anyone using virtme to test the kernel? I can't vouch for the
>
> correctness of the fix but it does make the KASAN splat go away for me.
>
> [ 12.474676][ T1] ==================================================================
>
> [ 12.474870][ T1] BUG: KASAN: slab-use-after-free in v9fs_stat2inode_dotl+0x9d6/0xb80
>
> [ 12.475060][ T1] Read of size 8 at addr ffff888002bdbad8 by task swapper/0/1
>
> [ 12.475248][ T1]
>
> [ 12.475314][ T1] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.8.0-virtme #1
>
> [ 12.475503][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
>
> [ 12.475811][ T1] Call Trace:
>
> [ 12.475908][ T1] <TASK>
>
> [ 12.475976][ T1] dump_stack_lvl+0x82/0xd0
>
> [ 12.476133][ T1] print_address_description.constprop.0+0x2c/0x3b0
>
> [ 12.476295][ T1] ? v9fs_stat2inode_dotl+0x9d6/0xb80
>
> [ 12.476425][ T1] print_report+0xb4/0x270
>
> [ 12.476552][ T1] ? kasan_addr_to_slab+0x4e/0x90
>
> [ 12.476679][ T1] kasan_report+0xbd/0xf0
>
> [ 12.476775][ T1] ? v9fs_stat2inode_dotl+0x9d6/0xb80
>
> [ 12.476903][ T1] v9fs_stat2inode_dotl+0x9d6/0xb80
>
> [ 12.477053][ T1] v9fs_fid_iget_dotl+0x18c/0x210
>
> [ 12.477180][ T1] v9fs_mount+0x3fe/0x7d0
>
> [ 12.477281][ T1] ? __pfx_v9fs_mount+0x10/0x10
>
> [ 12.477406][ T1] ? vfs_parse_fs_string+0xdb/0x130
>
> [ 12.477533][ T1] ? __pfx_vfs_parse_fs_string+0x10/0x10
>
> [ 12.477660][ T1] ? __pfx_v9fs_mount+0x10/0x10
>
> [ 12.477786][ T1] legacy_get_tree+0x107/0x200
>
> [ 12.477912][ T1] vfs_get_tree+0x8a/0x2e0
>
> [ 12.478042][ T1] do_new_mount+0x27d/0x5e0
>
> [ 12.478170][ T1] ? __pfx_do_new_mount+0x10/0x10
>
> [ 12.478294][ T1] ? __pfx___debug_check_no_obj_freed+0x10/0x10
>
> [ 12.478453][ T1] ? __virt_addr_valid+0x227/0x420
>
> [ 12.478583][ T1] path_mount+0x271/0x14f0
>
> [ 12.478713][ T1] ? __pfx_path_mount+0x10/0x10
>
> [ 12.478840][ T1] ? kmem_cache_free+0xd7/0x220
>
> [ 12.478970][ T1] ? kern_path+0x3d/0x50
>
> [ 12.479068][ T1] init_mount+0x9d/0xf0
>
> [ 12.479164][ T1] ? __pfx_init_mount+0x10/0x10
>
> [ 12.479292][ T1] do_mount_root+0xbc/0x330
>
> [ 12.479419][ T1] mount_root_generic+0x22c/0x470
>
> [ 12.479550][ T1] ? __pfx_mount_root_generic+0x10/0x10
>
> [ 12.479680][ T1] ? mount_root+0x25b/0x2f0
>
> [ 12.479807][ T1] prepare_namespace+0xa5/0x2d0
>
> [ 12.479933][ T1] ? __pfx_prepare_namespace+0x10/0x10
>
> [ 12.480061][ T1] ? __pfx_kernel_init+0x10/0x10
>
> [ 12.480188][ T1] kernel_init+0x20/0x200
>
> [ 12.480285][ T1] ? __pfx_kernel_init+0x10/0x10
>
> [ 12.480410][ T1] ret_from_fork+0x31/0x70
>
> [ 12.480543][ T1] ? __pfx_kernel_init+0x10/0x10
>
> [ 12.480670][ T1] ret_from_fork_asm+0x1a/0x30
>
> [ 12.480807][ T1] </TASK>
>
> [ 12.480904][ T1]
>
> [ 12.480969][ T1] Allocated by task 1:
>
> [ 12.481063][ T1] kasan_save_stack+0x24/0x50
>
> [ 12.481191][ T1] kasan_save_track+0x14/0x30
>
> [ 12.481323][ T1] __kasan_kmalloc+0x7f/0x90
>
> [ 12.481449][ T1] p9_client_getattr_dotl+0x4c/0x1a0
>
> [ 12.481576][ T1] v9fs_fid_iget_dotl+0xca/0x210
>
> [ 12.481706][ T1] v9fs_mount+0x3fe/0x7d0
>
> [ 12.481801][ T1] legacy_get_tree+0x107/0x200
>
> [ 12.481927][ T1] vfs_get_tree+0x8a/0x2e0
>
> [ 12.482053][ T1] do_new_mount+0x27d/0x5e0
>
> [ 12.482178][ T1] path_mount+0x271/0x14f0
>
> [ 12.482303][ T1] init_mount+0x9d/0xf0
>
> [ 12.482397][ T1] do_mount_root+0xbc/0x330
>
> [ 12.482523][ T1] mount_root_generic+0x22c/0x470
>
> [ 12.482649][ T1] prepare_namespace+0xa5/0x2d0
>
> [ 12.482779][ T1] kernel_init+0x20/0x200
>
> [ 12.482876][ T1] ret_from_fork+0x31/0x70
>
> [ 12.483002][ T1] ret_from_fork_asm+0x1a/0x30
>
> [ 12.483128][ T1]
>
> [ 12.483191][ T1] Freed by task 1:
>
> [ 12.483283][ T1] kasan_save_stack+0x24/0x50
>
> [ 12.483409][ T1] kasan_save_track+0x14/0x30
>
> [ 12.483535][ T1] kasan_save_free_info+0x3b/0x60
>
> [ 12.483662][ T1] __kasan_slab_free+0xf4/0x180
>
> [ 12.483788][ T1] kfree+0xd3/0x230
>
> [ 12.483886][ T1] v9fs_fid_iget_dotl+0x15e/0x210
>
> [ 12.484017][ T1] v9fs_mount+0x3fe/0x7d0
>
> [ 12.484112][ T1] legacy_get_tree+0x107/0x200
>
> [ 12.484238][ T1] vfs_get_tree+0x8a/0x2e0
>
> [ 12.484365][ T1] do_new_mount+0x27d/0x5e0
>
> [ 12.484492][ T1] path_mount+0x271/0x14f0
>
> [ 12.484619][ T1] init_mount+0x9d/0xf0
>
> [ 12.484713][ T1] do_mount_root+0xbc/0x330
>
> [ 12.484846][ T1] mount_root_generic+0x22c/0x470
>
> [ 12.484974][ T1] prepare_namespace+0xa5/0x2d0
>
> [ 12.485100][ T1] kernel_init+0x20/0x200
>
> [ 12.485196][ T1] ret_from_fork+0x31/0x70
>
> [ 12.485324][ T1] ret_from_fork_asm+0x1a/0x30
>
> [ 12.485449][ T1]
>
> [ 12.485512][ T1] The buggy address belongs to the object at ffff888002bdbad8
>
> [ 12.485512][ T1] which belongs to the cache kmalloc-192 of size 192
>
> [ 12.485825][ T1] The buggy address is located 0 bytes inside of
>
> [ 12.485825][ T1] freed 192-byte region [ffff888002bdbad8, ffff888002bdbb98)
>
> [ 12.486131][ T1]
>
> [ 12.486194][ T1] The buggy address belongs to the physical page:
>
> [ 12.486347][ T1] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888002bdbc10 pfn:0x2bda
>
> [ 12.486600][ T1] head: order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>
> [ 12.486795][ T1] flags: 0x80000000000a40(workingset|slab|head|node=0|zone=1)
>
> [ 12.486989][ T1] page_type: 0xffffffff()
>
> [ 12.487088][ T1] raw: 0080000000000a40 ffff888001042c40 ffff888001040a88 ffff888001040a88
>
> [ 12.487315][ T1] raw: ffff888002bdbc10 00000000001a0017 00000001ffffffff 0000000000000000
>
> [ 12.487538][ T1] head: 0080000000000a40 ffff888001042c40 ffff888001040a88 ffff888001040a88
>
> [ 12.487765][ T1] head: ffff888002bdbc10 00000000001a0017 00000001ffffffff 0000000000000000
>
> [ 12.487992][ T1] head: 0080000000000001 ffffea00000af681 dead000000000122 00000000ffffffff
>
> [ 12.488213][ T1] head: 0000000200000000 0000000000000000 00000000ffffffff 0000000000000000
>
> [ 12.488436][ T1] page dumped because: kasan: bad access detected
>
> [ 12.488590][ T1]
>
> [ 12.488653][ T1] Memory state around the buggy address:
>
> [ 12.488797][ T1] ffff888002bdb980: fc fc fc fc 00 00 00 00 00 00 00 00 00 00 00 00
>
> [ 12.488986][ T1] ffff888002bdba00: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
>
> [ 12.489168][ T1] >ffff888002bdba80: fc fc fc fc fc fc fc fc fc fc fc fa fb fb fb fb
>
> [ 12.489353][ T1] ^
>
> [ 12.489506][ T1] ffff888002bdbb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
> [ 12.489688][ T1] ffff888002bdbb80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> [ 12.489873][ T1] ==================================================================
>
On Fri, 22 Mar 2024 14:26:07 +0000 Eric Van Hensbergen wrote: > Patch is in the unapplied portion of my for-next tree along with > another one. I was hoping to hear some feedback on the other one > before i did a pull request and was torn on whether or not I wait on > -rc1 to send since we are so close. My guess would be that quite a few folks use 9p for in-VM kernel testing. Real question is how many actually update their work tree before -rc1 or even -rc2, given the anticipated merge window code instability.. so maybe there's no extreme urgency? From netdev's perspective, FWIW, it'd be great if the fix reached Linux before Thursday, which is when we will forward our tree again.
On Fri, 22 Mar 2024 08:13:12 -0700 Jakub Kicinski wrote: > On Fri, 22 Mar 2024 14:26:07 +0000 Eric Van Hensbergen wrote: > > Patch is in the unapplied portion of my for-next tree along with > > another one. I was hoping to hear some feedback on the other one > > before i did a pull request and was torn on whether or not I wait on > > -rc1 to send since we are so close. > > My guess would be that quite a few folks use 9p for in-VM kernel > testing. Real question is how many actually update their work tree > before -rc1 or even -rc2, given the anticipated merge window code > instability.. so maybe there's no extreme urgency? > > From netdev's perspective, FWIW, it'd be great if the fix reached > Linux before Thursday, which is when we will forward our tree again. Any progress on getting the fix to Linus? I didn't spot it getting merged. I'm a bit surprised there aren't more people complaining TBH I'd have thought any CI setup with KASAN enabled has a good chance of hitting this..
On Wed, Mar 27, 2024 at 11:53 AM Jakub Kicinski <kuba@kernel.org> wrote: > > On Fri, 22 Mar 2024 08:13:12 -0700 Jakub Kicinski wrote: > > On Fri, 22 Mar 2024 14:26:07 +0000 Eric Van Hensbergen wrote: > > > Patch is in the unapplied portion of my for-next tree along with > > > another one. I was hoping to hear some feedback on the other one > > > before i did a pull request and was torn on whether or not I wait on > > > -rc1 to send since we are so close. > > > > My guess would be that quite a few folks use 9p for in-VM kernel > > testing. Real question is how many actually update their work tree > > before -rc1 or even -rc2, given the anticipated merge window code > > instability.. so maybe there's no extreme urgency? > > > > From netdev's perspective, FWIW, it'd be great if the fix reached > > Linux before Thursday, which is when we will forward our tree again. > > Any progress on getting the fix to Linus? I didn't spot it getting > merged. > > I'm a bit surprised there aren't more people complaining TBH > I'd have thought any CI setup with KASAN enabled has a good > chance of hitting this.. The proposed fix is no brainer: https://lore.kernel.org/all/20240202121531.2550018-1-lizhi.xu@windriver.com/ + v9fs_stat2inode_dotl(st, inode, 0); kfree(st); if (retval) goto error; - v9fs_stat2inode_dotl(st, inode, 0); Please ship it to Linus asap. I'm surprised this bug slipped through. It does affect bpf developers and our CI, since we run with KASAN and use 9P.
diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c index ef9db3e03506..2b313fe7003e 100644 --- a/fs/9p/vfs_inode_dotl.c +++ b/fs/9p/vfs_inode_dotl.c @@ -78,11 +78,11 @@ struct inode *v9fs_fid_iget_dotl(struct super_block *sb, struct p9_fid *fid) retval = v9fs_init_inode(v9ses, inode, &fid->qid, st->st_mode, new_decode_dev(st->st_rdev)); + v9fs_stat2inode_dotl(st, inode, 0); kfree(st); if (retval) goto error; - v9fs_stat2inode_dotl(st, inode, 0); v9fs_set_netfs_context(inode); v9fs_cache_inode_get_cookie(inode); retval = v9fs_get_acl(inode, fid);
The incorrect logical order of accessing the st object code in v9fs_fid_iget_dotl is causing this uaf. Fixes: 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths") Reported-and-tested-by: syzbot+7a3d75905ea1a830dbe5@syzkaller.appspotmail.com Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com> --- fs/9p/vfs_inode_dotl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)