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: 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: 8EXPL: 0CVE-2024-50202 – nilfs2: propagate directory read errors from nilfs_find_entry()
https://notcve.org/view.php?id=CVE-2024-50202
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1242c81 https://git.kernel.org/stable/c/b4b3dc9e7e604be98a222e9f941f5e93798ca475 https://git.kernel.org/stable/c/c1d0476885d708a932980b0f28cd90d9bd71db39 https://git.kernel.org/stable/c/edf8146057264191d5bfe5b91773f13d936dadd3 https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989 https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a https://git.kernel.org/stable/c/efa810b15a25531cbc2f527330947b9fe •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50199 – mm/swapfile: skip HugeTLB pages for unuse_vma
https://notcve.org/view.php?id=CVE-2024-50199
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. • https://git.kernel.org/stable/c/0fe6e20b9c4c53b3e97096ee73a0857f60aad43f https://git.kernel.org/stable/c/ba7f982cdb37ff5a7739dec85d7325ea66fc1496 https://git.kernel.org/stable/c/417d5838ca73c6331ae2fe692fab6c25c00d9a0b https://git.kernel.org/stable/c/e41710f5a61aca9d6baaa8f53908a927dd9e7aa7 https://git.kernel.org/stable/c/6ec0fe3756f941f42f8c57156b8bdf2877b2ebaf https://git.kernel.org/stable/c/bed2b9037806c62166a0ef9a559a1e7e3e1275b8 https://git.kernel.org/stable/c/eb66a833cdd2f7302ee05d05e0fa12a2ca32eb87 https://git.kernel.org/stable/c/7528c4fb1237512ee18049f852f014eba •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50195 – posix-clock: Fix missing timespec64 check in pc_clock_settime()
https://notcve.org/view.php?id=CVE-2024-50195
In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. • https://git.kernel.org/stable/c/0606f422b453f76c31ab2b1bd52943ff06a2dcf2 https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584 https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512 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/1ff7247101af723731ea42ed565d54fb8 •