From: sashiko-bot@kernel.org
To: "Lorenzo Bianconi" <lorenzo@kernel.org>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v7 02/10] net: airoha: Introduce airoha_gdm_dev struct
Date: Sun, 17 May 2026 05:58:12 +0000 [thread overview]
Message-ID: <20260517055812.CEC33C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260516-airoha-eth-multi-serdes-v7-2-99e0093303e2@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch introduces a race condition exposing a partially initialized port, leading to a NULL pointer dereference in NAPI polling handlers.
- [High] The `airoha_get_dsa_tag` function lacks packet length validation before stripping the MTK DSA tag, leading to an out-of-bounds memory access and `skb->len` integer underflow.
--
commit 3474bcc37d20c84839dc4e74bab44197a0507f51
Author: Lorenzo Bianconi <lorenzo@kernel.org>
net: airoha: Introduce airoha_gdm_dev struct
This commit introduces the airoha_gdm_dev structure to collect net_device
related info, preparing the driver for a 1:n relationship between GDM ports
and net_devices.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5a027cc7ffcb1..3ca0dbd19275a 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -2007,7 +2020,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> u8 fport;
>
> qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
> - tag = airoha_get_dsa_tag(skb, dev);
> + tag = airoha_get_dsa_tag(skb, netdev);
While looking at this patch, I noticed an issue in airoha_get_dsa_tag() that
pre-exists in the code. Does this function lack packet length validation
before pulling the MTK DSA tag?
airoha_get_dsa_tag() unconditionally performs memmove() and __skb_pull():
memmove(skb->data + MTK_HDR_LEN, skb->data, 2 * ETH_ALEN);
__skb_pull(skb, MTK_HDR_LEN);
If an unprivileged user sends an undersized packet via a raw socket
(AF_PACKET), could this result in an out-of-bounds memory access and cause
skb->len to integer-underflow?
This could lead to dma_map_single() attempting to map a massive amount of
memory, potentially causing an IOMMU fault and a local denial-of-service.
[ ... ]
> @@ -2975,53 +3060,22 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> return -EINVAL;
> }
>
> - dev = devm_alloc_etherdev_mqs(eth->dev, sizeof(*port),
> - AIROHA_NUM_NETDEV_TX_RINGS,
> - AIROHA_NUM_RX_RING);
> - if (!dev) {
> - dev_err(eth->dev, "alloc_etherdev failed\n");
> + port = devm_kzalloc(eth->dev, sizeof(*port), GFP_KERNEL);
> + if (!port)
> return -ENOMEM;
[ ... ]
> - port = netdev_priv(dev);
> u64_stats_init(&port->stats.syncp);
> spin_lock_init(&port->stats.lock);
> - port->eth = eth;
> - port->dev = dev;
> port->id = id;
> /* XXX: Read nbq from DTS */
> port->nbq = id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> eth->ports[p] = port;
>
> - return airoha_metadata_dst_alloc(port);
> + err = airoha_metadata_dst_alloc(port);
> + if (err)
> + return err;
> +
> + return airoha_alloc_gdm_device(eth, port, np);
> }
Could an interrupt cause a NULL pointer dereference in the NAPI handlers?
Since NAPI is enabled earlier in airoha_probe() via airoha_qdma_start_napi(),
and eth->ports[p] is assigned here before airoha_alloc_gdm_device() populates
port->dev, NAPI handlers like airoha_qdma_rx_process() could see a NULL
port->dev:
airoha_qdma_rx_process()
...
port = eth->ports[p];
netdev = port->dev->dev;
I note that this issue is fixed later in the series by commit 68e8fa8fe0224
("net: airoha: Support multiple net_devices for a single FE GDM port"), which
changes port->dev to an array and adds proper NULL checks.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260516-airoha-eth-multi-serdes-v7-0-99e0093303e2@kernel.org?part=2
next prev parent reply other threads:[~2026-05-17 5:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-16 5:57 [PATCH net-next v7 00/10] net: airoha: Support multiple net_devices connected to the same GDM port Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 01/10] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot
2026-05-18 20:39 ` Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 02/10] net: airoha: Introduce airoha_gdm_dev struct Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot [this message]
2026-05-18 20:59 ` Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 03/10] net: airoha: Move airoha_qdma pointer in " Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot
2026-05-19 8:21 ` Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 04/10] net: airoha: Rely on airoha_gdm_dev pointer in airoha_is_lan_gdm_port() Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 05/10] net: airoha: Move qos_sq_bmap in airoha_gdm_dev struct Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot
2026-05-19 8:23 ` Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 06/10] net: airoha: Move {cpu,fwd}_tx_packets " Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 07/10] net: airoha: Support multiple net_devices for a single FE GDM port Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot
2026-05-18 21:28 ` Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 08/10] net: airoha: Do not stop GDM port if it is shared Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot
2026-05-18 22:12 ` Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 09/10] net: airoha: Introduce WAN device flag Lorenzo Bianconi
2026-05-16 5:57 ` [PATCH net-next v7 10/10] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration Lorenzo Bianconi
2026-05-17 5:58 ` sashiko-bot
2026-05-19 8:37 ` Lorenzo Bianconi
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=20260517055812.CEC33C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.