CVE-2021-47558

What it actually does

Race condition in the stmmac Ethernet driver leaves Tx queues enabled during interface stop/reconfiguration, allowing use-after-free or invalid memory access when ethtool -L, ethtool -G, or XDP attach/detach operations occur.

Why it matters to the business

Local reconfiguration of network queues, ring sizes, or XDP programs triggers immediate kernel panic, causing denial of service, loss of network connectivity, and potential disruption to any workloads relying on the affected interface.

How an attack unfolds

An attacker with local shell access on a system using the stmmac driver runs ethtool or ip commands to change queue count, ring size, or attach an XDP program; the missing netif_tx_disable call allows a packet transmission path to dereference freed or stale memory, producing the observed paging fault and panic.

How to fix it

Update to a Linux kernel containing the fix (post-2021-47558 commit) that ensures netif_tx_disable is called on interface stop; reboot after upgrade and verify the stmmac driver version no longer exhibits the race.

How to confirm the fix worked

Confirm the kernel source contains the netif_tx_disable call before netif_tx_stop_all_queues in the stmmac reconfiguration path; test by repeating the three triggering ethtool/ip operations and verifying absence of panic.

Typical attack path

1. Obtain local unprivileged shell on Linux host using stmmac driver
2. Execute ethtool -L, ethtool -G, or ip link set dev ethX xdp
3. Kernel attempts to transmit while queues are still active after reconfiguration
4. Panic occurs in dwmac4_set_addr or dev_hard_start_xmit

How to detect it

Search kernel logs and dmesg for panic strings containing 'Unable to handle kernel paging request' followed by dwmac4_set_addr, dev_hard_start_xmit, or stmmac; correlate with preceding ethtool or ip link XDP commands in audit logs.

• Unable to handle kernel paging request at virtual address
• dwmac4_set_addr+0x8/0x10
• dev_hard_start_xmit+0xe4/0x1ac
• sch_direct_xmit+0xe8/0x39c
• Call trace ending in dev_queue_xmit

What your security team should do

• Prioritize kernel upgrade on all systems exposing stmmac interfaces
• Restrict ethtool and ip link XDP operations to root via sudoers or SELinux policy
• Monitor for unexplained kernel panics referencing stmmac or dwmac4