From: sashiko-bot@kernel.org
To: vladimir.oltean@nxp.com
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH v4 net 1/8] net: enetc: consistently track dropped frames in enetc_xdp_xmit()
Date: Fri, 16 Oct 2026 10:56:55 +0000 [thread overview]
Message-ID: <sashiko-outbox-174210@kernel.org> (raw)
In-Reply-To: <20261015105536.1692348-2-vladimir.oltean@nxp.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] enetc: Use-After-Free in enetc_xdp_xmit() racing with enetc_close() teardown
- [High] enetc: OOB array access if CPUs exceed hardware TX rings
- [High] enetc: TX ring corruption when XDP_REDIRECT overlaps with network stack
--
commit 805311ddad67da52149365adfc7772abd1f8ca5b
Author: vladimir.oltean@nxp.com <vladimir.oltean@nxp.com>
net: enetc: consistently track dropped frames in enetc_xdp_xmit()
This patch updates enetc_xdp_xmit() to consistently increment the xdp_tx_drops
counter for all silently dropped frames. It routes early failures and batch
failures to a common exit path to ensure statistics are updated accurately.
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
> index 80f0082f6c633..26abc5fafd188 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> @@ -1814,15 +1814,18 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
> struct enetc_bdr *tx_ring;
> int xdp_tx_bd_cnt, i, k;
> int xdp_tx_frm_cnt = 0;
> + int err = 0;
> +
> + tx_ring = priv->xdp_tx_ring[smp_processor_id()];
[Severity: High]
Can tx_ring point to out-of-bounds memory here if the system has more
possible CPUs than hardware TX rings?
During initialization, the driver configures:
first_xdp_tx_ring = priv->num_tx_rings - num_possible_cpus();
priv->xdp_tx_ring = &priv->tx_ring[first_xdp_tx_ring];
If num_possible_cpus() is greater than priv->num_tx_rings,
first_xdp_tx_ring becomes negative, leaving priv->xdp_tx_ring pointing
out-of-bounds.
Because this patch moves the tx_ring assignment before the ENETDOWN check
and adds an unconditional dereference of tx_ring->stats in the goto out
path, an XDP_REDIRECT to this interface will now dereference this invalid
pointer and crash, whereas previously it would safely return -ENETDOWN.
[Severity: High]
Does this setup cause concurrent, lockless modifications of a TX ring
that is already in use by the network stack?
When no local XDP program is loaded, enetc_num_stack_tx_queues() allocates
all priv->num_tx_rings to the network stack. However, the driver also
unconditionally assigns priv->xdp_tx_ring to point to the uppermost
hardware queues.
If another interface uses XDP_REDIRECT to send frames to this device,
enetc_xdp_xmit() executes locklessly here, concurrently modifying the
same TX ring that the standard network stack is using under the Qdisc
__netif_tx_lock, leading to queue corruption.
>
> if (unlikely(test_bit(ENETC_TX_DOWN, &priv->flags) ||
> - !netif_carrier_ok(ndev)))
> - return -ENETDOWN;
> + !netif_carrier_ok(ndev))) {
> + err = -ENETDOWN;
> + goto out;
> + }
>
> enetc_lock_mdio();
>
> - tx_ring = priv->xdp_tx_ring[smp_processor_id()];
> -
> prefetchw(ENETC_TXBD(*tx_ring, tx_ring->next_to_use));
[ ... ]
> @@ -1853,11 +1855,13 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
> if (unlikely((flags & XDP_XMIT_FLUSH) || k != xdp_tx_frm_cnt))
> enetc_update_tx_ring_tail(tx_ring);
>
> - tx_ring->stats.xdp_tx += xdp_tx_frm_cnt;
> -
> enetc_unlock_mdio();
>
> - return xdp_tx_frm_cnt;
> +out:
> + tx_ring->stats.xdp_tx += xdp_tx_frm_cnt;
[Severity: High]
Will this result in a use-after-free if it races with the interface teardown?
In the teardown path, enetc_close() does not wait for RCU or hold a
synchronization lock against remote XDP_REDIRECT threads before freeing
the TX rings:
enetc_close()
enetc_stop()
set_bit(ENETC_TX_DOWN, &priv->flags);
...
enetc_assign_tx_resources(priv, NULL);
Since this patch changes the early ENETDOWN check to jump to the out
label instead of returning immediately, the code will now unconditionally
dereference tx_ring->stats here even if the interface is going down
and the resources have already been freed.
> + tx_ring->stats.xdp_tx_drops += num_frames - xdp_tx_frm_cnt;
> +
> + return err ?: xdp_tx_frm_cnt;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261015105536.1692348-1-vladimir.oltean@nxp.com?part=1
next prev parent reply other threads:[~2026-10-16 10:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 10:55 [PATCH v4 net 0/8] Fix short frame transmission in enetc vladimir.oltean
2026-10-15 10:55 ` [PATCH v4 net 1/8] net: enetc: consistently track dropped frames in enetc_xdp_xmit() vladimir.oltean
2026-10-16 10:56 ` sashiko-bot [this message]
2026-10-15 10:55 ` [PATCH v4 net 2/8] net: enetc: serialize access to the same TX ring from NAPI XDP_TX and ndo_xdp_xmit() vladimir.oltean
2026-10-16 10:56 ` sashiko-bot
2026-10-15 10:55 ` [PATCH v4 net 3/8] net: enetc: fix bogus TX ring consumer index after reinitialization vladimir.oltean
2026-10-15 10:55 ` [PATCH v4 net 4/8] net: enetc: do not rely on mEMAC hardware frame padding vladimir.oltean
2026-10-16 10:56 ` sashiko-bot
2026-10-15 10:55 ` [PATCH v4 net 5/8] net: enetc: ensure head buffer has at least 16 octets vladimir.oltean
2026-10-16 10:56 ` sashiko-bot
2026-10-15 10:55 ` [PATCH v4 net 6/8] net: enetc: pad short XDP frames in software vladimir.oltean
2026-10-15 10:55 ` [PATCH v4 net 7/8] net: enetc: fix leak of pending XDP_TX frames when going down vladimir.oltean
2026-10-15 10:55 ` [PATCH v4 net 8/8] net: enetc: ensure enetc_xdp_xmit() calls enetc_update_tx_ring_tail() vladimir.oltean
2026-10-16 10:56 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-174210@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.