CVE-2021-47013

What it actually does

Use-after-free in the EMAC MAC transmit path where a socket buffer is freed on error in emac_tx_fill_tpd but its length field is subsequently dereferenced in netdev_sent_queue.

Why it matters to the business

Kernel instability or crashes on systems using the affected EMAC network driver can interrupt network services and require unplanned reboots or forensic investigation.

How an attack unfolds

An attacker triggers the error path in emac_tx_fill_tpd by sending packets that cause transmit descriptor preparation to fail, freeing the skb; the subsequent access to the now-freed skb->len in netdev_sent_queue then produces memory corruption.

How to fix it

Apply the upstream fix that saves skb->len into a local variable before the call to emac_tx_fill_tpd and uses that variable instead of skb->len afterward; rebuild and deploy the patched kernel.

How to confirm the fix worked

Confirm the presence of the length-saving assignment before the emac_tx_fill_tpd call and the absence of any direct skb->len use after the potential free site in emac_mac_tx_buf_send.

Typical attack path

1. Send crafted or malformed packets to an interface using the EMAC driver
2. Force emac_tx_fill_tpd to take an error branch that calls dev_kfree_skb
3. Allow netdev_sent_queue to dereference the freed skb->len value
4. Trigger kernel memory corruption or crash

How to detect it

Review kernel logs for oops or panic messages referencing emac_mac_tx_buf_send or emac_tx_fill_tpd; inspect crash dumps for use-after-free patterns involving socket buffers in the transmit path.

What your security team should do

• Prioritize kernel updates on all systems exposing EMAC interfaces
• Monitor vendor advisories for backported fixes in supported distributions
• Test network stress workloads after patching to verify stability