CVSS: -EPSS: %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: %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: %CPEs: 3EXPL: 0CVE-2024-50216 – xfs: fix finding a last resort AG in xfs_filestream_pick_ag
https://notcve.org/view.php?id=CVE-2024-50216
In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory. • https://git.kernel.org/stable/c/f8f1ed1ab3babad46b25e2dbe8de43b33fe7aaa6 https://git.kernel.org/stable/c/77ddc732416b017180893cbb2356e9f0a414c575 https://git.kernel.org/stable/c/a023408925acd64db5c8980373fcb3e28ec6fd29 https://git.kernel.org/stable/c/dc60992ce76fbc2f71c2674f435ff6bde2108028 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-50215 – nvmet-auth: assign dh_key to NULL after kfree_sensitive
https://notcve.org/view.php?id=CVE-2024-50215
In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace. • https://git.kernel.org/stable/c/7a277c37d3522e9b2777d762bbbcecafae2b1f8d https://git.kernel.org/stable/c/c94e965f766321641ec38e4eece9ce8884543244 https://git.kernel.org/stable/c/c60af16e1d6cc2237d58336546d6adfc067b6b8f https://git.kernel.org/stable/c/e61bd51e44409495d75847e9230736593e4c8710 https://git.kernel.org/stable/c/d2f551b1f72b4c508ab9298419f6feadc3b5d791 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-50212 – lib: alloc_tag_module_unload must wait for pending kfree_rcu calls
https://notcve.org/view.php?id=CVE-2024-50212
In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment] • https://git.kernel.org/stable/c/a473573964e51dcb6efc182f773cd3924be4a184 https://git.kernel.org/stable/c/24211fb49c9ac1b576470b7e393a5a0b50af2707 https://git.kernel.org/stable/c/dc783ba4b9df3fb3e76e968b2cbeb9960069263c •