[syzbot] [v9fs?] KASAN: slab-use-after-free Read in v9fs_stat2inode_dotl

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 596764183be8 Add linux-next specific files for 20240129
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1612e22fe80000
kernel config: https://syzkaller.appspot.com/x/.config?x=584144ad19f381aa
dashboard link: https://syzkaller.appspot.com/bug?extid=7a3d75905ea1a830dbe5
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12251228180000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1641bcdfe80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b647c038857b/disk-59676418.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/729e26c3ac55/vmlinux-59676418.xz
kernel image: https://storage.googleapis.com/syzbot-assets/15aa5e287059/bzImage-59676418.xz

The issue was bisected to:

commit 724a08450f74b02bd89078a596fd24857827c012
Author: Eric Van Hensbergen <eri...@kernel.org>
Date: Fri Jan 5 22:25:39 2024 +0000

fs/9p: simplify iget to remove unnecessary paths

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=165c6d0fe80000
final oops: https://syzkaller.appspot.com/x/report.txt?x=155c6d0fe80000
console output: https://syzkaller.appspot.com/x/log.txt?x=115c6d0fe80000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7a3d75...@syzkaller.appspotmail.com
Fixes: 724a08450f74 ("fs/9p: simplify iget to remove unnecessary paths")

==================================================================
BUG: KASAN: slab-use-after-free in v9fs_stat2inode_dotl+0xb3f/0xce0 fs/9p/vfs_inode_dotl.c:569
Read of size 8 at addr ffff8880172d4bb0 by task syz-executor117/5063

CPU: 1 PID: 5063 Comm: syz-executor117 Not tainted 6.8.0-rc1-next-20240129-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc3/0x620 mm/kasan/report.c:488
kasan_report+0xd9/0x110 mm/kasan/report.c:601
v9fs_stat2inode_dotl+0xb3f/0xce0 fs/9p/vfs_inode_dotl.c:569
v9fs_fid_iget_dotl+0x1cb/0x260 fs/9p/vfs_inode_dotl.c:85
v9fs_get_inode_from_fid fs/9p/v9fs.h:230 [inline]
v9fs_mount+0x515/0xa90 fs/9p/vfs_super.c:142
legacy_get_tree+0x109/0x220 fs/fs_context.c:662
vfs_get_tree+0x8f/0x380 fs/super.c:1784
do_new_mount fs/namespace.c:3352 [inline]
path_mount+0x14e6/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount fs/namespace.c:3875 [inline]
__x64_sys_mount+0x297/0x320 fs/namespace.c:3875
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd2/0x260 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7f88a76d7b69
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff734da2a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f88a76d7b69
RDX: 0000000020004500 RSI: 00000000200002c0 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000020000300 R09: 00007fff734da2e0
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff734da2e0
R13: 00007fff734da568 R14: 431bde82d7b634db R15: 00007f88a7720074
</TASK>

Allocated by task 5063:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:389
kmalloc include/linux/slab.h:590 [inline]
p9_client_getattr_dotl+0x4c/0x1e0 net/9p/client.c:1726
v9fs_fid_iget_dotl+0xe7/0x260 fs/9p/vfs_inode_dotl.c:73
v9fs_get_inode_from_fid fs/9p/v9fs.h:230 [inline]
v9fs_mount+0x515/0xa90 fs/9p/vfs_super.c:142
legacy_get_tree+0x109/0x220 fs/fs_context.c:662
vfs_get_tree+0x8f/0x380 fs/super.c:1784
do_new_mount fs/namespace.c:3352 [inline]
path_mount+0x14e6/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount fs/namespace.c:3875 [inline]
__x64_sys_mount+0x297/0x320 fs/namespace.c:3875
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd2/0x260 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x6d/0x75

Freed by task 5063:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x121/0x1c0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2122 [inline]
slab_free mm/slub.c:4296 [inline]
kfree+0x129/0x370 mm/slub.c:4406
v9fs_fid_iget_dotl+0x195/0x260 fs/9p/vfs_inode_dotl.c:81
v9fs_get_inode_from_fid fs/9p/v9fs.h:230 [inline]
v9fs_mount+0x515/0xa90 fs/9p/vfs_super.c:142
legacy_get_tree+0x109/0x220 fs/fs_context.c:662
vfs_get_tree+0x8f/0x380 fs/super.c:1784
do_new_mount fs/namespace.c:3352 [inline]
path_mount+0x14e6/0x1f20 fs/namespace.c:3679
do_mount fs/namespace.c:3692 [inline]
__do_sys_mount fs/namespace.c:3898 [inline]
__se_sys_mount fs/namespace.c:3875 [inline]
__x64_sys_mount+0x297/0x320 fs/namespace.c:3875
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xd2/0x260 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x6d/0x75

The buggy address belongs to the object at ffff8880172d4bb0
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 0 bytes inside of
freed 192-byte region [ffff8880172d4bb0, ffff8880172d4c70)

The buggy address belongs to the physical page:
page:ffffea00005cb500 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x172d4
flags: 0xfff80000000800(slab|node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffffff()
raw: 00fff80000000800 ffff888014c41a00 ffffea00005fa5c0 dead000000000004
raw: 0000000000000000 00000000800f000f 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 7, tgid 7 (kworker/0:0), ts 3076962571, free_ts 0
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x2d4/0x350 mm/page_alloc.c:1539
prep_new_page mm/page_alloc.c:1546 [inline]
get_page_from_freelist+0xa19/0x3740 mm/page_alloc.c:3353
__alloc_pages+0x22e/0x2420 mm/page_alloc.c:4609
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page mm/slub.c:2191 [inline]
allocate_slab mm/slub.c:2354 [inline]
new_slab+0xcc/0x3a0 mm/slub.c:2407
___slab_alloc+0x66d/0x17a0 mm/slub.c:3541
__slab_alloc.constprop.0+0x56/0xb0 mm/slub.c:3626
__slab_alloc_node mm/slub.c:3679 [inline]
slab_alloc_node mm/slub.c:3851 [inline]
kmalloc_node_trace+0x113/0x390 mm/slub.c:4021
kmalloc_node include/linux/slab.h:606 [inline]
kzalloc_node include/linux/slab.h:722 [inline]
alloc_worker+0x40/0x1b0 kernel/workqueue.c:2078
create_worker+0xf3/0x730 kernel/workqueue.c:2186
maybe_create_worker kernel/workqueue.c:2468 [inline]
manage_workers kernel/workqueue.c:2520 [inline]
worker_thread+0xca1/0x1290 kernel/workqueue.c:2766
kthread+0x2c1/0x3a0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:242
page_owner free stack trace missing

Memory state around the buggy address:
ffff8880172d4a80: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880172d4b00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>ffff8880172d4b80: fc fc fc fc fc fc fa fb fb fb fb fb fb fb fb fb
^
ffff8880172d4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
ffff8880172d4c80: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[syzbot]

For archival purposes, forwarding an incoming command email to
syzkall...@googlegroups.com.

***

Subject: Re: [syzbot] [v9fs?] KASAN: slab-use-after-free Read in v9fs_stat2inode_dotl
Author: lizh...@windriver.com

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
index ef9db3e03506..6ad86b604877 100644
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -82,7 +82,6 @@ struct inode *v9fs_fid_iget_dotl(struct super_block *sb, struct p9_fid *fid)
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);

[syzbot]

For archival purposes, forwarding an incoming command email to
syzkall...@googlegroups.com.

***

Subject: Re: [syzbot] [v9fs?] KASAN: slab-use-after-free Read in v9fs_stat2inode_dotl
Author: lizh...@windriver.com

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

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);

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+7a3d75...@syzkaller.appspotmail.com

Tested on:

commit: 076d56d7 Add linux-next specific files for 20240202
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=14811f1fe80000
kernel config: https://syzkaller.appspot.com/x/.config?x=4eccd90d3ac887b2
dashboard link: https://syzkaller.appspot.com/bug?extid=7a3d75905ea1a830dbe5
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=15f20a38180000

Note: testing is done by a robot and is best-effort only.

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+7a3d75...@syzkaller.appspotmail.com

Tested on:

commit: 076d56d7 Add linux-next specific files for 20240202
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

console output: https://syzkaller.appspot.com/x/log.txt?x=172cf5b0180000

kernel config: https://syzkaller.appspot.com/x/.config?x=4eccd90d3ac887b2
dashboard link: https://syzkaller.appspot.com/bug?extid=7a3d75905ea1a830dbe5
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

patch: https://syzkaller.appspot.com/x/patch.diff?x=108fe43fe80000

[Lizhi Xu]

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+7a3d75...@syzkaller.appspotmail.com
Signed-off-by: Lizhi Xu <lizh...@windriver.com>
---
fs/9p/vfs_inode_dotl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

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);

--
2.43.0

[Breno Leitao]

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+7a3d75...@syzkaller.appspotmail.com
> Signed-off-by: Lizhi Xu <lizh...@windriver.com>

Tested-by: Breno Leitao <lei...@debian.org>

[asma...@codewreck.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+7a3d75...@syzkaller.appspotmail.com
> Signed-off-by: Lizhi Xu <lizh...@windriver.com>

Reviewed-by: Dominique Martinet <asma...@codewreck.org>

--
Dominique Martinet | Asmadeus

[Jakub Kicinski]

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] ==================================================================

[Jakub Kicinski]

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.

[Eric Van Hensbergen]

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

[Jakub Kicinski]

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..

[Alexei Starovoitov]

The proposed fix is no brainer:
https://lore.kernel.org/all/20240202121531.2...@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.