CVE-2024-56700

What it actually does

Atomicity violation in fmc_send_cmd() allows concurrent modification of fmdev->resp_skb after validity check, resulting in null pointer dereference when skb->data is accessed.

Why it matters to the business

Kernel crashes or denial of service on affected Linux systems during concurrent wireless media operations; low exploit likelihood reduces urgency but still requires patching to maintain stability across deployments with high downstream kernel dependents.

How an attack unfolds

An attacker with local access triggers concurrent execution of fmc_send_cmd() and code that nulls fmdev->resp_skb; after the check passes the value is cleared, leading to invalid skb dereference. Generic Linux kernel exploitation campaigns by espionage and financially motivated actors could adapt this pattern though no specific threat actor has been tied to this issue.

How to fix it

Update the Linux kernel to the fixed commit d16109c9fdc1b8cea4fe63b42e06e926c3f68990 or later stable release containing the patch that moves the fmdev->resp_skb validity check inside the locked section. For listed Ubuntu packages apply potrace 1.13-2 or 1.14-2 equivalents if backported.

How to confirm the fix worked

Confirm kernel source contains the locking change around the resp_skb check; boot test the updated kernel and monitor for absence of related null dereference oops in dmesg during media driver load and command operations.

Typical attack path

1. Obtain local code execution on target Linux system
2. Identify and trigger concurrent paths that modify fmdev->resp_skb while fmc_send_cmd() runs
3. Force the window where the validity check passes on a now-null pointer
4. Cause null pointer dereference at skb->data access leading to crash

How to detect it

Search kernel logs and crash dumps for null pointer dereference at line referencing skb->data in fmc_send_cmd context; correlate with media driver activity and concurrent process execution around fmdev structures. No specific named threat actors have published indicators for this flaw.

What your security team should do

• Prioritize kernel updates on systems using wl128x media drivers within normal patching cycles given low EPSS and no KEV listing
• Review concurrent execution paths in custom or out-of-tree drivers for similar atomicity issues
• Monitor kernel logs for null pointer dereference patterns involving fmdev or resp_skb