fkie_cve-2024-35971
Vulnerability from fkie_nvd
Published
2024-05-20 10:15
Modified
2024-11-21 09:21
Severity ?
Summary
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.
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Handle softirqs at the end of IRQ thread to fix hang\n\nThe ks8851_irq() thread may call ks8851_rx_pkts() in case there are\nany packets in the MAC FIFO, which calls netif_rx(). This netif_rx()\nimplementation is guarded by local_bh_disable() and local_bh_enable().\nThe local_bh_enable() may call do_softirq() to run softirqs in case\nany are pending. One of the softirqs is net_rx_action, which ultimately\nreaches the driver .start_xmit callback. If that happens, the system\nhangs. The entire call chain is below:\n\nks8851_start_xmit_par from netdev_start_xmit\nnetdev_start_xmit from dev_hard_start_xmit\ndev_hard_start_xmit from sch_direct_xmit\nsch_direct_xmit from __dev_queue_xmit\n__dev_queue_xmit from __neigh_update\n__neigh_update from neigh_update\nneigh_update from arp_process.constprop.0\narp_process.constprop.0 from __netif_receive_skb_one_core\n__netif_receive_skb_one_core from process_backlog\nprocess_backlog from __napi_poll.constprop.0\n__napi_poll.constprop.0 from net_rx_action\nnet_rx_action from __do_softirq\n__do_softirq from call_with_stack\ncall_with_stack from do_softirq\ndo_softirq from __local_bh_enable_ip\n__local_bh_enable_ip from netif_rx\nnetif_rx from ks8851_irq\nks8851_irq from irq_thread_fn\nirq_thread_fn from irq_thread\nirq_thread from kthread\nkthread from ret_from_fork\n\nThe hang happens because ks8851_irq() first locks a spinlock in\nks8851_par.c ks8851_lock_par() spin_lock_irqsave(\u0026ksp-\u003elock, ...)\nand with that spinlock locked, calls netif_rx(). Once the execution\nreaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again\nwhich attempts to claim the already locked spinlock again, and the\nhang happens.\n\nMove the do_softirq() call outside of the spinlock protected section\nof ks8851_irq() by disabling BHs around the entire spinlock protected\nsection of ks8851_irq() handler. Place local_bh_enable() outside of\nthe spinlock protected section, so that it can trigger do_softirq()\nwithout the ks8851_par.c ks8851_lock_par() spinlock being held, and\nsafely call ks8851_start_xmit_par() without attempting to lock the\nalready locked spinlock.\n\nSince ks8851_irq() is protected by local_bh_disable()/local_bh_enable()\nnow, replace netif_rx() with __netif_rx() which is not duplicating the\nlocal_bh_disable()/local_bh_enable() calls." }, { "lang": "es", "value": "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\u00f3n de netif_rx() est\u00e1 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\u00f3n de llamada .start_xmit del controlador. Si eso sucede, el sistema se bloquea. La cadena de llamadas completa est\u00e1 a continuaci\u00f3n: 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(\u0026amp;ksp-\u0026gt;lock, ...) y con ese spinlock bloqueado, llama a netif_rx(). Una vez que la ejecuci\u00f3n 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\u00f3n protegida por spinlock de ks8851_irq() deshabilitando los BH alrededor de toda la secci\u00f3n protegida por spinlock del controlador ks8851_irq(). Coloque local_bh_enable() fuera de la secci\u00f3n 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\u00e1 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()." } ], "id": "CVE-2024-35971", "lastModified": "2024-11-21T09:21:19.700", "metrics": {}, "published": "2024-05-20T10:15:11.947", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.openwall.com/lists/oss-security/2024/05/30/1" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "http://www.openwall.com/lists/oss-security/2024/05/30/2" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/492337a4fbd1421b42df684ee9b34be2a2722540" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/be0384bf599cf1eb8d337517feeb732d71f75a6f" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/cba376eb036c2c20077b41d47b317d8218fe754f" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…