CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46797 – powerpc/qspinlock: Fix deadlock in MCS queue
https://notcve.org/view.php?id=CVE-2024-46797
In the Linux kernel, the following vulnerability has been resolved: powerpc/qspinlock: Fix deadlock in MCS queue If an interrupt occurs in queued_spin_lock_slowpath() after we increment qnodesp->count and before node->lock is initialized, another CPU might see stale lock values in get_tail_qnode(). If the stale lock value happens to match the lock on that CPU, then we write to the "next" pointer of the wrong qnode. This causes a deadlock as the former CPU, once it becomes the head of the MCS queue, will spin indefinitely until it's "next" pointer is set by its successor in the queue. Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in occasional lockups similar to the following: $ stress-ng --all 128 --vm-bytes 80% --aggressive \ --maximize --oomable --verify --syslog \ --metrics --times --timeout 5m watchdog: CPU 15 Hard LOCKUP ...... NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 Call Trace: 0xc000002cfffa3bf0 (unreliable) _raw_spin_lock+0x6c/0x90 raw_spin_rq_lock_nested.part.135+0x4c/0xd0 sched_ttwu_pending+0x60/0x1f0 __flush_smp_call_function_queue+0x1dc/0x670 smp_ipi_demux_relaxed+0xa4/0x100 xive_muxed_ipi_action+0x20/0x40 __handle_irq_event_percpu+0x80/0x240 handle_irq_event_percpu+0x2c/0x80 handle_percpu_irq+0x84/0xd0 generic_handle_irq+0x54/0x80 __do_irq+0xac/0x210 __do_IRQ+0x74/0xd0 0x0 do_IRQ+0x8c/0x170 hardware_interrupt_common_virt+0x29c/0x2a0 --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490 ...... NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 --- interrupt: 500 0xc0000029c1a41d00 (unreliable) _raw_spin_lock+0x6c/0x90 futex_wake+0x100/0x260 do_futex+0x21c/0x2a0 sys_futex+0x98/0x270 system_call_exception+0x14c/0x2f0 system_call_vectored_common+0x15c/0x2ec The following code flow illustrates how the deadlock occurs. For the sake of brevity, assume that both locks (A and B) are contended and we call the queued_spin_lock_slowpath() function. CPU0 CPU1 ---- ---- spin_lock_irqsave(A) | spin_unlock_irqrestore(A) | spin_lock(B) | | | ▼ | id = qnodesp->count++; | (Note that nodes[0].lock == A) | | | ▼ | Interrupt | (happens before "nodes[0].lock = B") | | | ▼ | spin_lock_irqsave(A) | | | ▼ | id = qnodesp->count++ | nodes[1].lock = A | | | ▼ | Tail of MCS queue | | spin_lock_irqsave(A) ▼ | Head of MCS queue ▼ | CPU0 is previous tail ▼ | Spin indefinitely ▼ (until "nodes[1].next != NULL") prev = get_tail_qnode(A, CPU0) | ▼ prev == &qnodes[CPU0].nodes[0] (as qnodes ---truncated--- • https://git.kernel.org/stable/c/84990b169557428c318df87b7836cd15f65b62dc https://git.kernel.org/stable/c/d84ab6661e8d09092de9b034b016515ef9b66085 https://git.kernel.org/stable/c/f06af737e4be28c0e926dc25d5f0a111da4e2987 https://git.kernel.org/stable/c/734ad0af3609464f8f93e00b6c0de1e112f44559 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46796 – smb: client: fix double put of @cfile in smb2_set_path_size()
https://notcve.org/view.php?id=CVE-2024-46796
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double put of @cfile in smb2_set_path_size() If smb2_compound_op() is called with a valid @cfile and returned -EINVAL, we need to call cifs_get_writable_path() before retrying it as the reference of @cfile was already dropped by previous call. This fixes the following KASAN splat when running fstests generic/013 against Windows Server 2022: CIFS: Attempting to mount //w22-fs0/scratch run fstests generic/013 at 2024-09-02 19:48:59 ================================================================== BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200 Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176 CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: cifsoplockd cifs_oplock_break [cifs] Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? detach_if_pending+0xab/0x200 print_report+0x156/0x4d9 ? detach_if_pending+0xab/0x200 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? • https://git.kernel.org/stable/c/1e60bc0e954389af82f1d9a85f13a63f6572350f https://git.kernel.org/stable/c/71f15c90e785d1de4bcd65a279e7256684c25c0d https://git.kernel.org/stable/c/5a72d1edb0843e4c927a4096f81e631031c25c28 https://git.kernel.org/stable/c/762099898309218b4a7954f3d49e985dc4dfd638 https://git.kernel.org/stable/c/f9c169b51b6ce20394594ef674d6b10efba31220 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46795 – ksmbd: unset the binding mark of a reused connection
https://notcve.org/view.php?id=CVE-2024-46795
In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset the binding mark of a reused connection Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generate_preauth_hash() will not set sess->Preauth_HashValue and it will be NULL. It is used as a material to create an encryption key in ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer dereference error from crypto_shash_update(). BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? • https://git.kernel.org/stable/c/f5a544e3bab78142207e0242d22442db85ba1eff https://git.kernel.org/stable/c/9914f1bd61d5e838bb1ab15a71076d37a6db65d1 https://git.kernel.org/stable/c/93d54a4b59c4b3d803d20aa645ab5ca71f3b3b02 https://git.kernel.org/stable/c/41bc256da7e47b679df87c7fc7a5b393052b9cce https://git.kernel.org/stable/c/4c8496f44f5bb5c06cdef5eb130ab259643392a1 https://git.kernel.org/stable/c/78c5a6f1f630172b19af4912e755e1da93ef0ab5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46794 – x86/tdx: Fix data leak in mmio_read()
https://notcve.org/view.php?id=CVE-2024-46794
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix data leak in mmio_read() The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM. Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM. This variable is only needed as an output value. It did not need to be passed to the VMM in the first place. Do not send the original value of *val to the VMM. [ dhansen: clarify what 'val' is used for. ] • https://git.kernel.org/stable/c/31d58c4e557d46fa7f8557714250fb6f89c941ae https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7 https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7 https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46791 – can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open
https://notcve.org/view.php?id=CVE-2024-46791
In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open The mcp251x_hw_wake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex. CPU0 CPU1 ---- ---- mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() <interrupt> mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlock Use disable_irq_nosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running. • https://git.kernel.org/stable/c/8ce8c0abcba314e1fe954a1840f6568bf5aef2ef https://git.kernel.org/stable/c/3a49b6b1caf5cefc05264d29079d52c99cb188e0 https://git.kernel.org/stable/c/513c8fc189b52f7922e36bdca58997482b198f0e https://git.kernel.org/stable/c/f7ab9e14b23a3eac6714bdc4dba244d8aa1ef646 https://git.kernel.org/stable/c/8fecde9c3f9a4b97b68bb97c9f47e5b662586ba7 https://git.kernel.org/stable/c/e554113a1cd2a9cfc6c7af7bdea2141c5757e188 https://git.kernel.org/stable/c/7dd9c26bd6cf679bcfdef01a8659791aa6487a29 •