CVE-2024-56593

What it actually does

NULL pointer dereference in brcmf_sdiod_sglist_rw() when the pre-allocated sgtable lacks sufficient entries for worst-case SKB queuing under high sd_sgentry_align values, causing sg_next to return NULL and triggering an oops.

Why it matters to the business

Systems using the affected Wi-Fi driver may experience unexpected crashes during high-volume packet handling, leading to downtime and potential loss of network connectivity on affected devices.

How an attack unfolds

An attacker or workload generates conditions with many queued SKBs (up to 64) combined with insufficient tailroom padding, exhausting the undersized sgtable entries during brcmf_sdiod_sglist_rw processing and dereferencing a null sg pointer.

How to fix it

Update to a kernel containing commit 342f87d263462c2670b77ea9a32074cab2ac6fa1 or later; the fix increases sgtable nents allocation to max(rxglom_size, txglom_size) * 2.

How to confirm the fix worked

Confirm the patched kernel version is running and verify that brcmf_sdiod_sglist_rw no longer triggers NULL dereference under synthetic high-queue SKB workloads matching the original nents calculation.

Typical attack path

1. Trigger high-volume SKB queuing in the brcmfmac pkt queue
2. Ensure tailroom padding requires additional SKB allocations per original packet
3. Execute skb_queue_walk loop with more entries than pre-allocated sgtable nents supports
4. Invoke sg_next on exhausted table resulting in NULL dereference and kernel oops

How to detect it

Review kernel logs for oops traces containing brcmf_sdiod_sglist_rw and sg_next; inspect Wi-Fi packet queuing activity preceding the crash on systems using brcmfmac.

What your security team should do

• Prioritize kernel updates on all systems using brcmfmac SDIO Wi-Fi
• Monitor for kernel oops reports referencing brcmf_sdiod_sglist_rw
• Apply the fix before enabling high glom sizes or heavy network loads