CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35971 – net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
https://notcve.org/view.php?id=CVE-2024-35971
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below: ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). • https://git.kernel.org/stable/c/797047f875b5463719cc70ba213eb691d453c946 https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540 https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f http://www.openwall.com/lists/oss-security/2024/05/30/1 http://www.openwall.com/lists/oss-security/2024/05/30/2 •
CVSS: 6.3EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35970 – af_unix: Clear stale u->oob_skb.
https://notcve.org/view.php?id=CVE-2024-35970
In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. • https://git.kernel.org/stable/c/314001f0bf927015e459c9d387d62a231fe93af3 https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153 https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9 https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6 https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35969 – ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
https://notcve.org/view.php?id=CVE-2024-35969
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it still means hlist_for_each_entry_rcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane. In particular, the reference count can be zero. This can happen if ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough timing, this can happen: 1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry. 2. • https://git.kernel.org/stable/c/5c578aedcb21d79eeb4e9cf04ca5b276ac82614c https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1 https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903 https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70 https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652 https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35968 – pds_core: Fix pdsc_check_pci_health function to use work thread
https://notcve.org/view.php?id=CVE-2024-35968
In the Linux kernel, the following vulnerability has been resolved: pds_core: Fix pdsc_check_pci_health function to use work thread When the driver notices fw_status == 0xff it tries to perform a PCI reset on itself via pci_reset_function() in the context of the driver's health thread. However, pdsc_reset_prepare calls pdsc_stop_health_thread(), which attempts to stop/flush the health thread. This results in a deadlock because the stop/flush will never complete since the driver called pci_reset_function() from the health thread context. Fix by changing the pdsc_check_pci_health_function() to queue a newly introduced pdsc_pci_reset_thread() on the pdsc's work queue. Unloading the driver in the fw_down/dead state uncovered another issue, which can be seen in the following trace: WARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440 [...] RIP: 0010:__queue_work+0x358/0x440 [...] Call Trace: <TASK> ? __warn+0x85/0x140 ? • https://git.kernel.org/stable/c/d9407ff11809c6812bb84fe7be9c1367d758e5c8 https://git.kernel.org/stable/c/bd8740928aacda3d9a4cbb77e2ca3a951f20ba6b https://git.kernel.org/stable/c/46826a3844068c0d3919eb4a24c3ba7bf5d24449 https://git.kernel.org/stable/c/38407914d48273d7f8ab765b9243658afe1c3ab6 https://git.kernel.org/stable/c/81665adf25d28a00a986533f1d3a5df76b79cad9 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35967 – Bluetooth: SCO: Fix not validating setsockopt user input
https://notcve.org/view.php?id=CVE-2024-35967
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: SCO: la solución no valida la entrada del usuario de setsockopt. syzbot informó que sco_sock_setsockopt() está copiando datos sin verificar la longitud de la entrada del usuario. BUG: KASAN: slab fuera de los límites en copy_from_sockptr_offset include/linux/sockptr.h:49 [en línea] BUG: KASAN: slab fuera de los límites en copy_from_sockptr include/linux/sockptr.h:55 [en línea] BUG: KASAN: slab fuera de los límites en sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Lectura de tamaño 4 en la dirección ffff88805f7b15a3 mediante la tarea syz-executor.5/12578 • https://git.kernel.org/stable/c/b96e9c671b05f95126753a22145d4509d45ca197 https://git.kernel.org/stable/c/b0e30c37695b614bee69187f86eaf250e36606ce https://git.kernel.org/stable/c/7bc65d23ba20dcd7ecc094a12c181e594e5eb315 https://git.kernel.org/stable/c/72473db90900da970a16ee50ad23c2c38d107d8c https://git.kernel.org/stable/c/419a0ffca7010216f0fc265b08558d7394fa0ba7 https://git.kernel.org/stable/c/51eda36d33e43201e7a4fd35232e069b2c850b01 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •