CVE-2021-46948

What it actually does

Incorrect TX queue lookup using efx_channel_get_tx_queue() on a TXQ label instead of type can return NULL and trigger a kernel panic during TX event handling in the sfc farch driver.

Why it matters to the business

Systems using affected Linux kernel versions with Solarflare/AMD SFC network adapters may experience unexpected crashes and loss of network connectivity under normal or adversarial local workloads.

How an attack unfolds

A local attacker with the ability to trigger network TX events on an affected interface supplies a TXQ label to the event handler; the wrong lookup function returns NULL, which is dereferenced and causes a kernel panic.

How to fix it

Apply the upstream fix for sfc farch TX queue lookup in the Linux kernel; upgrade to a kernel containing commit resolving the label-versus-type lookup error in drivers/net/ethernet/sfc/farch.c.

How to confirm the fix worked

Confirm the presence of the corrected TX queue lookup logic in the running kernel source or binary; test that TX event paths no longer invoke efx_channel_get_tx_queue() on labels and that NULL checks are present.

Typical attack path

1. Obtain local user access on a Linux system with an SFC network device
2. Trigger or manipulate TX completion events that reach the farch event handler
3. Force the label-based lookup path that calls the inappropriate queue getter
4. Cause NULL dereference leading to immediate kernel panic

How to detect it

Review kernel logs for oops/panic entries containing sfc, farch, TX event, or efx_channel_get_tx_queue; correlate with local processes generating network traffic on affected adapters.

What your security team should do

• Prioritize kernel updates on any hosts using SFC network adapters
• Monitor for kernel panics with stack traces referencing sfc farch TX event handling
• Restrict local access on systems that cannot be immediately patched