CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41034 – nilfs2: fix kernel bug on rename operation of broken directory
https://notcve.org/view.php?id=CVE-2024-41034
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug on rename operation of broken directory Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size. This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories. Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot(). • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/ff9767ba2cb949701e45e6e4287f8af82986b703 https://git.kernel.org/stable/c/24c1c8566a9b6be51f5347be2ea76e25fc82b11e https://git.kernel.org/stable/c/a9a466a69b85059b341239766a10efdd3ee68a4b https://git.kernel.org/stable/c/7000b438dda9d0f41a956fc9bffed92d2eb6be0d https://git.kernel.org/stable/c/1a8879c0771a68d70ee2e5e66eea34207e8c6231 https://git.kernel.org/stable/c/60f61514374e4a0c3b65b08c6024dd7e26150bfd https://git.kernel.org/stable/c/298cd810d7fb687c90a14d8f9fd1b8719 •
CVSS: 6.7EPSS: 0%CPEs: 9EXPL: 0CVE-2024-41020 – filelock: Fix fcntl/close race recovery compat path
https://notcve.org/view.php?id=CVE-2024-41020
In the Linux kernel, the following vulnerability has been resolved: filelock: Fix fcntl/close race recovery compat path When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. An LSM can prevent the fcntl/close race cleanup path in fcntl_setlk() from working, leading to use-after-free read in lock_get_status() when reading /proc/locks. • https://git.kernel.org/stable/c/c293621bbf678a3d85e3ed721c3921c8a670610d https://git.kernel.org/stable/c/a561145f3ae973ebf3e0aee41624e92a6c5cb38d https://git.kernel.org/stable/c/4c43ad4ab41602201d34c66ac62130fe339d686f https://git.kernel.org/stable/c/911cc83e56a2de5a40758766c6a70d6998248860 https://git.kernel.org/stable/c/53e21cfa68a7d12de378b7116c75571f73e0dfa2 https://git.kernel.org/stable/c/f4d0775c6e2f1340ca0725f0337de149aaa989ca https://git.kernel.org/stable/c/73ae349534ebc377328e7d21891e589626c6e82c https://git.kernel.org/stable/c/5b0af8e4c70e4b884bb94ff5f0cd49ecf • CWE-667: Improper Locking •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-41017 – jfs: don't walk off the end of ealist
https://notcve.org/view.php?id=CVE-2024-41017
In the Linux kernel, the following vulnerability has been resolved: jfs: don't walk off the end of ealist Add a check before visiting the members of ea to make sure each ea stays within the ealist. • https://git.kernel.org/stable/c/7f91bd0f2941fa36449ce1a15faaa64f840d9746 https://git.kernel.org/stable/c/fc16776a82e8df97b6c4f9a10ba95aa44cef7ba5 https://git.kernel.org/stable/c/6386f1b6a10e5d1ddd03db4ff6dfc55d488852ce https://git.kernel.org/stable/c/7e21574195a45fc193555fa40e99fed16565ff7e https://git.kernel.org/stable/c/4e034f7e563ab723b93a59980e4a1bb33198ece8 https://git.kernel.org/stable/c/17440dbc66ab98b410514b04987f61deedb86751 https://git.kernel.org/stable/c/f4435f476b9bf059cd9e26a69f5b29c768d00375 https://git.kernel.org/stable/c/dbde7bc91093fa9c2410e418b236b70fd •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41016 – ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
https://notcve.org/view.php?id=CVE-2024-41016
In the Linux kernel, the following vulnerability has been resolved: ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry() xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images. • https://git.kernel.org/stable/c/e2b3d7a9d019d4d1a0da6c3ea64a1ff79c99c090 https://git.kernel.org/stable/c/e8f9c4af7af7e9e4cd09c0251c7936593147419f https://git.kernel.org/stable/c/57a3d89831fcaa2cdbe024b47c7c36d5a56c3637 https://git.kernel.org/stable/c/c031d286eceb82f72f8623b7f4abd2aa491bfb5e https://git.kernel.org/stable/c/cfb926051fab19b10d1e65976211f364aa820180 https://git.kernel.org/stable/c/c726dea9d0c806d64c26fcef483b1fb9474d8c5e https://git.kernel.org/stable/c/e4ffea01adf3323c821b6f37e9577d2d400adbaa https://git.kernel.org/stable/c/af77c4fc1871847b528d58b7fdafb4aa1 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-41015 – ocfs2: add bounds checking to ocfs2_check_dir_entry()
https://notcve.org/view.php?id=CVE-2024-41015
In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_check_dir_entry() This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region. • https://git.kernel.org/stable/c/13d38c00df97289e6fba2e54193959293fd910d2 https://git.kernel.org/stable/c/564d23cc5b216211e1694d53f7e45959396874d0 https://git.kernel.org/stable/c/77495e5da5cb110a8fed27b052c77853fe282176 https://git.kernel.org/stable/c/53de17ad01cb5f6f8426f597e9d5c87d4cf53bb7 https://git.kernel.org/stable/c/fd65685594ee707cbf3ddf22ebb73697786ac114 https://git.kernel.org/stable/c/e05a24289db90f76ff606086aadd62d068a88dcd https://git.kernel.org/stable/c/624b380074f0dc209fb8706db3295c735079f34c https://git.kernel.org/stable/c/edb2e67dd4626b06fd7eb37252d506791 •