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: 5EXPL: 0CVE-2024-50191 – ext4: don't set SB_RDONLY after filesystem errors
https://notcve.org/view.php?id=CVE-2024-50191
In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that. • https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d https://git.kernel.org/stable/c/4061e07f040a091f694f461b86a26cf95ae66439 https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9 https://git.kernel.org/stable/c/ee77c388469116565e009eaa704a60bc78489e09 https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50183 – scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance
https://notcve.org/view.php?id=CVE-2024-50183
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue. • https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6 https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9 https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50181 – clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D
https://notcve.org/view.php?id=CVE-2024-50181
In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang. • https://git.kernel.org/stable/c/b677b94a9193ec7b6607bd1255172ae59174a382 https://git.kernel.org/stable/c/d18dc8e14b9c794f58dae1577ccb2ab84a4a1b11 https://git.kernel.org/stable/c/11ceb17e6f07cc30410f3a6276cddda248a9b863 https://git.kernel.org/stable/c/339273a9ddfe7632b717c2e13e81cbd5d383e1ff https://git.kernel.org/stable/c/94f6cdc837e38371324cee97dfd2ef1a99a82c98 https://git.kernel.org/stable/c/a54c441b46a0745683c2eef5a359d22856d27323 •