[PATCH v4 net 5/8] net: enetc: ensure head buffer has at least 16 octets
From: vladimir . oltean
Date: Thu Oct 15 2026 - 07:12:40 EST
The ENETC does not support BUF_LEN or FRM_LEN in TX buffer descriptors
less than 16. This is written in the reference manual of all SoCs
supported by the driver: LS1028A, i.MX943, i.MX95 etc.
Frames must not have a FRM_LEN that is less than 16 bytes. Frames of
0-15 bytes are not supported.
(...)
The first descriptor in a chain must not have a BUFF_LEN that is less
than 16 bytes.
I don't think proper attention was paid to this during development, we
found the text at the end of a bug investigation. Therefore, the driver
does not enforce this.
But the frame length and geometry is out of the driver's control, and
the network stack can actually send packets that ENETC doesn't like.
Zefir Kurtisi found a case where transmitting L2 WNM keep-alive frames
through ENETC would soft-lockup the host through an IRQ storm. He later
distilled this into a small enetc-killer.c user space program which
sends a packet with MAC DA, MAC SA and EtherType IPv4 (14 octets in
length) through an AF_PACKET raw socket. Note that this particular case
was already closed by the previous commit, but an identical situation
still happens when the first buffer of a multi-buffer frame is < 16
bytes.
The IRQ storm is actually a curious effect of a chain of events.
The hardware behaviour, when an invalid BD is put in its TX ring, is
that it would transmit the packet as normal, update counters, raise
completion interrupt as normal, but it would just not advance the
consumer index of the ring (TBaCIR) to signify that the BD has been
consumed and is available for software to free. The ring will also get
its TBaSR[BUSY] bit persistently set to 1 afterwards.
It deserves an explanation why the behaviour above would lead to an
IRQ storm, since ENETC interrupts are message-based (MSI-X), and an
unhandled interrupt would typically just be lost rather than retrigger
itself as a wired interrupt would.
NAPI processing in ENETC has 3 steps:
I. the enetc_msix() hardirq handler disables RBaIER, TBaIER and sets
softirq processing to the 'pending' state.
II. the enetc_poll() softirq handler for the IRQ vector walks through
the TX rings affine to that vector, checks which ones have a TBCIR
updated since last time - enetc_bd_ready_count() - processes those
completed frames, and clears pending interrupts in these updated TX
rings by writing to TBaIDR. (I've excluded RX processing due to it
being irrelevant).
III. After the softirq handler does its round of checking all RX and TX
rings for updates, it re-enables all interrupts in RBaIER and
TBaIER that were previously disabled by the hardirq handler, and
exits.
Because the TX ring with the short frame is skipped at step II (TBCIR
wasn't updated as part of HW malfunction), its pending IRQ is not
cleared in TBaIDR by enetc_clean_tx_ring().
But because enetc_msix() disables TBaIER at step I and re-enables it at
step III, another MSI will be fired upon re-enabling it. This is what
completes the cycle and the driver goes back to step I.
So the driver misinterprets the mixed signals it's getting from the
hardware, and ends up causing a software-amplified IRQ storm.
Because the driver now pads linear skbs to ETH_ZLEN for other reasons
too, we just need to ensure the head buffer has at least 16 bytes.
This can be done using pskb_may_pull(), which moves that number of bytes
from the paged area into the head. This is case 5 below.
skb_headlen (H) | skb->len (L) | linear? | handled by
----------------+--------------+---------+---------------------------------------
H == L | L < 60 | yes | eth_skb_pad() (pads head to 60)
H == L | L >= 60 | yes | already valid, no-op
H < 16 | L < 60 | no | eth_skb_pad() (linearizes + pads to 60)
H < 16 | L >= 60 | no | pskb_may_pull() (pulls frags into head)
H >= 16 | L >= 60 | no | already valid, no-op
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Reported-by: Zefir Kurtisi <zefir.kurtisi@xxxxxxxxxxxx>
Closes: https://lore.kernel.org/netdev/b3d9136c-2803-4203-b1ea-1f9e62de80a1@xxxxxxxxx/
Signed-off-by: Vladimir Oltean <vladimir.oltean@xxxxxxx>
---
v3->v4:
- rename from "net: enetc: pad short frames in software". The padding
to ETH_ZLEN is now done by "net: enetc: do not rely on mEMAC hardware
frame padding", so this patch only deals with the 16 octet minimum
head buffer length
- move the check from enetc_xmit() to enetc_start_xmit(), after
eth_skb_pad()
- use pskb_may_pull() instead of skb_linearize()
- drop the code comment above the head buffer length check, it is
redundant with the commit message
- rework the commit message, add a table of the handled cases
- drop Reviewed-by from Wei Fang and Tested-by from Zefir Kurtisi due to
the change of approach
v1->v3: part of "pad short frames in software"
---
drivers/net/ethernet/freescale/enetc/enetc.c | 6 ++++++
drivers/net/ethernet/freescale/enetc/enetc.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index 9ab90145dcfa..08870df613b8 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1076,6 +1076,12 @@ static netdev_tx_t enetc_start_xmit(struct sk_buff *skb,
if (eth_skb_pad(skb))
return NETDEV_TX_OK;
+ if (unlikely(skb_headlen(skb) < ENETC_MIN_BUFF_SIZE &&
+ !pskb_may_pull(skb, ENETC_MIN_BUFF_SIZE))) {
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+ }
+
if (unlikely(skb_shinfo(skb)->nr_frags > priv->max_frags))
if (unlikely(skb_linearize(skb)))
goto drop_packet_err;
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h
index 08613e6a1d28..b5f38ad17280 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -22,6 +22,8 @@
#define ENETC_MAX_MTU (ENETC_MAC_MAXFRM_SIZE - \
(ETH_FCS_LEN + ETH_HLEN + VLAN_HLEN))
+#define ENETC_MIN_BUFF_SIZE 16
+
#define ENETC_CBD_DATA_MEM_ALIGN 64
#define ENETC_MADDR_HASH_TBL_SZ 64
--
2.43.0