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: 4EXPL: 0CVE-2024-50187 – drm/vc4: Stop the active perfmon before being destroyed
https://notcve.org/view.php?id=CVE-2024-50187
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. • https://git.kernel.org/stable/c/65101d8c9108201118efa7e08f4e2c57f438deb9 https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967 https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0 https://git.kernel.org/stable/c/c9adba739d5f7cdc47a7754df4a17b47b1ecf513 https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50185 – mptcp: handle consistently DSS corruption
https://notcve.org/view.php?id=CVE-2024-50185
In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type. • https://git.kernel.org/stable/c/6771bfd9ee2460c13e38c0cd46a3afb5404ae716 https://git.kernel.org/stable/c/fde99e972b8f88cebe619241d7aa43d288ef666a https://git.kernel.org/stable/c/12c1676d598e3b8dd92a033b623b792cc2ea1ec5 https://git.kernel.org/stable/c/35668f8ec84f6c944676e48ecc6bbc5fc8e6fe25 https://git.kernel.org/stable/c/b8be15d1ae7ea4eedd547c3b3141f592fbddcd30 https://git.kernel.org/stable/c/8bfd391bde685df7289b928ce8876a3583be4bfb https://git.kernel.org/stable/c/e32d262c89e2b22cb0640223f953b548617ed8a6 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50184 – virtio_pmem: Check device status before requesting flush
https://notcve.org/view.php?id=CVE-2024-50184
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. • https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36 https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4 https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4 https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50 •