CVE-2022-48648

What it actually does

Null pointer dereference in efx_hard_start_xmit when tx_queue is unexpectedly NULL, causing kernel crash on access to offset 0x20.

Why it matters to the business

Systems using affected Linux kernel versions with SFC Ethernet drivers may experience unexpected crashes or instability under rare conditions triggered by other bugs, leading to downtime and potential data loss in network-intensive workloads.

How an attack unfolds

An attacker or faulty driver state causes tx_queue to be NULL during transmit path; the code then attempts to dereference it, triggering a kernel NULL pointer dereference panic. No public in-the-wild exploitation is known.

How to fix it

Update the Linux kernel to a version containing commit b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7 or later stable releases that include the fix for the sfc driver.

How to confirm the fix worked

Verify the running kernel contains the referenced commit or is newer than the vulnerable versions; test network transmit paths under load to confirm absence of the dereference condition.

Typical attack path

1. Trigger conditions that set tx_queue to NULL in the SFC driver transmit path
2. Initiate network transmission via efx_hard_start_xmit
3. Kernel attempts invalid dereference resulting in panic

How to detect it

Search kernel logs for 'BUG: unable to handle kernel NULL pointer dereference' combined with 'efx_hard_start_xmit' and RIP offset around 0x153; examine crash dumps for tx_queue handling in sfc module.

What your security team should do

• Prioritize kernel updates on systems using Solarflare/SFC network adapters
• Monitor for kernel panics matching the described NULL dereference signature
• Review any dependent drivers or patches that could set tx_queue to NULL