CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44954 – ALSA: line6: Fix racy access to midibuf
https://notcve.org/view.php?id=CVE-2024-44954
In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. • https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81 https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5 https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29 https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747 https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44953 – scsi: ufs: core: Fix deadlock during RTC update
https://notcve.org/view.php?id=CVE-2024-44953
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix deadlock during RTC update There is a deadlock when runtime suspend waits for the flush of RTC work, and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume. Here is deadlock backtrace: kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff <ffffffee5e71ddb0> __switch_to+0x1a8/0x2d4 <ffffffee5e71e604> __schedule+0x684/0xa98 <ffffffee5e71ea60> schedule+0x48/0xc8 <ffffffee5e725f78> schedule_timeout+0x48/0x170 <ffffffee5e71fb74> do_wait_for_common+0x108/0x1b0 <ffffffee5e71efe0> wait_for_completion+0x44/0x60 <ffffffee5d6de968> __flush_work+0x39c/0x424 <ffffffee5d6decc0> __cancel_work_sync+0xd8/0x208 <ffffffee5d6dee2c> cancel_delayed_work_sync+0x14/0x28 <ffffffee5e2551b8> __ufshcd_wl_suspend+0x19c/0x480 <ffffffee5e255fb8> ufshcd_wl_runtime_suspend+0x3c/0x1d4 <ffffffee5dffd80c> scsi_runtime_suspend+0x78/0xc8 <ffffffee5df93580> __rpm_callback+0x94/0x3e0 <ffffffee5df90b0c> rpm_suspend+0x2d4/0x65c <ffffffee5df91448> __pm_runtime_suspend+0x80/0x114 <ffffffee5dffd95c> scsi_runtime_idle+0x38/0x6c <ffffffee5df912f4> rpm_idle+0x264/0x338 <ffffffee5df90f14> __pm_runtime_idle+0x80/0x110 <ffffffee5e24ce44> ufshcd_rtc_work+0x128/0x1e4 <ffffffee5d6e3a40> process_one_work+0x26c/0x650 <ffffffee5d6e65c8> worker_thread+0x260/0x3d8 <ffffffee5d6edec8> kthread+0x110/0x134 <ffffffee5d616b18> ret_from_fork+0x10/0x20 Skip updating RTC if RPM state is not RPM_ACTIVE. • https://git.kernel.org/stable/c/6bf999e0eb41850d5c857102535d5c53b2ede224 https://git.kernel.org/stable/c/f13f1858a28c68b7fc0d72c2008d5c1f80d2e8d5 https://git.kernel.org/stable/c/3911af778f208e5f49d43ce739332b91e26bc48e •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-44952 – driver core: Fix uevent_show() vs driver detach race
https://notcve.org/view.php?id=CVE-2024-44952
In the Linux kernel, the following vulnerability has been resolved: driver core: Fix uevent_show() vs driver detach race uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock. This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. • https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0 https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-44951 – serial: sc16is7xx: fix TX fifo corruption
https://notcve.org/view.php?id=CVE-2024-44951
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: fix TX fifo corruption Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A. The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), which changed the EFR locking to operate on each channel instead of chip-wise. This commit has introduced a regression, because the EFR lock is used not only to protect the EFR registers access, but also, in a very obscure and undocumented way, to protect access to the data buffer, which is shared by the Tx and Rx handlers, but also by each channel of the IC. Fix this regression first by switching to kfifo_out_linear_ptr() in sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer. Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for each channel. • https://git.kernel.org/stable/c/4409df5866b7ff7686ba27e449ca97a92ee063c9 https://git.kernel.org/stable/c/4b068e55bf5ea7bab4d8a282c6a24b03e80c0b68 https://git.kernel.org/stable/c/9879e1bec3c0f077427dd0d258c80c63ce9babdf https://git.kernel.org/stable/c/dbe196ca489f3833e0f9eeb86ac346194f131c91 https://git.kernel.org/stable/c/09cfe05e9907f3276887a20e267cc40e202f4fdd https://git.kernel.org/stable/c/133f4c00b8b2bfcacead9b81e7e8edfceb4b06c4 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44950 – serial: sc16is7xx: fix invalid FIFO access with special register set
https://notcve.org/view.php?id=CVE-2024-44950
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: fix invalid FIFO access with special register set When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading. Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register set Fix the problem by claiming the efr_lock mutex when accessing the Special register set. • https://git.kernel.org/stable/c/dfeae619d781dee61666d5551b93ba3be755a86b https://git.kernel.org/stable/c/6a6730812220a9a5ce4003eb347da1ee5abd06b0 https://git.kernel.org/stable/c/7d3b793faaab1305994ce568b59d61927235f57b •