CVE-2021-46949

What it actually does

Incorrect TX queue lookup using efx_get_tx_queue() on an instance number instead of type can return NULL, dereferencing it during TX flush done handling and causing a kernel panic.

Why it matters to the business

Local users can trigger availability loss through system crashes on affected Linux kernels, disrupting services without data exposure or modification.

How an attack unfolds

An attacker with local low-privileged access triggers TX queue flush completion paths that invoke the flawed lookup, supplying a qid that leads to NULL and panics the kernel; no remote or unauthenticated vectors apply and EPSS remains low with no known actors or campaigns.

How to fix it

Update to a Linux kernel containing the fix for the TX queue lookup logic in the SFC farch driver; apply vendor backports or newer mainline releases that replace the inappropriate efx_get_tx_queue() call.

How to confirm the fix worked

Confirm the running kernel contains the corrected TX flush handling code by inspecting driver source or changelog entries for the sfc farch TX queue lookup change; test TX queue operations under load to ensure no NULL dereference occurs.

Typical attack path

1. Obtain local shell or process execution with low privileges
2. Interact with SFC Ethernet driver TX paths to initiate queue flush operations
3. Supply TXQ instance number that causes efx_get_tx_queue() to return NULL
4. Trigger the flush-done handler to dereference the NULL pointer and panic

How to detect it

Review kernel logs for oops/panic entries mentioning sfc or farch TX flush handling; correlate with process activity that exercises Ethernet TX queues on affected hardware.

What your security team should do

• Prioritize kernel updates on systems using Solarflare/AMD SFC Ethernet adapters
• Monitor for kernel oops or panic logs related to sfc driver TX paths
• Restrict local access on multi-tenant hosts until patched given low-privilege trigger