summaryrefslogtreecommitdiff
path: root/scripts/basic/split-include.c
diff options
context:
space:
mode:
authorYuanfu Xie <yuanfuxie@stu.pku.edu.cn>2026-09-22 21:15:36 +0800
committerDominique Martinet <asmadeus@codewreck.org>2026-10-29 06:01:11 +0000
commitff1baa01a6e1f24741f7428119e6f3a61b995604 (patch)
tree2c761847022e5b2c97e92c536ce2d1f33174dda7 /scripts/basic/split-include.c
parent4e915aa8566173b44146bc46177c85afbe6bdf96 (diff)
downloadlinux-ff1baa01a6e1f24741f7428119e6f3a61b995604.tar.gz
linux-ff1baa01a6e1f24741f7428119e6f3a61b995604.zip
9p: fall back to the normal open path for non-regular files
v9fs_vfs_atomic_open() and v9fs_vfs_atomic_open_dotl() call finish_open(file, dentry, generic_file_open) regardless of the file type the server reported for the created dentry. The supplied callback replaces f_op->open in do_dentry_open(), so blkdev_open() never runs for a server-reported device node: an open() with O_CREAT succeeds with f_op = def_blk_fops while f_mapping still points at the 9p inode, because the bdev mapping swap only happens inside blkdev_open(). The block file methods then derive their block_device from that inode with I_BDEV(); the loads land at the tail of a 656-byte v9fs_inode_cache object (offsets +624 and +632), which KASAN reports as slab-out-of-bounds, and the garbage they read is then dereferenced, so the first read(), write(), ioctl() or close() ends in a NULL pointer write and a panic. In the ioctl(BLKGETSIZE64) variant the value read this way is returned to userspace. The server controls the file type reported for the create, so a malicious server can crash the client this way. KASAN report of the read() variant, on a build of linux-stable 2709dd5ae32f: BUG: KASAN: slab-out-of-bounds in blkdev_read_iter+0x3cd/0x440 Read of size 8 at addr ffff88800828ceb0 by task repro/1 Call Trace: <TASK> dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 blkdev_read_iter+0x3cd/0x440 vfs_read+0x718/0xa50 ksys_read+0x10f/0x200 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The buggy address belongs to the object at ffff88800828cc40 which belongs to the cache v9fs_inode_cache of size 656 The buggy address is located 624 bytes inside of allocated 656-byte region [ffff88800828cc40, ffff88800828ced0) A plain open() without O_CREAT is not affected: it runs blkdev_open() and either maps the device correctly or fails with -ENXIO for an rdev with no registered device. When the created inode is not a regular file, clunk the fid the create opened. The unopened fid is already on the dentry. Set FMODE_CREATED and return finish_no_open(file, NULL) so the VFS keeps its dentry reference and calls the inode's ->open. Regular files still use finish_open() with generic_file_open. Fixes: be12af3ef5e6 ("getting rid of 'opened' argument of ->atomic_open() - part 1") Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn> Message-ID: <908FC420-EC1F-46FC-8526-698F646961A8@stu.pku.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Diffstat (limited to 'scripts/basic/split-include.c')
0 files changed, 0 insertions, 0 deletions