CVE-2024-46708 – pinctrl: qcom: x1e80100: Fix special pin offsets
https://notcve.org/view.php?id=CVE-2024-46708
In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: x1e80100: Fix special pin offsets Remove the erroneus 0x100000 offset to prevent the boards from crashing on pin state setting, as well as for the intended state changes to take effect. • https://git.kernel.org/stable/c/05e4941d97ef05ddaa742a57301daab8a2f7db5b https://git.kernel.org/stable/c/0197bf772f657fbdea5e9bdec5eea6e67d82cbde https://git.kernel.org/stable/c/d3692d95cc4d88114b070ee63cffc976f00f207f •
CVE-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 •
CVE-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 •
CVE-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 •
CVE-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 •