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: 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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46698 – video/aperture: optionally match the device in sysfb_disable()
https://notcve.org/view.php?id=CVE-2024-46698
In the Linux kernel, the following vulnerability has been resolved: video/aperture: optionally match the device in sysfb_disable() In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. • https://git.kernel.org/stable/c/5ae3716cfdcd286268133867f67d0803847acefc https://git.kernel.org/stable/c/485ec8f8e1d8ae12aa1daa5ad345ba8940ad2db7 https://git.kernel.org/stable/c/17e78f43de0c6da34204cc858b4cc05671ea9acf https://git.kernel.org/stable/c/b49420d6a1aeb399e5b107fc6eb8584d0860fbd7 •