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/dd08ebf6c3525a7ea2186e636df064ea47281987 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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46702 – thunderbolt: Mark XDomain as unplugged when router is removed
https://notcve.org/view.php?id=CVE-2024-46702
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router. • https://git.kernel.org/stable/c/747bc154577de6e6af4bc99abfa859b8419bb4d8 https://git.kernel.org/stable/c/23ce6ba3b95488a2b9e9f6d43b340da0c15395dc https://git.kernel.org/stable/c/80ac8d194831eca0c2f4fd862f7925532fda320c https://git.kernel.org/stable/c/18b3ad2a3cc877dd4b16f48d84aa27b78d53bf1d https://git.kernel.org/stable/c/7ca24cf9163c112bb6b580c6fb57c04a1f8b76e1 https://git.kernel.org/stable/c/e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46701 – libfs: fix infinite directory reads for offset dir
https://notcve.org/view.php?id=CVE-2024-46701
In the Linux kernel, the following vulnerability has been resolved: libfs: fix infinite directory reads for offset dir After we switch tmpfs dir operations from simple_dir_operations to simple_offset_dir_operations, every rename happened will fill new dentry to dest dir's maple tree(&SHMEM_I(inode)->dir_offsets->mt) with a free key starting with octx->newx_offset, and then set newx_offset equals to free key + 1. This will lead to infinite readdir combine with rename happened at the same time, which fail generic/736 in xfstests(detail show as below). 1. create 5000 files(1 2 3...) under one dir 2. call readdir(man 3 readdir) once, and get one entry 3. rename(entry, "TEMPFILE"), then rename("TEMPFILE", entry) 4. loop 2~3, until readdir return nothing or we loop too many times(tmpfs break test with the second condition) We choose the same logic what commit 9b378f6ad48cf ("btrfs: fix infinite directory reads") to fix it, record the last_index when we open dir, and do not emit the entry which index >= last_index. The file->private_data now used in offset dir can use directly to do this, and we also update the last_index when we llseek the dir file. [brauner: only update last_index after seek when offset is zero like Jan suggested] • https://git.kernel.org/stable/c/a2e459555c5f9da3e619b7e47a63f98574dc75f1 https://git.kernel.org/stable/c/308b4fc2403b335894592ee9dc212a5e58bb309f https://git.kernel.org/stable/c/64a7ce76fb901bf9f9c36cf5d681328fc0fd4b5a •