CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46713 – perf/aux: Fix AUX buffer serialization
https://notcve.org/view.php?id=CVE-2024-46713
In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. • https://git.kernel.org/stable/c/45bfb2e50471abbbfd83d40d28c986078b0d24ff https://git.kernel.org/stable/c/7882923f1cb88dc1a17f2bf0c81b1fc80d44db82 https://git.kernel.org/stable/c/52d13d224fdf1299c8b642807fa1ea14d693f5ff https://git.kernel.org/stable/c/9dc7ad2b67772cfb94ceb3b0c9c4023c2463215d https://git.kernel.org/stable/c/c4b69bee3f4ef76809288fe6827bc14d4ae788ef https://git.kernel.org/stable/c/b9b6882e243b653d379abbeaa64a500182aba370 https://git.kernel.org/stable/c/2ab9d830262c132ab5db2f571003d80850d56b2a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46711 – mptcp: pm: fix ID 0 endp usage after multiple re-creations
https://notcve.org/view.php?id=CVE-2024-46711
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix ID 0 endp usage after multiple re-creations 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. • https://git.kernel.org/stable/c/3ad14f54bd7448384458e69f0183843f683ecce8 https://git.kernel.org/stable/c/c9c744666f7308a4daba520191e29d395260bcfe https://git.kernel.org/stable/c/53e2173172d26c0617b29dd83618b71664bed1fb https://git.kernel.org/stable/c/119806ae4e46cf239db8e6ad92bc2fd3daae86dc https://git.kernel.org/stable/c/9366922adc6a71378ca01f898c41be295309f044 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46710 – drm/vmwgfx: Prevent unmapping active read buffers
https://notcve.org/view.php?id=CVE-2024-46710
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Prevent unmapping active read buffers The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus. Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0. • https://git.kernel.org/stable/c/485d98d472d53f9617ffdfba5e677ac29ad4fe20 https://git.kernel.org/stable/c/58a3714db4d9dcaeb9fc4905141e17b9f536c0a5 https://git.kernel.org/stable/c/0851b1ec650adadcaa23ec96daad95a55bf966f0 https://git.kernel.org/stable/c/d5228d158e4c0b1663b3983044913c15c3d0135e https://git.kernel.org/stable/c/aba07b9a0587f50e5d3346eaa19019cf3f86c0ea •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46709 – drm/vmwgfx: Fix prime with external buffers
https://notcve.org/view.php?id=CVE-2024-46709
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix prime with external buffers Make sure that for external buffers mapping goes through the dma_buf interface instead of trying to access pages directly. External buffers might not provide direct access to readable/writable pages so to make sure the bo's created from external dma_bufs can be read dma_buf interface has to be used. Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't trigger this due to the fact that virtual machines will not have multiple GPUs but it enables better test coverage in IGT. • https://git.kernel.org/stable/c/65674218b43f2dd54587ab2b06560e17c30d8b41 https://git.kernel.org/stable/c/b32233accefff1338806f064fb9b62cf5bc0609f https://git.kernel.org/stable/c/2cdb71c975a10b8774fcd199f16f9ea88948de50 https://git.kernel.org/stable/c/9a9716bbbf3dd6b6cbefba3abcc89af8b72631f4 https://git.kernel.org/stable/c/5c12391ee1ab59cb2f3be3f1f5e6d0fc0c2dc854 https://git.kernel.org/stable/c/50f1199250912568606b3778dc56646c10cb7b04 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46707 – KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
https://notcve.org/view.php?id=CVE-2024-46707
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception. • https://git.kernel.org/stable/c/15818af2f7aa55eff375333cb7689df15d3f24ef https://git.kernel.org/stable/c/96b076e8ee5bc3a1126848c8add0f74bd30dc9d1 https://git.kernel.org/stable/c/94d4fbad01b19ec5eab3d6b50aaec4f9db8b2d8d https://git.kernel.org/stable/c/9d7629bec5c3f80bd0e3bf8103c06a2f7046bd92 https://git.kernel.org/stable/c/2073132f6ed3079369e857a8deb33d11bdd983bc https://git.kernel.org/stable/c/3e6245ebe7ef341639e9a7e402b3ade8ad45a19f •