CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50193 – x86/entry_32: Clear CPU buffers after register restore in NMI return
https://notcve.org/view.php?id=CVE-2024-50193
In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. • https://git.kernel.org/stable/c/50f021f0b985629accf10481a6e89af8b9700583 https://git.kernel.org/stable/c/d54de9f2a127090f2017184e8257795b487d5312 https://git.kernel.org/stable/c/2e3087505ddb8ba2d3d4c81306cca11e868fcdb9 https://git.kernel.org/stable/c/ca13d8cd8dac25558da4ee8df4dc70e8e7f9d762 https://git.kernel.org/stable/c/a0e2dab44d22b913b4c228c8b52b2a104434b0b3 https://git.kernel.org/stable/c/51eca9f1fd047b500137d021f882d93f03280118 https://git.kernel.org/stable/c/6f44a5fc15b5cece0785bc07453db77d99b0a6de https://git.kernel.org/stable/c/b6400eb0b347821efc57760221f8fb6d6 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50192 – irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
https://notcve.org/view.php?id=CVE-2024-50192
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. • https://git.kernel.org/stable/c/64edfaa9a2342a3ce34f8cb982c2c2df84db4de3 https://git.kernel.org/stable/c/b7d7b7fc876f836f40bf48a87e07ea18756ba196 https://git.kernel.org/stable/c/755b9532c885b8761fb135fedcd705e21e61cccb https://git.kernel.org/stable/c/64b12b061c5488e2d69e67c4eaae5da64fd30bfe https://git.kernel.org/stable/c/01282ab5182f85e42234df2ff42f0ce790f465ff https://git.kernel.org/stable/c/d960505a869e66184fff97fb334980a5b797c7c6 https://git.kernel.org/stable/c/1442ee0011983f0c5c4b92380e6853afb513841a •
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: 5EXPL: 0CVE-2024-50189 – HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
https://notcve.org/view.php?id=CVE-2024-50189
In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption. • https://git.kernel.org/stable/c/4b2c53d93a4bc9d52cc0ec354629cfc9dc217f93 https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276 https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93 https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47 https://git.kernel.org/stable/c/9dfee956f53eea96d93ef1e13ab4ce020f4c58b3 https://git.kernel.org/stable/c/c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50188 – net: phy: dp83869: fix memory corruption when enabling fiber
https://notcve.org/view.php?id=CVE-2024-50188
In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed. • https://git.kernel.org/stable/c/a29de52ba2a156873505d8b8cef44e69925b8114 https://git.kernel.org/stable/c/21b5af7f0c99b3bf1fd02016e6708b613acbcaf4 https://git.kernel.org/stable/c/ad0d76b8ee5db063791cc2e7a30ffc9852ac37c4 https://git.kernel.org/stable/c/c1944b4253649fc6f2fb53e7d6302eb414d2182c https://git.kernel.org/stable/c/9ca634676ff66e1d616259e136f96f96b2a1759a https://git.kernel.org/stable/c/e3f2de32dae35bc7d173377dc97b5bc9fcd9fc84 https://git.kernel.org/stable/c/a842e443ca8184f2dc82ab307b43a8b38defd6a5 •