*Published: June 2024 – Exclusive Deep Dive & Exploit Details*

Overview

In early 2021, a vulnerability was discovered in the Linux kernel’s Solarflare (sfc) network driver code. The bug, now tracked as CVE-2021-46947, leads to a kernel crash (NULL pointer dereference) when querying network statistics (via ethtool -S) under certain configurations. While no remote code execution is possible, the bug can easily and reliably crash affected systems, creating a Denial of Service (DoS) condition.

In this post, we’ll dig into the root cause, see example exploit scenarios, review a related code snippet, provide links to the official patch and sources, and share practical guidance for users and administrators.

An array for XDP TX queues (efx->xdp_tx_queues) is allocated based on this count.

- During hardware probing, not all array slots are guaranteed to be initialized (some may remain NULL).
- When users (or scripts) run ethtool -S <iface> (to fetch statistics), the code traverses all entries in that array, *assuming* they are valid. Any uninitialized pointer leads to a NULL pointer dereference and an immediate kernel oops.

When the bug is triggered (typically by a stats query), you’ll see an oops like this

BUG: kernel NULL pointer dereference, address: 00000000000000f8
#PF: supervisor read access in kernel mode
#PF: error_code(x000) - not-present page
Oops: 000 [#1] SMP PTI
CPU: 23 PID: 4126959 Comm: ethtool Tainted: G           O      5.10.20-cloudflare-2021.3.1 #1
RIP: 001:efx_ethtool_get_stats+x2ca/x330 [sfc]
...
Call Trace:
  dev_ethtool+x1832/x283

Here’s a simplified and annotated excerpt from the buggy code path

// BAD: Initial allocation and counting code
// efx->xdp_tx_queue_count = num_possible_cpus();
// efx->xdp_tx_queues = kzalloc(... xdp_tx_queue_count ...);

for (i = ; i < efx->xdp_tx_queue_count; i++) {
    struct efx_tx_queue *txq = efx->xdp_tx_queues[i];
    u64 packets = txq->tx_packets; // <-- txq might be NULL!
    // ...
}

If efx->xdp_tx_queues[i] is NULL (never initialized), dereferencing it triggers a hard crash.

How Could This Happen?

- Some CPU queue entries aren’t initialized because there’s less hardware-supported queues than CPUs or some hardware limit/error at probe.

Exploit Scenario

This bug can be triggered locally by any unprivileged user on a vulnerable system with the sfc driver loaded, simply by running:

ethtool -S <name-of-sfc-interface>

Proof of Concept (PoC)

# list SFC interfaces (like enp2s, eth1, etc)
ip link

# crash system by querying stats
ethtool -S enp2s

If the system is vulnerable and queue slots are NULL, instant kernel panic/oops and a possible reboot.

Official Fix

The fix: The kernel patch adjusts efx->xdp_tx_queue_count *after* probing, setting it to the real number of initialized queues.

Excerpt from the fix

// After probing and initializing XDP TX queues
tmp_count = count_initialized_xdp_queues(...);
efx->xdp_tx_queue_count = tmp_count;

Effectively, now any array walk matches the actual live entries.

See the Actual Commit

- Patch (LKML, commit)
- Discussion (LKML mailing list)

Attack vector: Local (any user can crash the box)

- Affected versions: At least Linux 5.10 and likely others using the SFC driver before April 2021 fixes.

Blacklisting the driver: If you don’t need Solarflare NICs, blacklist the sfc kernel module.

3. Prevent unprivileged ethtool use: Not practical—access to /dev/net/ can allow interface stats reads anyway.

References

- CVE-2021-46947 at NVD
- Official Linux Kernel Patch
- Upstream commit discussion, LKML
- ethtool -S man page

Conclusion

CVE-2021-46947 is an example of how kernel stats code—something run by debugging tools—can accidentally offer a reliable and simple DoS primitive, taking down servers with a single command. While the underlying hardware-driver mix narrows the attack surface, all users of the sfc driver should update promptly.


Tip: If your datacenter uses Solarflare cards, patch now and update your incident docs to add local ethtool misuse as a possible indicator!

Feel free to share or link this post, but reproduction requires direct access to a vulnerable SFC-equipped server. For further deep dives, follow the related Linux kernel security advisories and the CVE system.

Timeline

Published on: 02/27/2024 19:04:06 UTC
Last modified on: 04/10/2024 20:00:47 UTC