From: sashiko-bot@kernel.org
To: "Birger Koblitz" <mail@birger-koblitz.de>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH net-next v17 11/13] ax88179_178a: Update driver name and information
Date: Wed, 07 Oct 2026 03:05:44 +0000 [thread overview]
Message-ID: <sashiko-outbox-162609@kernel.org> (raw)
In-Reply-To: <20261006-ax88179a-v17-11-252814fe35ea@birger-koblitz.de>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] net: skb data corruption in ax88179a_tx_fixup due to missing skb_cloned check
- [High] pm: leaked pm_mode state in ax88179a_suspend error path
--
commit beecb9dc824b9046a2ddbab47f74bb933e48f1e8
Author: Birger Koblitz <mail@birger-koblitz.de>
ax88179_178a: Update driver name and information
Add additionally supported devices to Kconfig description, add further
requirements such as PHYLINK. Update driver name in usb_driver and
update MODULE_DESCRIPTION to include the additionally supported chips.
> diff --git a/drivers/net/usb/ax88179a_devices.c b/drivers/net/usb/ax88179a_devices.c
> new file mode 100644
> index 0000000000000..929fa51280e84
> --- /dev/null
> +++ b/drivers/net/usb/ax88179a_devices.c
> @@ -0,0 +1,1284 @@
[ ... ]
> +static int ax88179a_suspend(struct usb_interface *intf, pm_message_t message)
> +{
> + struct usbnet *dev = usb_get_intfdata(intf);
> + struct ax88179_data *priv;
> + u8 tmp8 = 0;
> + u16 tmp16;
> + int ret;
> +
> + priv = dev->driver_priv;
> + ax88179_set_pm_mode(dev, true);
> +
> + if (netif_running(dev->net)) {
> + rtnl_lock();
> + phylink_suspend(priv->phylink, !!priv->wolopts);
> + rtnl_unlock();
> + }
> +
> + ret = usbnet_suspend(intf, message);
> + if (ret) {
> + rtnl_lock();
> + phylink_resume(priv->phylink);
> + rtnl_unlock();
> + return ret;
^^^^
[Severity: High]
Could this early return bypass ax88179_set_pm_mode(dev, false) and leave the
driver's internal PM state permanently corrupted?
If in_pm remains true, this could cause subsequent control commands to
bypass runtime PM locks, leading to aggressive auto-suspend and eventual
USB timeouts.
> + }
[ ... ]
> +static struct sk_buff *ax88179a_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
> +{
> + u64 tx_desc = skb->len & AX179A_TX_DESC_LEN_MASK;
> + int frame_size = dev->maxpacket;
> + struct sk_buff *ax_skb;
> + u64 *tx_desc_ptr;
> + int padding_size;
> + int headroom;
> + int tailroom;
> + u16 tci = 0;
> +
> + /* TSO MSS */
> + tx_desc |= FIELD_PREP(AX179A_TX_DESC_MSS, (u64)skb_shinfo(skb)->gso_size);
> +
> + headroom = (skb->len + sizeof(tx_desc)) % 8;
> + padding_size = headroom ? 8 - headroom : 0;
> +
> + if (((skb->len + sizeof(tx_desc) + padding_size) % frame_size) == 0) {
> + padding_size += 8;
> + tx_desc |= AX179A_TX_DESC_DROP_PADD;
> + }
> +
> + if ((dev->net->features & NETIF_F_HW_VLAN_CTAG_TX) && (vlan_get_tag(skb, &tci) >= 0)) {
> + tx_desc |= AX179A_TX_DESC_VLAN;
> + tx_desc |= FIELD_PREP(AX179A_TX_DESC_VLAN_ID, (u64)tci);
> + }
> +
> + if (!dev->can_dma_sg && (dev->net->features & NETIF_F_SG) && skb_linearize(skb)) {
> + dev_kfree_skb_any(skb);
> + return NULL;
> + }
> +
> + headroom = skb_headroom(skb);
> + tailroom = skb_tailroom(skb);
> +
> + if (!(headroom >= sizeof(tx_desc) && tailroom >= padding_size)) {
> + ax_skb = skb_copy_expand(skb, sizeof(tx_desc), padding_size, flags);
> + dev_kfree_skb_any(skb);
> + skb = ax_skb;
> + if (!skb)
> + return NULL;
> + }
> + if (padding_size != 0)
> + skb_put_zero(skb, padding_size);
> + /* Copy TX header */
> + tx_desc_ptr = skb_push(skb, sizeof(tx_desc));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Severity: High]
Are we writing into the SKB headroom here without checking if the buffer is
shared?
If a cloned SKB (such as during packet capture, TCP retransmits, or
broadcast) happens to have sufficient headroom and tailroom, this skips
skb_copy_expand and directly modifies the shared buffer.
This would corrupt data for all other clones holding a reference. Should
this call skb_cloned() or unshare the SKB buffer first?
> + put_unaligned_le64(tx_desc, tx_desc_ptr);
> +
> + usbnet_set_skb_tx_stats(skb, 1, 0);
> +
> + return skb;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261006-ax88179a-v17-0-252814fe35ea@birger-koblitz.de?part=11
next prev parent reply other threads:[~2026-10-07 3:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 3:05 [PATCH net-next v17 00/13] ax88179_178a: Add support for AX88179A-based chips Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 01/13] phylink: Add phylink_mac_interrupt Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-07 3:55 ` Fwd: " Birger Koblitz
2026-10-07 12:18 ` Andrew Lunn
2026-10-07 14:16 ` Birger Koblitz
2026-10-08 3:34 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 02/13] phylib: Add support for PHYs with broken forced mode Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-08 3:36 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 03/13] ax88179_178a: Split driver into library and device specific code Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-08 3:38 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 04/13] ax88179_178a: Add HW support for AX179A-based chips Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-08 3:41 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 05/13] ax88179_178a: Add EEE configuration support for AX88179A MACs Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-06 3:05 ` [PATCH net-next v17 06/13] ax88179_178a: Add EEE configuration support for AX88179A PHYs Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-06 3:05 ` [PATCH net-next v17 07/13] ax88179_178a: Add VLAN offload support for AX88179A Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-08 3:44 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 08/13] ax88179_178a: Add AX179A/AX279 multicast configuration Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-06 3:05 ` [PATCH net-next v17 09/13] ax88179_178a: Add Suspend/resume support for AX88179A/772D/279 Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-08 3:47 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 10/13] ax88179_178a: Add ethtool get_drvinfo Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-06 3:05 ` [PATCH net-next v17 11/13] ax88179_178a: Update driver name and information Birger Koblitz
2026-10-07 3:05 ` sashiko-bot [this message]
2026-10-08 3:48 ` Birger Koblitz
2026-10-06 3:05 ` [PATCH net-next v17 12/13] ax88179_178a: Add support for AX88179A/772D/279 EEPROM access Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-06 3:05 ` [PATCH net-next v17 13/13] ax88796b: Add support for AX88772D, AX88179A and AX88279 Birger Koblitz
2026-10-07 3:05 ` sashiko-bot
2026-10-08 3:50 ` Birger Koblitz
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-162609@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mail@birger-koblitz.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox