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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46706 – tty: serial: fsl_lpuart: mark last busy before uart_add_one_port
https://notcve.org/view.php?id=CVE-2024-46706
In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: mark last busy before uart_add_one_port With "earlycon initcall_debug=1 loglevel=8" in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT. The lpuart driver has auto suspend delay set to 3000ms, but during uart_add_one_port, a child device serial ctrl will added and probed with its pm runtime enabled(see serial_ctrl.c). The runtime suspend call path is: device_add |-> bus_probe_device |->device_initial_probe |->__device_attach |-> pm_runtime_get_sync(dev->parent); |-> pm_request_idle(dev); |-> pm_runtime_put(dev->parent); So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang. To address the issue, mark last busy just after pm_runtime_enable, three seconds is long enough to switch from bootconsole to normal console. • https://git.kernel.org/stable/c/43543e6f539b3e646348c253059f75e27d63c94d https://git.kernel.org/stable/c/8eb92cfca6c2c5a15ab1773f3d18ab8d8f7dbb68 https://git.kernel.org/stable/c/3ecf625d4acb71d726bc0b49403cf68388b3d58d https://git.kernel.org/stable/c/dc98d76a15bc29a9a4e76f2f65f39f3e590fb15c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46705 – drm/xe: reset mmio mappings with devm
https://notcve.org/view.php?id=CVE-2024-46705
In the Linux kernel, the following vulnerability has been resolved: drm/xe: reset mmio mappings with devm Set our various mmio mappings to NULL. This should make it easier to catch something rogue trying to mess with mmio after device removal. For example, we might unmap everything and then start hitting some mmio address which has already been unmamped by us and then remapped by something else, causing all kinds of carnage. • https://git.kernel.org/stable/c/b1c9fbed3884d3883021d699c7cdf5253a65543a https://git.kernel.org/stable/c/c7117419784f612d59ee565145f722e8b5541fe6 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46703 – Revert "serial: 8250_omap: Set the console genpd always on if no console suspend"
https://notcve.org/view.php?id=CVE-2024-46703
In the Linux kernel, the following vulnerability has been resolved: Revert "serial: 8250_omap: Set the console genpd always on if no console suspend" This reverts commit 68e6939ea9ec3d6579eadeab16060339cdeaf940. Kevin reported that this causes a crash during suspend on platforms that dont use PM domains. • https://git.kernel.org/stable/c/68e6939ea9ec3d6579eadeab16060339cdeaf940 https://git.kernel.org/stable/c/321aecb079e9ca8b1af90778068a6fb40f2bf22d https://git.kernel.org/stable/c/0863bffda1131fd2fa9c05b653ad9ee3d8db127e •