CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50228 – mm: shmem: fix data-race in shmem_getattr()
https://notcve.org/view.php?id=CVE-2024-50228
In the Linux kernel, the following vulnerability has been resolved: mm: shmem: fix data-race in shmem_getattr() I got the following KCSAN report during syzbot testing: ================================================================== BUG: KCSAN: data-race in generic_fillattr / inode_set_ctime_current write to 0xffff888102eb3260 of 4 bytes by task 6565 on cpu 1: inode_set_ctime_to_ts include/linux/fs.h:1638 [inline] inode_set_ctime_current+0x169/0x1d0 fs/inode.c:2626 shmem_mknod+0x117/0x180 mm/shmem.c:3443 shmem_create+0x34/0x40 mm/shmem.c:3497 lookup_open fs/namei.c:3578 [inline] open_last_lookups fs/namei.c:3647 [inline] path_openat+0xdbc/0x1f00 fs/namei.c:3883 do_filp_open+0xf7/0x200 fs/namei.c:3913 do_sys_openat2+0xab/0x120 fs/open.c:1416 do_sys_open fs/open.c:1431 [inline] __do_sys_openat fs/open.c:1447 [inline] __se_sys_openat fs/open.c:1442 [inline] __x64_sys_openat+0xf3/0x120 fs/open.c:1442 x64_sys_call+0x1025/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:258 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff888102eb3260 of 4 bytes by task 3498 on cpu 0: inode_get_ctime_nsec include/linux/fs.h:1623 [inline] inode_get_ctime include/linux/fs.h:1629 [inline] generic_fillattr+0x1dd/0x2f0 fs/stat.c:62 shmem_getattr+0x17b/0x200 mm/shmem.c:1157 vfs_getattr_nosec fs/stat.c:166 [inline] vfs_getattr+0x19b/0x1e0 fs/stat.c:207 vfs_statx_path fs/stat.c:251 [inline] vfs_statx+0x134/0x2f0 fs/stat.c:315 vfs_fstatat+0xec/0x110 fs/stat.c:341 __do_sys_newfstatat fs/stat.c:505 [inline] __se_sys_newfstatat+0x58/0x260 fs/stat.c:499 __x64_sys_newfstatat+0x55/0x70 fs/stat.c:499 x64_sys_call+0x141f/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:263 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e value changed: 0x2755ae53 -> 0x27ee44d3 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 3498 Comm: udevd Not tainted 6.11.0-rc6-syzkaller-00326-gd1f2d51b711a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 ================================================================== When calling generic_fillattr(), if you don't hold read lock, data-race will occur in inode member variables, which can cause unexpected behavior. Since there is no special protection when shmem_getattr() calls generic_fillattr(), data-race occurs by functions such as shmem_unlink() or shmem_mknod(). This can cause unexpected results, so commenting it out is not enough. Therefore, when calling generic_fillattr() from shmem_getattr(), it is appropriate to protect the inode using inode_lock_shared() and inode_unlock_shared() to prevent data-race. • https://git.kernel.org/stable/c/44a30220bc0a171c010e8df63d144655abdafe61 https://git.kernel.org/stable/c/9fb9703cd43ee20a6de8ccdef991677b7274cec0 https://git.kernel.org/stable/c/7cc30ada84323be19395094d567579536e0d187e https://git.kernel.org/stable/c/bda1a99a0dd644f31a87d636ac624eeb975cb65a https://git.kernel.org/stable/c/3d9528484480e8f4979b3a347930ed383be99f89 https://git.kernel.org/stable/c/82cae1e30bd940253593c2d4f16d88343d1358f4 https://git.kernel.org/stable/c/edd1f905050686fdc4cfe233d818469fdf7d5ff8 https://git.kernel.org/stable/c/ffd56612566bc23877c8f45def2801f33 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50218 – ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
https://notcve.org/view.php?id=CVE-2024-50218
In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are "unsigned int". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL. • https://git.kernel.org/stable/c/1afc32b952335f665327a1a9001ba1b44bb76fd9 https://git.kernel.org/stable/c/27d95867bee806cdc448d122bd99f1d8b0544035 https://git.kernel.org/stable/c/95fbed8ae8c32c0977e6be1721c190d8fea23f2f https://git.kernel.org/stable/c/70767689ec6ee5f05fb0a2c17d7ec1927946e486 https://git.kernel.org/stable/c/ecd62f684386fa64f9c0cea92eea361f4e6444c2 https://git.kernel.org/stable/c/2fe5d62e122b040ce7fc4d31aa7fa96ae328cefc https://git.kernel.org/stable/c/88f97a4b5843ce21c1286e082c02a5fb4d8eb473 https://git.kernel.org/stable/c/0b6b8c2055784261de3fb641c5d0d6396 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50217 – btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()
https://notcve.org/view.php?id=CVE-2024-50217
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). • https://git.kernel.org/stable/c/142388194191a3edc9ba01cfcfd8b691e0971fb2 https://git.kernel.org/stable/c/47a83f8df39545f3f552bb6a1b6d9c30e37621dd https://git.kernel.org/stable/c/aec8e6bf839101784f3ef037dcdb9432c3f32343 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50211 – udf: refactor inode_bmap() to handle error
https://notcve.org/view.php?id=CVE-2024-50211
In the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. • https://git.kernel.org/stable/c/493447dd8336607fce426f7879e581095f6c606e https://git.kernel.org/stable/c/b22d9a5698abf04341f8fbc30141e0673863c3a6 https://git.kernel.org/stable/c/c226964ec786f3797ed389a16392ce4357697d24 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50210 – posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
https://notcve.org/view.php?id=CVE-2024-50210
In the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that. [pabeni@redhat.com: fixed commit message typo] • https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073 https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01 https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2 https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264 https://git.kernel.org/stable/c/d8794ac20a299b647ba9958f6d657051fc51a540 https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943 https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593a •