* [PATCH v5.10 2/2] net/sched: cls_u32: use skb_header_pointer_careful()
From: Shivani Agarwal @ 2026-06-18 8:08 UTC (permalink / raw)
To: stable, gregkh
Cc: davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel,
xiaosuo, iri, jhs, ajay.kaher, alexey.makhalov,
vamsi-krishna.brahmajosyula, yin.ding, tapas.kundu, GangMin Kim,
Bin Lan, Shivani Agarwal
In-Reply-To: <20260618080807.1269070-1-shivani.agarwal@broadcom.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit cabd1a976375780dabab888784e356f574bbaed8 ]
skb_header_pointer() does not fully validate negative @offset values.
Use skb_header_pointer_careful() instead.
GangMin Kim provided a report and a repro fooling u32_classify():
BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0
net/sched/cls_u32.c:221
Fixes: fbc2e7d9cf49 ("cls_u32: use skb_header_pointer() to dereference data safely")
Reported-by: GangMin Kim <km.kim1503@gmail.com>
Closes: https://lore.kernel.org/netdev/CANn89iJkyUZ=mAzLzC4GdcAgLuPnUoivdLaOs6B9rq5_erj76w@mail.gmail.com/T/
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260128141539.3404400-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Bin Lan <lanbincn@139.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Shivani: Modified to apply on 5.10.y ]
Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
---
net/sched/cls_u32.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index f2a0c1068..e501390cc 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -149,10 +149,8 @@ static int u32_classify(struct sk_buff *skb, const struct tcf_proto *tp,
int toff = off + key->off + (off2 & key->offmask);
__be32 *data, hdata;
- if (skb_headroom(skb) + toff > INT_MAX)
- goto out;
-
- data = skb_header_pointer(skb, toff, 4, &hdata);
+ data = skb_header_pointer_careful(skb, toff, 4,
+ &hdata);
if (!data)
goto out;
if ((*data ^ key->val) & key->mask) {
@@ -202,8 +200,9 @@ static int u32_classify(struct sk_buff *skb, const struct tcf_proto *tp,
if (ht->divisor) {
__be32 *data, hdata;
- data = skb_header_pointer(skb, off + n->sel.hoff, 4,
- &hdata);
+ data = skb_header_pointer_careful(skb,
+ off + n->sel.hoff,
+ 4, &hdata);
if (!data)
goto out;
sel = ht->divisor & u32_hash_fold(*data, &n->sel,
@@ -217,7 +216,7 @@ static int u32_classify(struct sk_buff *skb, const struct tcf_proto *tp,
if (n->sel.flags & TC_U32_VAROFFSET) {
__be16 *data, hdata;
- data = skb_header_pointer(skb,
+ data = skb_header_pointer_careful(skb,
off + n->sel.offoff,
2, &hdata);
if (!data)
--
2.53.0
^ permalink raw reply related
* [PATCH v5.10 1/2] net: add skb_header_pointer_careful() helper
From: Shivani Agarwal @ 2026-06-18 8:08 UTC (permalink / raw)
To: stable, gregkh
Cc: davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel,
xiaosuo, iri, jhs, ajay.kaher, alexey.makhalov,
vamsi-krishna.brahmajosyula, yin.ding, tapas.kundu, Bin Lan,
Shivani Agarwal
In-Reply-To: <20260618080807.1269070-1-shivani.agarwal@broadcom.com>
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 13e00fdc9236bd4d0bff4109d2983171fbcb74c4 ]
This variant of skb_header_pointer() should be used in contexts
where @offset argument is user-controlled and could be negative.
Negative offsets are supported, as long as the zone starts
between skb->head and skb->data.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260128141539.3404400-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Adjust context ]
Signed-off-by: Bin Lan <lanbincn@139.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Shivani: Modified to apply on 5.10.y ]
Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
---
include/linux/skbuff.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8abbb64bd..a2daeba8b 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3686,6 +3686,18 @@ skb_header_pointer(const struct sk_buff *skb, int offset, int len, void *buffer)
skb_headlen(skb), buffer);
}
+/* Variant of skb_header_pointer() where @offset is user-controlled
+ * and potentially negative.
+ */
+static inline void * __must_check
+skb_header_pointer_careful(const struct sk_buff *skb, int offset,
+ int len, void *buffer)
+{
+ if (unlikely(offset < 0 && -offset > skb_headroom(skb)))
+ return NULL;
+ return skb_header_pointer(skb, offset, len, buffer);
+}
+
/**
* skb_needs_linearize - check if we need to linearize a given skb
* depending on the given device features.
--
2.53.0
^ permalink raw reply related
* [PATCH v5.10 0/2] Fix CVE-2026-23204
From: Shivani Agarwal @ 2026-06-18 8:08 UTC (permalink / raw)
To: stable, gregkh
Cc: davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel,
xiaosuo, iri, jhs, ajay.kaher, alexey.makhalov,
vamsi-krishna.brahmajosyula, yin.ding, tapas.kundu,
Shivani Agarwal
To fix CVE-2026-23204, commit cabd1a976375 is required; however,
it depends on commit 13e00fdc9236. Therefore, both patches
have been backported to v5.10.
Eric Dumazet (2):
net: add skb_header_pointer_careful() helper
net/sched: cls_u32: use skb_header_pointer_careful()
include/linux/skbuff.h | 12 ++++++++++++
net/sched/cls_u32.c | 13 ++++++-------
2 files changed, 18 insertions(+), 7 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH net-next 0/2] appletalk: move the protocol out of tree
From: Finn Thain @ 2026-06-18 8:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: Carsten Strotmann, Jakub Kicinski, Carsten Strotmann,
John Paul Adrian Glaubitz, davem, netdev, edumazet, pabeni,
andrew+netdev, horms, geert, chleroy, npiggin, mpe, maddy,
linux-mips, linux-m68k, linuxppc-dev
In-Reply-To: <2791b2e3-bf58-4dce-9262-4f1d8d3241fb@lunn.ch>
On Thu, 18 Jun 2026, Andrew Lunn wrote:
> appletalk is just one of many many drivers where the listed Maintainers
> does not respond to patches, or there is no Maintainer at all. So a lot
> of work falls on the top level netdev Maintainers.
It goes with the territory. If that messes up their performance reviews, I
am okay with that. We all make our own choices.
> In fact, a lot of the AI driven bug fixes tend to fall into this
> category of old drivers with no active Maintainers, since that tends to
> be where the poorer quality code is.
That has not been my experience. I rarely see a review from sashiko-bot on
the scsi mailing list that doesn't list as many pre-existing bugs as new
bugs. This is almost always actively developed code, not mature code.
In anycase, quality is irrelevant here. I'm happy to see fixes for any
code base whatever its level of quality and whatever the quality metric.
What matters more to me than quality is utility.
> So top level netdev Maintainers are having to do a lot more work, on old
> drivers which very few people care about. That is a poor use of their
> talent, when we actually want them working on drivers for modern
> hardware with a lot of users.
>
Again, that has not been my experience. Linux often gets installed because
the hardware is not modern enough so the vendor has abandoned it and so
there's no better alternative than Linux.
As for wasted talent, this industry discards skillsets just as fast as you
discard e-waste. It goes with the territory. Moreover, if maintainers are
not using AI to make themselves more effective then they should admit to
retro-computing.
^ permalink raw reply
* Re: [PATCH net] net: sit: require CAP_NET_ADMIN in the device netns for changelink
From: Nicolas Dichtel @ 2026-06-18 8:25 UTC (permalink / raw)
To: Maoyi Xie, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Xiao Liang, Kees Cook, netdev,
linux-kernel, stable
In-Reply-To: <20260618070817.3378283-1-maoyixie.tju@gmail.com>
Le 18/06/2026 à 09:08, Maoyi Xie a écrit :
> ipip6_changelink() operates on at most two netns, dev_net(dev) and the
> tunnel link netns t->net. They differ once the device is created in or
> moved to a netns other than the one the request runs in. The rtnl
> changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
> caller privileged there but not in t->net can rewrite a tunnel that
> lives in t->net.
>
> Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,
> before any attribute is parsed. sit was the one tunnel type not covered
> by the recent series that added this check to the other changelink()
> handlers.
>
> Fixes: 5e6700b3bf98 ("sit: add support of x-netns")
> Link: https://lore.kernel.org/netdev/20260612085941.3158249-1-maoyixie.tju@gmail.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net v2] net: marvell: prestera: initialize err in prestera_port_sfp_bind
From: Maxime Chevallier @ 2026-06-18 8:18 UTC (permalink / raw)
To: Ruoyu Wang, Taras Chornyi, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Russell King,
Oleksandr Mazur, Yevhen Orlov, netdev, linux-kernel
In-Reply-To: <20260617193228.1653582-1-ruoyuw560@gmail.com>
Hi,
On 6/17/26 21:32, Ruoyu Wang wrote:
> prestera_port_sfp_bind() returns err after walking the ports node. If no
> child node matches the port's front-panel id, err is never assigned.
>
> Initialize err to 0 because absence of a matching optional port device
> tree node is not an error. In that case no phylink is created and port
> creation should continue with port->phy_link left NULL. Errors from
> malformed matched nodes and phylink_create() still propagate.
>
> Fixes: 52323ef75414 ("net: marvell: prestera: add phylink support")
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Sorry for the grumpiness, but Andrew did ask you to read :
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
and one of the first things it says it to wait 24h before a repost :/
The patch in itself LGTM, so :
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Please wait 24h next time,
Maxime
^ permalink raw reply
* neigh: poor scalability of forced GC when neighbour count exceeds gc_thresh3
From: Vimal Agrawal @ 2026-06-18 8:17 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Jakub Kicinski, Vimal Agrawal
While investigating a soft lockup observed during neighbour table
growth, I noticed that neighbour allocation latency increases
significantly once the number of entries exceeds gc_thresh3.
Test setup:
net.ipv6.neigh.default.gc_thresh1 = 16384
net.ipv6.neigh.default.gc_thresh2 = 32768
net.ipv6.neigh.default.gc_thresh3 = 32768
I created approximately 50,000 reachable neighbour entries and
measured time spent in __neigh_create(). Once the table size exceeds
gc_thresh3, neighbour creation latency increases dramatically (in my
testing, individual allocations can take >16 ms). Profiling shows that
most of the time is spent waiting on tbl->lock, typically held by
neigh_forced_gc().
The relevant path is:
static int neigh_forced_gc(struct neigh_table *tbl)
{
...
write_lock_bh(&tbl->lock);
list_for_each_entry_safe(n, tmp, &tbl->gc_list, gc_list) {
if (refcount_read(&n->refcnt) == 1) {
...
In my workload, most entries are active/reachable and have refcnt > 1,
so the GC walk scans a large portion of the neighbour table without
reclaiming entries. As a result, the lock can be held for a long
period while traversing the GC list.
Another observation is that once gc_thresh3 is exceeded, every new
neighbour allocation attempts a forced GC:
entries = atomic_inc_return(&tbl->gc_entries) - 1;
if (entries >= gc_thresh3 ||
(entries >= READ_ONCE(tbl->gc_thresh2) &&
time_after(now, READ_ONCE(tbl->last_flush) + 5 * HZ))) {
if (!neigh_forced_gc(tbl) && entries >= gc_thresh3) {
...
Unlike the gc_thresh2 case, there is no rate limiting once the table
is already above gc_thresh3. Under sustained neighbour creation this
results in repeated full GC scans, further increasing contention on
tbl->lock.
Has this scalability issue been discussed previously, or is there a
reason why forced GC above gc_thresh3 is intentionally not
rate-limited?
I would be interested in feedback before working on a patch.
Thanks,
Vimal Agrawal
^ permalink raw reply
* Re: [PATCH net-next 0/2] appletalk: move the protocol out of tree
From: Geert Uytterhoeven @ 2026-06-18 8:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Finn Thain, Carsten Strotmann, Jakub Kicinski,
John Paul Adrian Glaubitz, davem, netdev, edumazet, pabeni,
andrew+netdev, horms, chleroy, npiggin, mpe, maddy, linux-mips,
linux-m68k, linuxppc-dev
In-Reply-To: <2791b2e3-bf58-4dce-9262-4f1d8d3241fb@lunn.ch>
Hi Andrew,
On Thu, 18 Jun 2026 at 10:01, Andrew Lunn <andrew@lunn.ch> wrote:
> If the appletalk community can take the workload off the top level
> maintainers, respond to all patches within 2 to 3 days, give
> Reviewed-by, or make change requests, it can probably stay in the
> Mainline kernel. Otherwise it will move out of tree.
"2 or 3 days" is rather short. If we would have to move all code
maintained by people who cannot respond to all patches within 2 to
3 days out of the mainline kernel, you'd end up with a networking
subsystem without supporting OS ;-)
git grep three.*week -- Documentation/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH] net: fman: fix clock and device node leak in probe error paths
From: Madalin Bucur @ 2026-06-18 8:08 UTC (permalink / raw)
To: ZhaoJinming
Cc: Sean Anderson, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260618075435.1262533-1-zhaojinming@uniontech.com>
> -----Original Message-----
> From: ZhaoJinming <zhaojinming@uniontech.com>
> Sent: Thursday, June 18, 2026 10:55 AM
> To: Madalin Bucur <madalin.bucur@nxp.com>
> Cc: Sean Anderson <sean.anderson@linux.dev>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; ZhaoJinming <zhaojinming@uniontech.com>
> Subject: [PATCH] net: fman: fix clock and device node leak in probe error paths
>
> In read_dts_node(), fm_node is acquired via of_node_get() and clk is
> acquired via of_clk_get(). After a successful of_clk_get() call, the
> error paths for clk_get_rate failure and of_property_read_u32_array
> failure correctly goto fman_node_put (releasing fm_node) but miss
> clk_put(clk).
>
> Worse, all error paths from the MURAM node lookup onward goto
> fman_free directly, skipping both fman_node_put and clk_put, leaking
> both the fm_node and clk references.
>
> of_clk_get() eventually calls __of_clk_get() -> clk_hw_create_clk() ->
> alloc_clk() -> kzalloc_obj() to allocate the clk struct, so clk_put()
> must be called to release this memory. Without it, the allocated clk
> struct is leaked on every probe failure after of_clk_get() succeeds.
>
> Introduce a clk_put label between the success return and fman_node_put
> in the unwind chain, and redirect all error paths after of_clk_get()
> to this new label. Since no goto target remains for fman_free, fold
> it into fman_node_put and remove the now-unused label.
>
> Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
> ---
> drivers/net/ethernet/freescale/fman/fman.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fman/fman.c
> b/drivers/net/ethernet/freescale/fman/fman.c
> index 013273a2de32..734cbe8efd7e 100644
> --- a/drivers/net/ethernet/freescale/fman/fman.c
> +++ b/drivers/net/ethernet/freescale/fman/fman.c
> @@ -2736,7 +2736,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> err = -EINVAL;
> dev_err(&of_dev->dev, "%s: Failed to determine FM%d clock rate\n",
> __func__, fman->dts_params.id);
> - goto fman_node_put;
> + goto clk_put;
> }
> /* Rounding to MHz */
> fman->dts_params.clk_freq = DIV_ROUND_UP(clk_rate, 1000000);
> @@ -2746,7 +2746,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> if (err) {
> dev_err(&of_dev->dev, "%s: failed to read fsl,qman-channel-range
> for %pOF\n",
> __func__, fm_node);
> - goto fman_node_put;
> + goto clk_put;
> }
> fman->dts_params.qman_channel_base = range[0];
> fman->dts_params.num_of_qman_channels = range[1];
> @@ -2757,7 +2757,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> err = -EINVAL;
> dev_err(&of_dev->dev, "%s: could not find MURAM node\n",
> __func__);
> - goto fman_free;
> + goto clk_put;
> }
>
> err = of_address_to_resource(muram_node, 0,
> @@ -2766,7 +2766,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> of_node_put(muram_node);
> dev_err(&of_dev->dev, "%s: of_address_to_resource() = %d\n",
> __func__, err);
> - goto fman_free;
> + goto clk_put;
> }
>
> of_node_put(muram_node);
> @@ -2776,7 +2776,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> if (err < 0) {
> dev_err(&of_dev->dev, "%s: irq %d allocation failed (error = %d)\n",
> __func__, irq, err);
> - goto fman_free;
> + goto clk_put;
> }
>
> if (fman->dts_params.err_irq != 0) {
> @@ -2786,7 +2786,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> if (err < 0) {
> dev_err(&of_dev->dev, "%s: irq %d allocation failed (error
> = %d)\n",
> __func__, fman->dts_params.err_irq, err);
> - goto fman_free;
> + goto clk_put;
> }
> }
>
> @@ -2794,7 +2794,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> if (IS_ERR(base_addr)) {
> err = PTR_ERR(base_addr);
> dev_err(&of_dev->dev, "%s: devm_ioremap() failed\n", __func__);
> - goto fman_free;
> + goto clk_put;
> }
>
> fman->dts_params.base_addr = base_addr;
> @@ -2806,7 +2806,7 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
> if (err) {
> dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
> __func__);
> - goto fman_free;
> + goto clk_put;
> }
>
> #ifdef CONFIG_DPAA_ERRATUM_A050385
> @@ -2816,9 +2816,10 @@ static struct fman *read_dts_node(struct
> platform_device *of_dev)
>
> return fman;
>
> +clk_put:
> + clk_put(clk);
> fman_node_put:
> of_node_put(fm_node);
> -fman_free:
> kfree(fman);
> return ERR_PTR(err);
> }
> --
> 2.20.1
Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
Thanks
^ permalink raw reply
* Re: [PATCH 1/2] igc: Wait for MAC passthrough after reset
From: Andrew Lunn @ 2026-06-18 8:08 UTC (permalink / raw)
To: Chia-Lin Kao (AceLan)
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
In-Reply-To: <20260618073324.1843310-1-acelan.kao@canonical.com>
> +static void igc_wait_for_lmvp_mac_passthrough(struct pci_dev *pdev,
> + struct igc_hw *hw)
> +{
> + u8 addr[ETH_ALEN] __aligned(2);
> + u32 orig_ral, orig_rah;
> + u32 ral, rah;
> + int i;
> +
> + if (!igc_is_lmvp_device(pdev))
> + return;
> +
> + igc_read_rar0(hw, addr, &orig_ral, &orig_rah);
> +
> + for (i = 0; i < 100; i++) {
> + msleep(100);
> + igc_read_rar0(hw, addr, &ral, &rah);
> + if ((ral != orig_ral || rah != orig_rah) &&
> + is_valid_ether_addr(addr))
> + return;
> + }
Please use one of the helpers from iopoll.h
Andrew
^ permalink raw reply
* Re: [PATCHv2] net: emac: Fix NULL pointer dereference in emac_probe
From: Andrew Lunn @ 2026-06-18 8:03 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, open list
In-Reply-To: <20260618023405.415644-1-rosenp@gmail.com>
On Wed, Jun 17, 2026 at 07:34:05PM -0700, Rosen Penev wrote:
> Move devm_request_irq() after devm_platform_ioremap_resource() so that
> dev->emacp is mapped before the interrupt handler can fire. An early
> interrupt hitting emac_irq() would dereference the NULL dev->emacp and
> crash.
>
> Also remove redundant error message. devm_platform_ioremap_resource()
> already returns an error message with dev_err_probe().
I still think there is a bigger problem that interrupts can fire
early, but:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/2] appletalk: move the protocol out of tree
From: Andrew Lunn @ 2026-06-18 8:01 UTC (permalink / raw)
To: Finn Thain
Cc: Carsten Strotmann, Jakub Kicinski, Carsten Strotmann,
John Paul Adrian Glaubitz, davem, netdev, edumazet, pabeni,
andrew+netdev, horms, geert, chleroy, npiggin, mpe, maddy,
linux-mips, linux-m68k, linuxppc-dev
In-Reply-To: <489024bc-b6e5-f601-3bce-444d75abbf5d@linux-m68k.org>
On Thu, Jun 18, 2026 at 10:55:54AM +1000, Finn Thain wrote:
>
> On Wed, 17 Jun 2026, Carsten Strotmann wrote:
>
> > > _Someone_ has to handle the reports and patches. And since nobody is
> > > doing that the code is going to GitHub, where it can continue to "just
> > > be left" or whatever, without racking up CVEs for the Linux kernel and
> > > leading to maintainer burn out :/
> > >
> >
> > That's a good point. The large influx of reports is a problem, and burn
> > out of maintainers is a too high cost.
> >
>
> Carsten, if, as a maintainer, you want to avoid burnout then
It is not necessarily Carsten who is heading towards burnout.
appletalk is just one of many many drivers where the listed
Maintainers does not respond to patches, or there is no Maintainer at
all. So a lot of work falls on the top level netdev Maintainers. In
fact, a lot of the AI driven bug fixes tend to fall into this category
of old drivers with no active Maintainers, since that tends to be
where the poorer quality code is. So top level netdev Maintainers are
having to do a lot more work, on old drivers which very few people
care about. That is a poor use of their talent, when we actually want
them working on drivers for modern hardware with a lot of users.
If the appletalk community can take the workload off the top level
maintainers, respond to all patches within 2 to 3 days, give
Reviewed-by, or make change requests, it can probably stay in the
Mainline kernel. Otherwise it will move out of tree.
Andrew
^ permalink raw reply
* [PATCH] net: fman: fix clock and device node leak in probe error paths
From: ZhaoJinming @ 2026-06-18 7:54 UTC (permalink / raw)
To: Madalin Bucur
Cc: Sean Anderson, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, ZhaoJinming
In read_dts_node(), fm_node is acquired via of_node_get() and clk is
acquired via of_clk_get(). After a successful of_clk_get() call, the
error paths for clk_get_rate failure and of_property_read_u32_array
failure correctly goto fman_node_put (releasing fm_node) but miss
clk_put(clk).
Worse, all error paths from the MURAM node lookup onward goto
fman_free directly, skipping both fman_node_put and clk_put, leaking
both the fm_node and clk references.
of_clk_get() eventually calls __of_clk_get() -> clk_hw_create_clk() ->
alloc_clk() -> kzalloc_obj() to allocate the clk struct, so clk_put()
must be called to release this memory. Without it, the allocated clk
struct is leaked on every probe failure after of_clk_get() succeeds.
Introduce a clk_put label between the success return and fman_node_put
in the unwind chain, and redirect all error paths after of_clk_get()
to this new label. Since no goto target remains for fman_free, fold
it into fman_node_put and remove the now-unused label.
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
---
drivers/net/ethernet/freescale/fman/fman.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index 013273a2de32..734cbe8efd7e 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2736,7 +2736,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
err = -EINVAL;
dev_err(&of_dev->dev, "%s: Failed to determine FM%d clock rate\n",
__func__, fman->dts_params.id);
- goto fman_node_put;
+ goto clk_put;
}
/* Rounding to MHz */
fman->dts_params.clk_freq = DIV_ROUND_UP(clk_rate, 1000000);
@@ -2746,7 +2746,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
if (err) {
dev_err(&of_dev->dev, "%s: failed to read fsl,qman-channel-range for %pOF\n",
__func__, fm_node);
- goto fman_node_put;
+ goto clk_put;
}
fman->dts_params.qman_channel_base = range[0];
fman->dts_params.num_of_qman_channels = range[1];
@@ -2757,7 +2757,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
err = -EINVAL;
dev_err(&of_dev->dev, "%s: could not find MURAM node\n",
__func__);
- goto fman_free;
+ goto clk_put;
}
err = of_address_to_resource(muram_node, 0,
@@ -2766,7 +2766,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
of_node_put(muram_node);
dev_err(&of_dev->dev, "%s: of_address_to_resource() = %d\n",
__func__, err);
- goto fman_free;
+ goto clk_put;
}
of_node_put(muram_node);
@@ -2776,7 +2776,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
if (err < 0) {
dev_err(&of_dev->dev, "%s: irq %d allocation failed (error = %d)\n",
__func__, irq, err);
- goto fman_free;
+ goto clk_put;
}
if (fman->dts_params.err_irq != 0) {
@@ -2786,7 +2786,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
if (err < 0) {
dev_err(&of_dev->dev, "%s: irq %d allocation failed (error = %d)\n",
__func__, fman->dts_params.err_irq, err);
- goto fman_free;
+ goto clk_put;
}
}
@@ -2794,7 +2794,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
if (IS_ERR(base_addr)) {
err = PTR_ERR(base_addr);
dev_err(&of_dev->dev, "%s: devm_ioremap() failed\n", __func__);
- goto fman_free;
+ goto clk_put;
}
fman->dts_params.base_addr = base_addr;
@@ -2806,7 +2806,7 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
if (err) {
dev_err(&of_dev->dev, "%s: of_platform_populate() failed\n",
__func__);
- goto fman_free;
+ goto clk_put;
}
#ifdef CONFIG_DPAA_ERRATUM_A050385
@@ -2816,9 +2816,10 @@ static struct fman *read_dts_node(struct platform_device *of_dev)
return fman;
+clk_put:
+ clk_put(clk);
fman_node_put:
of_node_put(fm_node);
-fman_free:
kfree(fman);
return ERR_PTR(err);
}
--
2.20.1
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH 1/2] igc: Wait for MAC passthrough after reset
From: Loktionov, Aleksandr @ 2026-06-18 7:55 UTC (permalink / raw)
To: kao, acelan, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260618073324.1843310-1-acelan.kao@canonical.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Chia-Lin Kao (AceLan) via Intel-wired-lan
> Sent: Thursday, June 18, 2026 9:33 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; intel-
> wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH 1/2] igc: Wait for MAC passthrough
> after reset
>
> Some systems support MAC passthrough for dock Ethernet controllers by
> having firmware rewrite the receive address registers after the
> controller reset completes.
>
> igc resets the controller before reading RAL0/RAH0, so that reset can
> restore the controller native MAC address temporarily. If the driver
> reads the registers immediately, it can race the firmware rewrite and
> keep the native dock MAC instead of the host passthrough MAC.
>
> For LMVP devices, poll RAL0/RAH0 after reset and before reading the
> MAC address. Stop once the address registers change to another valid
> Ethernet address, allowing firmware a bounded window to complete the
> passthrough update.
>
Good day, Chia-Lin
It'd be great if you could share more details on how to reproduce the issue.
What exact hardware setup is affected (dock model, NIC, system)?
Which firmware/BIOS version?
How often does the race trigger?
Do you have a way to reliably reproduce it?
Also, what is the observed behavior vs. expected behavior? For example,
which MAC address is seen and which one should be used?
> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 48
> +++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
> b/drivers/net/ethernet/intel/igc/igc_main.c
> index 2c9e2dfd8499..fa9752ed8bc5 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -11,6 +11,7 @@
> #include <net/pkt_sched.h>
> #include <linux/bpf_trace.h>
> #include <net/xdp_sock_drv.h>
> +#include <linux/etherdevice.h>
> #include <linux/pci.h>
> #include <linux/mdio.h>
>
> @@ -69,6 +70,52 @@ static const struct pci_device_id igc_pci_tbl[] = {
>
> MODULE_DEVICE_TABLE(pci, igc_pci_tbl);
>
> +static void igc_read_rar0(struct igc_hw *hw, u8 *addr, u32 *ral, u32
> +*rah) {
> + *ral = rd32(IGC_RAL(0));
> + *rah = rd32(IGC_RAH(0));
> +
> + addr[0] = *ral & 0xff;
> + addr[1] = (*ral >> 8) & 0xff;
> + addr[2] = (*ral >> 16) & 0xff;
> + addr[3] = (*ral >> 24) & 0xff;
> + addr[4] = *rah & 0xff;
> + addr[5] = (*rah >> 8) & 0xff;
> +}
> +
> +static bool igc_is_lmvp_device(struct pci_dev *pdev) {
> + switch (pdev->device) {
> + case IGC_DEV_ID_I225_LMVP:
> + case IGC_DEV_ID_I226_LMVP:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static void igc_wait_for_lmvp_mac_passthrough(struct pci_dev *pdev,
> + struct igc_hw *hw)
> +{
> + u8 addr[ETH_ALEN] __aligned(2);
> + u32 orig_ral, orig_rah;
> + u32 ral, rah;
> + int i;
> +
> + if (!igc_is_lmvp_device(pdev))
> + return;
> +
> + igc_read_rar0(hw, addr, &orig_ral, &orig_rah);
> +
> + for (i = 0; i < 100; i++) {
> + msleep(100);
> + igc_read_rar0(hw, addr, &ral, &rah);
> + if ((ral != orig_ral || rah != orig_rah) &&
> + is_valid_ether_addr(addr))
> + return;
> + }
> +}
> +
> enum latency_range {
> lowest_latency = 0,
> low_latency = 1,
> @@ -7259,6 +7306,7 @@ static int igc_probe(struct pci_dev *pdev,
> * known good starting state
> */
> hw->mac.ops.reset_hw(hw);
> + igc_wait_for_lmvp_mac_passthrough(pdev, hw);
>
> if (igc_get_flash_presence_i225(hw)) {
> if (hw->nvm.ops.validate(hw) < 0) {
> --
> 2.53.0
^ permalink raw reply
* Re: [BUG REPORT] KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg
From: Jiayuan Chen @ 2026-06-18 7:53 UTC (permalink / raw)
To: xietangxin, netdev, davem, edumazet, kuba, pabeni
Cc: horms, kuniyu, willemb, linux-kernel
In-Reply-To: <c953e09f-9bd5-43c8-b2e4-7305bb435229@yeah.net>
On 6/18/26 3:28 PM, xietangxin wrote:
> Hi all,
>
> We detected a data-race with syzkaller on master branch (commit 95e56f0f293e).
>
> The data-race occurs on `sk->sk_v6_daddr`. When a UDP socket is already in
> the ESTABLISHED state, calling sendmsg() with read `sk->sk_v6_daddr`.
> Concurrently, another thread call connect() on the same UDP socket to update
> the remote address, which writes to `sk->sk_v6_daddr`.
>
> Should we implement READ_ONCE/WRITE_ONCE helpers for `sk->sk_v6_daddr`
> to prevent torn reads? Or acquire the socket lock inside udpv6_sendmsg()
> to serialize with connect()?
>
> # KCSAN Report
> BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg
> read to 0xffff0000084dbc38 of 8 bytes by task 16916 on cpu 2:
> udpv6_sendmsg+0x1264/0x1a20 (/include/net/ipv6.h:593 net/ipv6/udp.c:1579)
> inet6_sendmsg+0x80/0xc0
> __sock_sendmsg+0xb0/0x138
> ____sys_sendmsg+0x41c/0x4f8
> ___sys_sendmsg+0xcc/0x150
> __sys_sendmsg+0xe8/0x190
> __arm64_sys_sendmsg+0x58/0x78
> invoke_syscall+0x84/0x218
> el0_svc_common.constprop.0+0x1a4/0x1f8
> do_el0_svc+0x3c/0x58
> el0_svc+0x38/0x100
> el0t_64_sync_handler+0xa0/0xe8
> el0t_64_sync+0x190/0x198
>
> write to 0xffff0000084dbc38 of 16 bytes by task 16901 on cpu 1:
> __ip6_datagram_connect+0x348/0x888 (/net/ipv6/datagram.c:247)
> udpv6_connect+0x48/0x178
> inet_dgram_connect+0xe0/0x1e0
> __sys_connect_file+0xd4/0x128
> __sys_connect+0xf0/0x130
> __arm64_sys_connect+0x54/0x78
> invoke_syscall+0x84/0x218
> el0_svc_common.constprop.0+0x1a4/0x1f8
> do_el0_svc+0x3c/0x58
> el0_svc+0x38/0x100
> el0t_64_sync_handler+0xa0/0xe8
> el0t_64_sync+0x190/0x198
>
> # Syzkaller Reproducer
> r0 = bpf$PROG_LOAD(0x5, &(0x7f00000001c0)={0x6, 0x4, &(0x7f0000000100)=ANY=[@ANYBLOB="18000000000000000000000000000000070000000200000095"], &(0x7f0000000040)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x9, '\x00', 0x0, @xdp=0x25, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3}, 0x94)
> bpf$BPF_PROG_TEST_RUN(0xa, &(0x7f00000002c0)={r0, 0x0, 0xe, 0x0, &(0x7f00000005c0)="d9d96e34a80e31f03a049a9e0000", 0x0, 0xb4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x39}, 0x50) (async, rerun: 32)
> r1 = socket$inet6(0xa, 0x2, 0x0) (rerun: 32)
> connect$inet6(r1, &(0x7f0000000040)={0xa, 0x4e23, 0x100200a, @loopback, 0x7f}, 0x1c) (async, rerun: 32)
> sendmsg$inet6(r1, &(0x7f00000002c0)={&(0x7f0000000140)={0xa, 0x4e22, 0x4, @remote, 0x2}, 0x1c, 0x0}, 0x4000001) (rerun: 32)
Already exist in syzbot with 11 similar reports.
https://syzkaller.appspot.com/bug?id=e3ef1f59aa88bf20425f0726337b0f6931416ff8
maybe data_race annotation should be used.
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add retry mechanism to airoha_qdma_set_trtcm_param()
From: Leto Liu (刘涛) @ 2026-06-18 7:52 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, netdev@vger.kernel.org,
Brown Huang (黃柏翰)
In-Reply-To: <aiqHgJ6FiAMu5gmF@lore-desk>
>I think the issue reported by sashiko in [0] is valid and it needs to be addressed in v2, but since I am not the original author of the patch, I will let Brown or Leto comment on it.
>
>Regards,
>Lorenzo
>
Thanks for the careful review — you are absolutely right.
In the current version, the immediate call to airoha_qdma_get_trtcm_param() can indeed clobber the write command we just issued. That helper programs REG_TRTCM_CFG_PARAM() to start a read transaction, so without first waiting for TRTCM_PARAM_RW_DONE_MASK after the write, we may overwrite the command register before the hardware has latched/finished the write. The added wmb() only enforces the ordering between the DATA and CFG writes, but it does not guarantee the write transaction has completed.
I will address this by restoring the DONE polling after the write, and only then performing the read-back verification (i.e. “write → poll DONE → read-back → compare”, with retries as needed). Also, to avoid clobbering the val argument, the poll will use a separate temporary variable.
I have revised the patch into a v2 version based on this approach, and it is currently under testing and validation. Since this is an intermittent issue, I am running long-duration stability tests. I expect to provide the v2 patch by next Monday.
Best Regards, Leto
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix TX scheduler queue mask loop upper bound
From: Lorenzo Bianconi @ 2026-06-18 7:42 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178166704952.2212140.11002626760717132754@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
> In airoha_qdma_set_chan_tx_sched(), the loop clearing queue mask was
> using AIROHA_NUM_TX_RING (32) instead of AIROHA_NUM_QOS_QUEUES (8).
>
> Each channel has 8 queues, and TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i)
> computes BIT(i + (channel * 8)). With i ranging 0..31, this causes:
> - channel 0: clears bit 0..31 (all 4 channels) instead of 0..7
> - channel 1: clears bit 8..31 (channels 1-3) instead of 8..15
> - channel 2: clears bit 16..31 (channels 2-3) instead of 16..23
> - channel 3: clears bit 24..31 (channel 3 only) - correct by accident
>
> While BIT(32+) on arm64 produces 64-bit values truncated to 0 in u32
> mask parameter, the loop still incorrectly clears queues within the
> same channel beyond queue 7.
>
> Fix by using AIROHA_NUM_QOS_QUEUES (8) as the loop upper bound.
I guess it is ok now if you respin this patch on top of net branch.
If so, please add my Acked-by.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Fixes: ef1ca9271313 ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..a1eda13400 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2217,7 +2217,7 @@ static int airoha_qdma_set_chan_tx_sched(struct net_device *dev,
> struct airoha_gdm_port *port = netdev_priv(dev);
> int i;
>
> - for (i = 0; i < AIROHA_NUM_TX_RING; i++)
> + for (i = 0; i < AIROHA_NUM_QOS_QUEUES; i++)
> airoha_qdma_clear(port->qdma, REG_QUEUE_CLOSE_CFG(channel),
> TXQ_DISABLE_CHAN_QUEUE_MASK(channel, i));
>
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [BUG REPORT] KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg
From: xietangxin @ 2026-06-18 7:28 UTC (permalink / raw)
To: netdev, davem, edumazet, kuba, pabeni
Cc: horms, kuniyu, willemb, linux-kernel
Hi all,
We detected a data-race with syzkaller on master branch (commit 95e56f0f293e).
The data-race occurs on `sk->sk_v6_daddr`. When a UDP socket is already in
the ESTABLISHED state, calling sendmsg() with read `sk->sk_v6_daddr`.
Concurrently, another thread call connect() on the same UDP socket to update
the remote address, which writes to `sk->sk_v6_daddr`.
Should we implement READ_ONCE/WRITE_ONCE helpers for `sk->sk_v6_daddr`
to prevent torn reads? Or acquire the socket lock inside udpv6_sendmsg()
to serialize with connect()?
# KCSAN Report
BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg
read to 0xffff0000084dbc38 of 8 bytes by task 16916 on cpu 2:
udpv6_sendmsg+0x1264/0x1a20 (/include/net/ipv6.h:593 net/ipv6/udp.c:1579)
inet6_sendmsg+0x80/0xc0
__sock_sendmsg+0xb0/0x138
____sys_sendmsg+0x41c/0x4f8
___sys_sendmsg+0xcc/0x150
__sys_sendmsg+0xe8/0x190
__arm64_sys_sendmsg+0x58/0x78
invoke_syscall+0x84/0x218
el0_svc_common.constprop.0+0x1a4/0x1f8
do_el0_svc+0x3c/0x58
el0_svc+0x38/0x100
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x190/0x198
write to 0xffff0000084dbc38 of 16 bytes by task 16901 on cpu 1:
__ip6_datagram_connect+0x348/0x888 (/net/ipv6/datagram.c:247)
udpv6_connect+0x48/0x178
inet_dgram_connect+0xe0/0x1e0
__sys_connect_file+0xd4/0x128
__sys_connect+0xf0/0x130
__arm64_sys_connect+0x54/0x78
invoke_syscall+0x84/0x218
el0_svc_common.constprop.0+0x1a4/0x1f8
do_el0_svc+0x3c/0x58
el0_svc+0x38/0x100
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x190/0x198
# Syzkaller Reproducer
r0 = bpf$PROG_LOAD(0x5, &(0x7f00000001c0)={0x6, 0x4, &(0x7f0000000100)=ANY=[@ANYBLOB="18000000000000000000000000000000070000000200000095"], &(0x7f0000000040)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x9, '\x00', 0x0, @xdp=0x25, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x3}, 0x94)
bpf$BPF_PROG_TEST_RUN(0xa, &(0x7f00000002c0)={r0, 0x0, 0xe, 0x0, &(0x7f00000005c0)="d9d96e34a80e31f03a049a9e0000", 0x0, 0xb4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x0, 0x39}, 0x50) (async, rerun: 32)
r1 = socket$inet6(0xa, 0x2, 0x0) (rerun: 32)
connect$inet6(r1, &(0x7f0000000040)={0xa, 0x4e23, 0x100200a, @loopback, 0x7f}, 0x1c) (async, rerun: 32)
sendmsg$inet6(r1, &(0x7f00000002c0)={&(0x7f0000000140)={0xa, 0x4e22, 0x4, @remote, 0x2}, 0x1c, 0x0}, 0x4000001) (rerun: 32)
--
Best regards,
Tangxin Xie
^ permalink raw reply
* Re: [PATCH] net: airoha: Stop TX queues on error path in airoha_dev_open
From: Lorenzo Bianconi @ 2026-06-18 7:33 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Wayen Yan, netdev, horms, pabeni, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260617164448.31e189bc@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
> On Tue, 16 Jun 2026 18:50:39 +0800 Wayen Yan wrote:
> > In airoha_dev_open(), if airoha_set_vip_for_gdm_port() fails after
> > netif_tx_start_all_queues() has been called, the TX queues remain
> > started while the device configuration is incomplete. This leaves
> > the device in an inconsistent state where packets could be
> > transmitted before the VIP/IFC port configuration is complete.
>
> Not sure if this was superseded by another posting but FWIW
> this posting did not apply.
I think we do not need this patch.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 2/2] igc: Cache MAC passthrough address
From: Chia-Lin Kao (AceLan) @ 2026-06-18 7:33 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20260618073324.1843310-1-acelan.kao@canonical.com>
Remember the MAC address that firmware writes into RAL0/RAH0 after reset.
On later probes, wait for that cached passthrough address instead of using
any valid register change as the completion condition.
This keeps the first probe conservative and lets later dock replug cycles
use the known passthrough address once the platform has already shown that
firmware can rewrite the address registers.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
---
drivers/net/ethernet/intel/igc/igc_main.c | 41 +++++++++++++++++++++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index fa9752ed8bc5..cf87a82f1bf8 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -12,6 +12,7 @@
#include <linux/bpf_trace.h>
#include <net/xdp_sock_drv.h>
#include <linux/etherdevice.h>
+#include <linux/mutex.h>
#include <linux/pci.h>
#include <linux/mdio.h>
@@ -70,6 +71,32 @@ static const struct pci_device_id igc_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, igc_pci_tbl);
+static bool igc_mac_passthrough_cached;
+static u8 igc_mac_passthrough_addr[ETH_ALEN] __aligned(2);
+static DEFINE_MUTEX(igc_mac_passthrough_lock);
+
+static bool igc_get_mac_passthrough_addr(u8 *addr)
+{
+ mutex_lock(&igc_mac_passthrough_lock);
+ if (!igc_mac_passthrough_cached) {
+ mutex_unlock(&igc_mac_passthrough_lock);
+ return false;
+ }
+
+ ether_addr_copy(addr, igc_mac_passthrough_addr);
+ mutex_unlock(&igc_mac_passthrough_lock);
+
+ return true;
+}
+
+static void igc_cache_mac_passthrough_addr(u8 *addr)
+{
+ mutex_lock(&igc_mac_passthrough_lock);
+ ether_addr_copy(igc_mac_passthrough_addr, addr);
+ igc_mac_passthrough_cached = true;
+ mutex_unlock(&igc_mac_passthrough_lock);
+}
+
static void igc_read_rar0(struct igc_hw *hw, u8 *addr, u32 *ral, u32 *rah)
{
*ral = rd32(IGC_RAL(0));
@@ -97,22 +124,32 @@ static bool igc_is_lmvp_device(struct pci_dev *pdev)
static void igc_wait_for_lmvp_mac_passthrough(struct pci_dev *pdev,
struct igc_hw *hw)
{
+ u8 cached_addr[ETH_ALEN] __aligned(2);
u8 addr[ETH_ALEN] __aligned(2);
u32 orig_ral, orig_rah;
u32 ral, rah;
+ bool cached;
int i;
if (!igc_is_lmvp_device(pdev))
return;
+ cached = igc_get_mac_passthrough_addr(cached_addr);
igc_read_rar0(hw, addr, &orig_ral, &orig_rah);
+ if (cached && ether_addr_equal(addr, cached_addr))
+ return;
for (i = 0; i < 100; i++) {
msleep(100);
igc_read_rar0(hw, addr, &ral, &rah);
- if ((ral != orig_ral || rah != orig_rah) &&
- is_valid_ether_addr(addr))
+ if (cached) {
+ if (ether_addr_equal(addr, cached_addr))
+ return;
+ } else if ((ral != orig_ral || rah != orig_rah) &&
+ is_valid_ether_addr(addr)) {
+ igc_cache_mac_passthrough_addr(addr);
return;
+ }
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] igc: Wait for MAC passthrough after reset
From: Chia-Lin Kao (AceLan) @ 2026-06-18 7:33 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, intel-wired-lan, netdev, linux-kernel
Some systems support MAC passthrough for dock Ethernet controllers by
having firmware rewrite the receive address registers after the controller
reset completes.
igc resets the controller before reading RAL0/RAH0, so that reset can
restore the controller native MAC address temporarily. If the driver reads
the registers immediately, it can race the firmware rewrite and keep the
native dock MAC instead of the host passthrough MAC.
For LMVP devices, poll RAL0/RAH0 after reset and before reading the MAC
address. Stop once the address registers change to another valid Ethernet
address, allowing firmware a bounded window to complete the passthrough
update.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
---
drivers/net/ethernet/intel/igc/igc_main.c | 48 +++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 2c9e2dfd8499..fa9752ed8bc5 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -11,6 +11,7 @@
#include <net/pkt_sched.h>
#include <linux/bpf_trace.h>
#include <net/xdp_sock_drv.h>
+#include <linux/etherdevice.h>
#include <linux/pci.h>
#include <linux/mdio.h>
@@ -69,6 +70,52 @@ static const struct pci_device_id igc_pci_tbl[] = {
MODULE_DEVICE_TABLE(pci, igc_pci_tbl);
+static void igc_read_rar0(struct igc_hw *hw, u8 *addr, u32 *ral, u32 *rah)
+{
+ *ral = rd32(IGC_RAL(0));
+ *rah = rd32(IGC_RAH(0));
+
+ addr[0] = *ral & 0xff;
+ addr[1] = (*ral >> 8) & 0xff;
+ addr[2] = (*ral >> 16) & 0xff;
+ addr[3] = (*ral >> 24) & 0xff;
+ addr[4] = *rah & 0xff;
+ addr[5] = (*rah >> 8) & 0xff;
+}
+
+static bool igc_is_lmvp_device(struct pci_dev *pdev)
+{
+ switch (pdev->device) {
+ case IGC_DEV_ID_I225_LMVP:
+ case IGC_DEV_ID_I226_LMVP:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void igc_wait_for_lmvp_mac_passthrough(struct pci_dev *pdev,
+ struct igc_hw *hw)
+{
+ u8 addr[ETH_ALEN] __aligned(2);
+ u32 orig_ral, orig_rah;
+ u32 ral, rah;
+ int i;
+
+ if (!igc_is_lmvp_device(pdev))
+ return;
+
+ igc_read_rar0(hw, addr, &orig_ral, &orig_rah);
+
+ for (i = 0; i < 100; i++) {
+ msleep(100);
+ igc_read_rar0(hw, addr, &ral, &rah);
+ if ((ral != orig_ral || rah != orig_rah) &&
+ is_valid_ether_addr(addr))
+ return;
+ }
+}
+
enum latency_range {
lowest_latency = 0,
low_latency = 1,
@@ -7259,6 +7306,7 @@ static int igc_probe(struct pci_dev *pdev,
* known good starting state
*/
hw->mac.ops.reset_hw(hw);
+ igc_wait_for_lmvp_mac_passthrough(pdev, hw);
if (igc_get_flash_presence_i225(hw)) {
if (hw->nvm.ops.validate(hw) < 0) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] xfrm: validate selector family and prefixlen during match
From: Steffen Klassert @ 2026-06-18 7:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet, syzbot+9383b1ff0df4b29ca5e6,
Sabrina Dubroca
In-Reply-To: <20260615090237.2689082-1-edumazet@google.com>
On Mon, Jun 15, 2026 at 09:02:37AM +0000, Eric Dumazet wrote:
> syzbot reported a shift-out-of-bounds in xfrm_selector_match()
> due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched
> against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).
>
> Fix this by:
>
> - Rejecting mismatched families in xfrm_selector_match.
> - Returning false in addr4_match if prefixlen > 32.
> - Returning false in addr_match if prefixlen > 128 (prevents overflow).
>
> Fixes: 3f0ab59e6537 ("xfrm: validate new SA's prefixlen using SA family when sel.family is unset")
> Reported-by: syzbot+9383b1ff0df4b29ca5e6@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/6a2fbe35.be3f099c.2836ae.0018.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Also applied, thanks a lot!
^ permalink raw reply
* Re: [PATCH ipsec] espintcp: use sk_msg_free_partial to fix partial send
From: Steffen Klassert @ 2026-06-18 7:24 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev, stable, Aaron Esau, Yiming Qian
In-Reply-To: <68ef5bdae251f605b0743d2e51c2a5cb285e5772.1781270325.git.sd@queasysnail.net>
On Fri, Jun 12, 2026 at 04:11:39PM +0200, Sabrina Dubroca wrote:
> sk_msg_free_partial() ensures consistency of the skmsg at every
> iteration, without having to manually handle uncharges and offsets.
> This simplifies the code, and fixes some bugs in skmsg accounting when
> we don't send the full contents.
>
> Cc: stable@vger.kernel.org
> Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
> Reported-by: Aaron Esau <aaron1esau@gmail.com>
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied, thanks a lot Sabrina!
^ permalink raw reply
* Re: [PATCH net] xfrm: annotate data-races around xfrm_policy_count[] and xfrm_policy_default[]
From: Steffen Klassert @ 2026-06-18 7:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet, syzbot+d85ba1c732720b9a4097, Herbert Xu
In-Reply-To: <20260612055634.3560352-1-edumazet@google.com>
On Fri, Jun 12, 2026 at 05:56:34AM +0000, Eric Dumazet wrote:
> KCSAN reported a data race involving net->xfrm.policy_count access.
>
> Add missing READ_ONCE()/WRITE_ONCE() annotations on
> xfrm_policy_count and xfrm_policy_default.
>
> Fixes: 2518c7c2b3d7 ("[XFRM]: Hash policies when non-prefixed.")
> Reported-by: syzbot+d85ba1c732720b9a4097@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/6a2b9e96.99669fcc.12a77b.0006.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied to the ipsec tree, thanks a lot Eric!
^ permalink raw reply
* Re: [PATCH] xfrm: Fix xfrm state cache insertion race
From: Steffen Klassert @ 2026-06-18 7:23 UTC (permalink / raw)
To: Simon Horman
Cc: Herbert Xu, netdev, Linus Torvalds, Jakub Kicinski, Paolo Abeni,
zdi-disclosures@trendmicro.com, Willy Tarreau
In-Reply-To: <20260615084321.GE712698@horms.kernel.org>
On Mon, Jun 15, 2026 at 09:43:21AM +0100, Simon Horman wrote:
> On Fri, Jun 12, 2026 at 12:58:59PM +0800, Herbert Xu wrote:
> > The xfrm input state cache insertion code checks the validity of
> > the state before acquiring the global xfrm_state_lock. Thus it's
> > possible for someone else to kill the state after it passed the
> > validity check, and then the insertion will add the dead state
> > to the cache.
> >
> > Fix this by moving the validity check inside the lock.
> >
> > This entire function is called on the input path, where BH must
> > be off (e.g., the caller of this function xfrm_input acquires
> > its spinlocks without disabling BH).
> >
> > So there is no need to disable BH here or take the RCU read lock.
> > Remove both and replace them with an assertion that trips if BH
> > is accidentally enabled on some future calling path.
> >
> > Fixes: 81a331a0e72d ("xfrm: Add an inbound percpu state cache.")
> > Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
Applied, thanks everyone!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox