CVE-2024-35971

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ks8851: maneja softirqs al final del subproceso IRQ para corregir el bloqueo. El subproceso ks8851_irq() puede llamar a ks8851_rx_pkts() en caso de que haya paquetes en MAC FIFO, que llama netif_rx(). Esta implementación de netif_rx() está protegida por local_bh_disable() y local_bh_enable(). local_bh_enable() puede llamar a do_softirq() para ejecutar softirqs en caso de que haya alguno pendiente. Uno de los softirqs es net_rx_action, que finalmente llega a la devolución de llamada .start_xmit del controlador. Si eso sucede, el sistema se bloquea. La cadena de llamadas completa está a continuación: ks8851_start_xmit_par de netdev_start_xmit netdev_start_xmit de dev_hard_start_xmit dev_hard_start_xmit de sch_direct_xmit sch_direct_xmit de __dev_queue_xmit __dev_queue_xmit de __neigh_update __neigh_update de neigh_update neigh_update de .constprop.0 arp_process.constprop.0 de __netif_receive_skb_one_core __netif_receive_skb_one_core de Process_backlog Process_backlog de __napi_poll.constprop.0 __napi_poll .constprop.0 de net_rx_action net_rx_action de __do_softirq __do_softirq de call_with_stack call_with_stack de do_softirq do_softirq de __local_bh_enable_ip __local_bh_enable_ip de netif_rx netif_rx de ks8851_irq ks8851_irq de irq_thread_fn _thread_fn de irq_thread irq_thread de kthread kthread de ret_from_fork El bloqueo ocurre porque ks8851_irq() primero bloquea un spinlock en ks8851_par. c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) y con ese spinlock bloqueado, llama a netif_rx(). Una vez que la ejecución llega a ks8851_start_xmit_par(), llama nuevamente a ks8851_lock_par(), lo que intenta reclamar el spinlock ya bloqueado nuevamente y se bloquea. Mueva la llamada do_softirq() fuera de la sección protegida por spinlock de ks8851_irq() deshabilitando los BH alrededor de toda la sección protegida por spinlock del controlador ks8851_irq(). Coloque local_bh_enable() fuera de la sección protegida de spinlock, para que pueda activar do_softirq() sin que se mantenga el spinlock ks8851_par.c ks8851_lock_par(), y llame de forma segura a ks8851_start_xmit_par() sin intentar bloquear el spinlock ya bloqueado. Dado que ks8851_irq() está protegido por local_bh_disable()/local_bh_enable() ahora, reemplace netif_rx() con __netif_rx() que no duplica las llamadas local_bh_disable()/local_bh_enable().

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(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens. Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock. Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls.

It was discovered that a race condition existed in the Bluetooth subsystem in the Linux kernel when modifying certain settings values through debugfs. A privileged local attacker could use this to cause a denial of service. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.