From: Itaru Kitayama <itaru.kitayama@linux.dev>
To: v9fs@lists.linux.dev
Subject: 9P2000 bug in mainline
Date: Sun, 17 Mar 2024 00:15:07 +0900 [thread overview]
Message-ID: <ZfW3eyENMB1P5jLS@vm3> (raw)
Hi,
I bisected down to this commit in Linus's tree:
[724a08450f74b02bd89078a596fd24857827c012] fs/9p: simplify iget to remove unnecessary paths
9P2000 stopped working on FVP with the arm64 kernel.
# mount -t 9p FM /mnt
[ 99.367520] ==================================================================
[ 99.367817] BUG: KASAN: slab-use-after-free in v9fs_stat2inode_dotl+0x818/0x9a0
[ 99.368266] Read of size 8 at addr ffff0008068a99a8 by task mount/165
[ 99.368608]
[ 99.368787] CPU: 1 PID: 165 Comm: mount Not tainted 6.8.0-rc1-00008-gbe57855f5050 #99
[ 99.369190] Hardware name: FVP Base RevC (DT)
[ 99.369442] Call trace:
[ 99.369637] dump_backtrace+0x94/0xf0
[ 99.369960] show_stack+0x1c/0x2c
[ 99.370265] dump_stack_lvl+0xb0/0x14c
[ 99.370644] print_report+0xdc/0x578
[ 99.371010] kasan_report+0xb4/0x100
[ 99.371378] __asan_report_load8_noabort+0x24/0x34
[ 99.371807] v9fs_stat2inode_dotl+0x818/0x9a0
[ 99.372193] v9fs_fid_iget_dotl+0x174/0x208
[ 99.372576] v9fs_mount+0x37c/0x740
[ 99.372921] legacy_get_tree+0xd4/0x198
[ 99.373301] vfs_get_tree+0x78/0x284
[ 99.373637] path_mount+0x738/0x1500
[ 99.373958] __arm64_sys_mount+0x48c/0x5c4
[ 99.374297] invoke_syscall+0xd4/0x24c
[ 99.374690] el0_svc_common.constprop.0+0xb0/0x23c
[ 99.375128] do_el0_svc+0x44/0x60
[ 99.375514] el0_svc+0x3c/0x7c
[ 99.375893] el0t_64_sync_handler+0x128/0x134
[ 99.376232] el0t_64_sync+0x1b0/0x1b4
[ 99.376552]
[ 99.376724] Allocated by task 165 on cpu 1 at 99.359984s:
[ 99.377046] kasan_save_stack+0x40/0x6c
[ 99.377402] kasan_save_track+0x24/0x44
[ 99.377760] kasan_save_alloc_info+0x6c/0x80
[ 99.378164] __kasan_kmalloc+0xe0/0xe4
[ 99.378517] kmalloc_trace+0x164/0x300
[ 99.378874] p9_client_getattr_dotl+0x50/0x19c
[ 99.379269] v9fs_fid_iget_dotl+0xb4/0x208
[ 99.379641] v9fs_mount+0x37c/0x740
[ 99.379978] legacy_get_tree+0xd4/0x198
[ 99.380356] vfs_get_tree+0x78/0x284
[ 99.380678] path_mount+0x738/0x1500
[ 99.380992] __arm64_sys_mount+0x48c/0x5c4
[ 99.381322] invoke_syscall+0xd4/0x24c
[ 99.381713] el0_svc_common.constprop.0+0xb0/0x23c
[ 99.382137] do_el0_svc+0x44/0x60
[ 99.382516] el0_svc+0x3c/0x7c
[ 99.382892] el0t_64_sync_handler+0x128/0x134
[ 99.383217] el0t_64_sync+0x1b0/0x1b4
[ 99.383527]
[ 99.383699] Freed by task 165 on cpu 1 at 99.367506s:
[ 99.384014] kasan_save_stack+0x40/0x6c
[ 99.384371] kasan_save_track+0x24/0x44
[ 99.384729] kasan_save_free_info+0x54/0x90
[ 99.385130] poison_slab_object+0x118/0x16c
[ 99.385498] __kasan_slab_free+0x40/0x98
[ 99.385863] kfree+0xec/0x290
[ 99.386190] v9fs_fid_iget_dotl+0x138/0x208
[ 99.386564] v9fs_mount+0x37c/0x740
[ 99.386902] legacy_get_tree+0xd4/0x198
[ 99.387279] vfs_get_tree+0x78/0x284
[ 99.387602] path_mount+0x738/0x1500
[ 99.387915] __arm64_sys_mount+0x48c/0x5c4
[ 99.388246] invoke_syscall+0xd4/0x24c
[ 99.388637] el0_svc_common.constprop.0+0xb0/0x23c
[ 99.389061] do_el0_svc+0x44/0x60
[ 99.389439] el0_svc+0x3c/0x7c
[ 99.389815] el0t_64_sync_handler+0x128/0x134
[ 99.390135] el0t_64_sync+0x1b0/0x1b4
[ 99.390451]
[ 99.390622] The buggy address belongs to the object at ffff0008068a99a8
[ 99.390622] which belongs to the cache kmalloc-192 of size 192
[ 99.391063] The buggy address is located 0 bytes inside of
[ 99.391063] freed 192-byte region [ffff0008068a99a8, ffff0008068a9a68)
[ 99.391530]
[ 99.391703] The buggy address belongs to the physical page:
[ 99.391960] page:fffffc00201a2a00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0008068a9af0 pfn:0x8868a8
[ 99.392411] head:fffffc00201a2a00 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ 99.392784] flags: 0x5fffe0000000a40(workingset|slab|head|node=0|zone=2|lastcpupid=0xffff)
[ 99.393178] page_type: 0xffffffff()
[ 99.393490] raw: 05fffe0000000a40 ffff00080000ce40 ffff000800000850 ffff000800000850
[ 99.393884] raw: ffff0008068a9af0 0000000000180015 00000001ffffffff 0000000000000000
[ 99.394211] page dumped because: kasan: bad access detected
[ 99.394479]
[ 99.394650] Memory state around the buggy address:
[ 99.394921] ffff0008068a9880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 99.395270] ffff0008068a9900: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 99.395619] >ffff0008068a9980: fc fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb
[ 99.395935] ^
[ 99.396210] ffff0008068a9a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
[ 99.396558] ffff0008068a9a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 99.396874] ==================================================================
[ 99.397370] Disabling lock debugging due to kernel taint
next reply other threads:[~2024-03-19 2:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 15:15 Itaru Kitayama [this message]
2024-03-19 3:00 ` 9P2000 bug in mainline Eric Van Hensbergen
2024-03-19 10:49 ` Itaru Kitayama
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZfW3eyENMB1P5jLS@vm3 \
--to=itaru.kitayama@linux.dev \
--cc=v9fs@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox