* Re: [PATCH v3 0/3] net: stmmac: L3/L4 filter bug fixes
From: Maxime Chevallier @ 2026-06-16 6:06 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, rmk+kernel,
Jose.Abreu, linux-kernel
In-Reply-To: <20260616042655.7782-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
Hi Nazim,
On 6/16/26 06:26, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> This series fixes three bugs in the stmmac L3/L4 TC flower filter
> implementation for the XGMAC2 core. All three patches target net.
>
> The L3/L4 filter match count statistics patch (originally patch 4/4)
> has been split out and will be sent separately against net-next per
> Andrew Lunn's review of v1.
>
> Patch 1 fixes a register corruption bug in the L4 filter port configuration.
> The XGMAC_L4_ADDR register holds both source and destination port match
> values in a single register. The original code overwrites the entire register
> when setting either field, silently erasing the other. This is fixed by
> using a read-modify-write sequence.
>
> Patch 2 fixes the basic flow match parser to properly reject unsupported
> offload requests with -EOPNOTSUPP instead of silently accepting them.
> Unsupported cases include partial protocol masks, non-IPv4 network proto,
> and non-TCP/UDP transport proto. Extack messages are now included so users
> know exactly which part of the match is unsupported. The -EOPNOTSUPP is
> also now returned directly instead of using break, which was silently
> discarding the error on FLOW_CLS_REPLACE operations.
>
> Patch 3 fixes a stale action bug on filter deletion. When a filter entry
> with a drop action is deleted, the action field was not reset, causing
> it to persist and potentially affect subsequent filter configurations.
>
> All three patches fix the original L3/L4 filter implementation introduced in
> 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower").
>
> Changes in v3:
> - Patch 2: add extack messages to each -EOPNOTSUPP return (Jakub Kicinski)
> - Patch 2: return -EOPNOTSUPP directly instead of break to avoid silently
> reporting success on unsupported FLOW_CLS_REPLACE (Sashiko review)
Please take a look at this page prior to reposting :
https://netdev.bots.linux.dev/net-next.html
There's also an announcement made on the netdev@ list when net-next
opens/closes.
You can't submit new series that target net-next during the merge window,
this revision will have to wait 2 weeks.
Maxime
^ permalink raw reply
* Re: [BUG] kernel BUG in team driver: buffer overflow in team_add_slave()
From: Yeswanth Krishna @ 2026-06-16 6:08 UTC (permalink / raw)
To: netdev, venkat88; +Cc: linux-kernel, linuxppc-dev
In-Reply-To: <a08b0a7f-089f-4428-9360-9edbec3a5453@linux.ibm.com>
> Please add below reported-by tag:
> Reported-by: Yeswanth Krishna Tellakula <yeswanth@linux.ibm.com>\
>
>
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] selftests/bpf: Cover small conntrack opts error writes
From: bot+bpf-ci @ 2026-06-16 6:19 UTC (permalink / raw)
To: chenyy23, bpf, netfilter-devel
Cc: chenyy23, pablo, fw, phil, davem, edumazet, kuba, pabeni, horms,
andrii, eddyz87, ast, daniel, memxor, martin.lau, song,
yonghong.song, jolsa, emil, shuah, kartikey406, coreteam, netdev,
linux-kernel, linux-kselftest, ast, andrii, daniel, martin.lau,
eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <c4c898dd23181b676ebf6b6b4d9c54f51bb69c75.1781586477.git.chenyy23@mails.tsinghua.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
> selftests/bpf: Cover small conntrack opts error writes
>
> Add a conntrack kfunc regression check for opts__sz values that do not
> cover opts->error. The BPF program initializes opts->error with a guard
> value, calls the lookup and allocation kfuncs with opts__sz set to
> sizeof(opts->netns_id), and verifies that the guard is still intact
> after the kfunc returns NULL.
>
> Without the conntrack wrapper guard, the kfunc error path overwrites
> that guard with -EINVAL even though the verifier checked only the first
> four bytes of the options object.
>
> Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
This is a regression test for the out-of-bounds opts->error write that
is fixed in the prior series commit 86b813c37ee5 ("bpf: Guard conntrack
opts error writes"), but it carries no Fixes: tags.
A regression test usually carries the same Fixes: tags as the fix it
covers, so it gets backported to stable alongside that fix. The two new
test cases map onto the two commits that introduced the kfuncs: the
small-opts lookup case covers the lookup kfunc and the small-opts alloc
case covers the alloc kfunc.
Should this include:
Fixes: b4c2b9593a1c ("net/netfilter: Add unstable CT lookup helpers for XDP and TC-BPF")
Fixes: d7e79c97c00c ("net: netfilter: Add kfuncs to allocate and insert CT")
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27597459087
^ permalink raw reply
* Re: [BUG] kernel BUG in team driver: buffer overflow in team_add_slave()
From: Mukesh Kumar Chaurasiya @ 2026-06-16 6:26 UTC (permalink / raw)
To: Yeswanth Krishna; +Cc: netdev, venkat88, linux-kernel, linuxppc-dev
In-Reply-To: <ad80ee33-400b-4c63-8197-838c3cf85cef@linux.ibm.com>
On Tue, Jun 16, 2026 at 11:38:37AM +0530, Yeswanth Krishna wrote:
>
> > Please add below reported-by tag:
> > Reported-by: Yeswanth Krishna Tellakula <yeswanth@linux.ibm.com>\
> >
> >
I am also not able to reproduce it.
Can you paste the full report of the crash?
Regards,
Mukesh
^ permalink raw reply
* [PATCH 5.10/5.15/6.1/6.6/6.12/6.18] ipvs: skip ipv6 extension headers for csum checks
From: Nazar Kalashnikov @ 2026-06-16 6:30 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman
Cc: Nazar Kalashnikov, Simon Horman, Julian Anastasov,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Phil Sutter, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Venkata Mohan Reddy, Patrick McHardy, Julius Volz,
netdev, lvs-devel, netfilter-devel, coreteam, linux-kernel,
Wensong Zhang, lvc-project
From: Julian Anastasov <ja@ssi.bg>
commit 05cfe9863ef049d98141dc2969eefde72fb07625 upstream.
Protocol checksum validation fails for IPv6 if there are extension
headers before the protocol header. iph->len already contains its
offset, so use it to fix the problem.
Fixes: 2906f66a5682 ("ipvs: SCTP Trasport Loadbalancing Support")
Fixes: 0bbdd42b7efa ("IPVS: Extend protocol DNAT/SNAT and state handlers")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Nazar Kalashnikov <nazarkalashnikov0@gmail.com>
---
Backport fix for CVE-2026-45850
net/netfilter/ipvs/ip_vs_proto_sctp.c | 18 ++++++------------
net/netfilter/ipvs/ip_vs_proto_tcp.c | 21 +++++++--------------
net/netfilter/ipvs/ip_vs_proto_udp.c | 20 +++++++-------------
3 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index 83e452916403..63c78a1f3918 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -10,7 +10,8 @@
#include <net/ip_vs.h>
static int
-sctp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp);
+sctp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp,
+ unsigned int sctphoff);
static int
sctp_conn_schedule(struct netns_ipvs *ipvs, int af, struct sk_buff *skb,
@@ -108,7 +109,7 @@ sctp_snat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
int ret;
/* Some checks before mangling */
- if (!sctp_csum_check(cp->af, skb, pp))
+ if (!sctp_csum_check(cp->af, skb, pp, sctphoff))
return 0;
/* Call application helper if needed */
@@ -156,7 +157,7 @@ sctp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
int ret;
/* Some checks before mangling */
- if (!sctp_csum_check(cp->af, skb, pp))
+ if (!sctp_csum_check(cp->af, skb, pp, sctphoff))
return 0;
/* Call application helper if needed */
@@ -185,19 +186,12 @@ sctp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
}
static int
-sctp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
+sctp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp,
+ unsigned int sctphoff)
{
- unsigned int sctphoff;
struct sctphdr *sh;
__le32 cmp, val;
-#ifdef CONFIG_IP_VS_IPV6
- if (af == AF_INET6)
- sctphoff = sizeof(struct ipv6hdr);
- else
-#endif
- sctphoff = ip_hdrlen(skb);
-
sh = (struct sctphdr *)(skb->data + sctphoff);
cmp = sh->checksum;
val = sctp_compute_cksum(skb, sctphoff);
diff --git a/net/netfilter/ipvs/ip_vs_proto_tcp.c b/net/netfilter/ipvs/ip_vs_proto_tcp.c
index 7da51390cea6..ede4fa3b63f5 100644
--- a/net/netfilter/ipvs/ip_vs_proto_tcp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_tcp.c
@@ -29,7 +29,8 @@
#include <net/ip_vs.h>
static int
-tcp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp);
+tcp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp,
+ unsigned int tcphoff);
static int
tcp_conn_schedule(struct netns_ipvs *ipvs, int af, struct sk_buff *skb,
@@ -166,7 +167,7 @@ tcp_snat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
int ret;
/* Some checks before mangling */
- if (!tcp_csum_check(cp->af, skb, pp))
+ if (!tcp_csum_check(cp->af, skb, pp, tcphoff))
return 0;
/* Call application helper if needed */
@@ -244,7 +245,7 @@ tcp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
int ret;
/* Some checks before mangling */
- if (!tcp_csum_check(cp->af, skb, pp))
+ if (!tcp_csum_check(cp->af, skb, pp, tcphoff))
return 0;
/*
@@ -301,17 +302,9 @@ tcp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
static int
-tcp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
+tcp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp,
+ unsigned int tcphoff)
{
- unsigned int tcphoff;
-
-#ifdef CONFIG_IP_VS_IPV6
- if (af == AF_INET6)
- tcphoff = sizeof(struct ipv6hdr);
- else
-#endif
- tcphoff = ip_hdrlen(skb);
-
switch (skb->ip_summed) {
case CHECKSUM_NONE:
skb->csum = skb_checksum(skb, tcphoff, skb->len - tcphoff, 0);
@@ -322,7 +315,7 @@ tcp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
if (csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
&ipv6_hdr(skb)->daddr,
skb->len - tcphoff,
- ipv6_hdr(skb)->nexthdr,
+ IPPROTO_TCP,
skb->csum)) {
IP_VS_DBG_RL_PKT(0, af, pp, skb, 0,
"Failed checksum for");
diff --git a/net/netfilter/ipvs/ip_vs_proto_udp.c b/net/netfilter/ipvs/ip_vs_proto_udp.c
index 68260d91c988..ffbebda547fc 100644
--- a/net/netfilter/ipvs/ip_vs_proto_udp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_udp.c
@@ -25,7 +25,8 @@
#include <net/ip6_checksum.h>
static int
-udp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp);
+udp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp,
+ unsigned int udphoff);
static int
udp_conn_schedule(struct netns_ipvs *ipvs, int af, struct sk_buff *skb,
@@ -155,7 +156,7 @@ udp_snat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
int ret;
/* Some checks before mangling */
- if (!udp_csum_check(cp->af, skb, pp))
+ if (!udp_csum_check(cp->af, skb, pp, udphoff))
return 0;
/*
@@ -238,7 +239,7 @@ udp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
int ret;
/* Some checks before mangling */
- if (!udp_csum_check(cp->af, skb, pp))
+ if (!udp_csum_check(cp->af, skb, pp, udphoff))
return 0;
/*
@@ -297,17 +298,10 @@ udp_dnat_handler(struct sk_buff *skb, struct ip_vs_protocol *pp,
static int
-udp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
+udp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp,
+ unsigned int udphoff)
{
struct udphdr _udph, *uh;
- unsigned int udphoff;
-
-#ifdef CONFIG_IP_VS_IPV6
- if (af == AF_INET6)
- udphoff = sizeof(struct ipv6hdr);
- else
-#endif
- udphoff = ip_hdrlen(skb);
uh = skb_header_pointer(skb, udphoff, sizeof(_udph), &_udph);
if (uh == NULL)
@@ -325,7 +319,7 @@ udp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
if (csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
&ipv6_hdr(skb)->daddr,
skb->len - udphoff,
- ipv6_hdr(skb)->nexthdr,
+ IPPROTO_UDP,
skb->csum)) {
IP_VS_DBG_RL_PKT(0, af, pp, skb, 0,
"Failed checksum for");
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Joanne Koong @ 2026-06-16 6:38 UTC (permalink / raw)
To: Askar Safin
Cc: akpm, axboe, bernd, brauner, david, dhowells, fuse-devel, hch,
jack, linux-api, linux-fsdevel, linux-kernel, linux-mm, miklos,
netdev, patches, pfalcato, rostedt, torvalds, val, viro, willy
In-Reply-To: <20260616011516.4039110-1-safinaskar@gmail.com>
On Mon, Jun 15, 2026 at 9:15 PM Askar Safin <safinaskar@gmail.com> wrote:
>
> Joanne Koong <joannelkoong@gmail.com>:
> > > speaking of fuse_dev_splice……_write actually, this series has broken
> > > xdg-document-portal!
> > >
> > > https://github.com/flatpak/xdg-desktop-portal/issues/2026
> > >
> > > Specifically what happens is that the EINVAL is returned due to oh.len
> > > != nbytes:
> > >
> > > fuse_dev_do_write: oh.len 16400 != nbytes 15526
> > >
> > > (where 16400 == 16384 (read len) + 16, 15526 == 15510 (file len) + 16)
> > >
> > > After reverting the series, there is no error because oh.len
> > > becomes 15526 too.
> >
> > I think this is because of how libfuse handles eof / short reads. When
> > it detects a short read, it fixes up the header length after the
> > header was already vmspliced to the pipe because it assumes vmsplice
> > mapped the header's page into the pipe by reference. It assumes that
> > modifying the header length in place gets then reflected in what the
> > pipe later splices out.
> >
> > The logic for this happens in fuse_send_data_iov() [1]:
> > a) sets out->len = headerlen (16) + len (16384) = 16400 in the
> > stack-allocated fuse_out_header
> > b) vmsplices the header to the pipe
> > c) splices the backing file to the pipe. if this hits EOF, it'll get
> > back 15510 instead of 16384
> > d) detects the short read [2], fixes up the stack out->len = 16 + 15510 = 15526
> > e) splices the pipe to /dev/fuse
> >
> > After this patch, step b) is a straight copy which means step d)'s
> > fixup doesn't modify what's in the pipe. This could be fixed up in
> > libfuse to not depend on modify-after-vmsplice, but I don't think this
> > helps for applications using already-released libfuse versions. I
> > think this patch needs to be reverted.
> >
> > Thanks,
> > Joanne
> >
> > [1] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L846
> > [2] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L956
>
> Uh, this is very unfortunate. But I still want to remove vmsplice.
> Maybe we can somehow save my patchsets? For example, let's return EINVAL
> for this particular combination (writable pipe + SPLICE_F_NONBLOCK).
writable pipe + SPLICE_F_NONBLOCK is a valid vmsplice call today, so I
think returning -EINVAL would still cause regressions. It happens to
be a workaround for libfuse only because libfuse falls back to
writev() when vmsplice fails, but I don't think we can assume other
callers have the same fallback.
Thanks,
Joanne
>
> --
> Askar Safin
^ permalink raw reply
* Re: [PATCH net] net: dsa: Fix skb ownership in taggers
From: Kurt Kanzenbach @ 2026-06-16 6:38 UTC (permalink / raw)
To: Linus Walleij, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Florian Fainelli, Jonas Gorski, Hauke Mehrtens, Woojung Huh,
UNGLinuxDriver, Chester A. Unal, Daniel Golle, Matthias Brugger,
AngeloGioacchino Del Regno, Wei Fang, Clark Wang,
Clément Léger, George McCollister, David Yang
Cc: netdev, Sashiko AI Review, Linus Walleij
In-Reply-To: <20260616-dsa-fix-free-skb-v1-1-fd30b35dcf66@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]
On Tue Jun 16 2026, Linus Walleij wrote:
> The tag_8021q.c tagger calls vlan_insert_tag() in dsa_8021q_xmit().
> vlan_insert_tag() will consume the skb with kfree_skb() on failure
> and return NULL.
>
> When NULL is returned as error code to ->xmit() in dsa_user_xmit()
> it will free the same skb again leading to a double-free.
>
> The idea of dsa_user_xmit() and dsa_switch_rcv() dropping the skb
> they held before the call to ->xmit() and ->rcv() is conceptually
> wrong: the pattern elsewhere in the networking code is that consumers
> drop their skb:s on failure.
>
> Modify the ->xmit() and ->rcv() call sites to not drop the SKB if
> the taggers return NULL from any of these calls. Move those drops into
> the taggers so every callback error path that retains ownership consumes
> the skb before returning NULL.
>
> Keep the existing helper ownership rules: VLAN insertion helpers already
> free on failure (this is the case in tag_8021q.c), while deferred
> transmit paths either transfer the skb reference to worker context or
> hold a worker reference with skb_get() and drop the caller's reference.
>
> For SJA1105 meta RX, transfer the buffered stampable skb under the meta
> lock and return NULL while the skb is waiting for its meta frame: the
> skb is not dropped in this case.
>
> Reported-by: Sashiko AI Review <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260610153952.1685895-1-kuba@kernel.org/
> Suggested-by: Jakub Kicinski <kuba@kernel.org>
> Assisted-by: Codex:gpt-5-5
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Acked-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek
> ---
> net/dsa/tag_hellcreek.c | 9 +++++++--
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply
* [PATCH net] net: llc: make empty have static storage duration
From: Wentao Guan @ 2026-06-16 6:40 UTC (permalink / raw)
To: kuba; +Cc: joel.granados, netdev, linux-kernel, zhanjun, niecheng1,
Wentao Guan
Make empty have static storage duration (like net/sysctl_net.c does) to
avoid a potential use-after-return and keep consistent with
__register_sysctl_table @table 'should not be free'd after registration'.
Fixes: 73dbd8cf7947 ("net: Remove ctl_table sentinel elements from several networking subsystems")
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
net/llc/sysctl_net_llc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/llc/sysctl_net_llc.c b/net/llc/sysctl_net_llc.c
index c8d88e2508fce..15f1e5d88f208 100644
--- a/net/llc/sysctl_net_llc.c
+++ b/net/llc/sysctl_net_llc.c
@@ -47,7 +47,7 @@ static struct ctl_table_header *llc_station_header;
int __init llc_sysctl_init(void)
{
- struct ctl_table empty[1] = {};
+ static struct ctl_table empty[1] = {};
llc2_timeout_header = register_net_sysctl(&init_net, "net/llc/llc2/timeout", llc2_timeout_table);
llc_station_header = register_net_sysctl_sz(&init_net, "net/llc/station", empty, 0);
--
2.30.2
^ permalink raw reply related
* 回复：[PATCH v18 net-next 07/11] net/nebula-matrix: add intr resource implementation
From: Illusion Wang @ 2026-06-16 6:45 UTC (permalink / raw)
To: Illusion Wang, Dimon, Alvin, Sam, netdev
Cc: andrew+netdev, corbet, kuba, horms, linux-doc, pabeni,
vadim.fedorenko, lukas.bulwahn, edumazet, enelsonmoore, skhan,
hkallweit1, open list
In-Reply-To: <20260611044916.2383-8-illusion.wang@nebula-matrix.com>
>commit 7a32ca8335c9041ec03b80d30716c474e81723ad
>Author: illusion.wang <illusion.wang@nebula-matrix.com>
>net/nebula-matrix: add intr resource implementation
>This patch adds the nbl_interrupt module for management of driver-private
>MSI-X indices, plus hw_ops callbacks to program the function MSI-X mapping
>registers, configure MSI-X info, and enable mailbox interrupts.
>> diff --git a/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c
>> new file mode 100644
>> index 0000000000000..6d6924e7d9a82
>> --- /dev/null
>> +++ b/drivers/net/ethernet/nebula-matrix/nbl/nbl_hw/nbl_interrupt.c
>[ ... ]
>> +int nbl_res_intr_destroy_msix_map(struct nbl_resource_mgt *res_mgt,
>> + u16 func_id)
>> +{
>[ ... ]
>> + /* use ctrl dev bdf */
>> + hw_ops->configure_msix_map(res_mgt->hw_ops_tbl->priv, func_id, false, 0,
>> + 0, 0, 0);
>> +
>> + intr_mgt->func_intr_res[func_id].interrupts = NULL;
>> + intr_mgt->func_intr_res[func_id].num_interrupts = 0;
>> + intr_mgt->func_intr_res[func_id].num_net_interrupts = 0;
>> + hw_ops->flush_write(res_mgt->hw_ops_tbl->priv);
>> +
>> + return 0;
>> +}
>Does this code leak the device-managed memory? nbl_res_intr_configure_msix_map()
>allocates interrupts via devm_kcalloc() and msix_map_table->base_addr via
>dmam_alloc_coherent(). Setting the pointer to NULL here without calling
>devm_kfree() and dmam_free_coherent() means the memory won't be freed until
>the device is detached. If the MSI-X map is repeatedly reconfigured, could
>this exhaust memory?
>[ ... ]
>> +int nbl_res_intr_configure_msix_map(struct nbl_resource_mgt *res_mgt,
>> + u16 func_id, u16 num_net_msix,
>> + u16 num_others_msix,
>> + bool net_msix_mask_en)
>> +{
[ ... ]
>> + msix_map_table = &intr_mgt->func_intr_res[func_id].msix_map_table;
>> + WARN_ON(msix_map_table->base_addr);
>> + msix_map_table->size =
>> + sizeof(struct nbl_msix_map) * NBL_MSIX_MAP_TABLE_MAX_ENTRIES;
>> + /* HW indexes the MSI-X map table with a fixed stride of 1024 entries,
>> + * so we must allocate the full table even if fewer vectors are used.
>> + */
>> + msix_map_table->base_addr = dmam_alloc_coherent(dev,
>> + msix_map_table->size,
>> + &msix_map_table->dma,
>> + GFP_KERNEL);
>> + if (!msix_map_table->base_addr) {
>> + dev_err(dev, "Allocate DMA memory for function msix map table failed\n");
>> + msix_map_table->size = 0;
>> + return -ENOMEM;
>> + }
>> +
>> + interrupts = devm_kcalloc(dev, requested, sizeof(interrupts[0]),
>> + GFP_KERNEL);
>> + if (!interrupts) {
>> + ret = -ENOMEM;
>> + goto alloc_interrupts_err;
>> + }
[ ... ]
>> +get_interrupt_err:
>> + while (i--) {
>> + intr_index = interrupts[i];
>> + if (intr_index >= NBL_NET_INTR_BASE)
>> + clear_bit(intr_index - NBL_NET_INTR_BASE,
>> + intr_mgt->interrupt_net_bitmap);
>> + else
>> + clear_bit(intr_index,
>> + intr_mgt->interrupt_others_bitmap);
>> + }
>> +
>> + intr_mgt->func_intr_res[func_id].num_interrupts = 0;
>> + intr_mgt->func_intr_res[func_id].interrupts = NULL;
>> + intr_mgt->func_intr_res[func_id].num_net_interrupts = 0;
>> +alloc_interrupts_err:
>> +
>> + return ret;
>> +}
>If an error occurs after allocating the memory (e.g., jumping to
>get_interrupt_err or alloc_interrupts_err), does this error path also leak
>the devm_kcalloc() and dmam_alloc_coherent() memory by simply returning
>without freeing it?
Both use devm-managed resources, so I think no manual free is needed.
destroy_msix_map: The interrupts array is allocated with devm_kcalloc(), and
the MSI-X map table is allocated with dmam_alloc_coherent() on the device's
DMA pool. Both are tied to the device lifecycle — they are automatically
reclaimed on driver detach. Setting the pointer to NULL is defensive;
the devm framework handles the actual free.
configure_msix_map error path: Same reasoning. interrupts is devm_kcalloc(),
and the DMA table is device-managed. On any error, the function returns to
the caller, which will eventually trigger driver remove and devm cleanup.
There is no repeated-reconfig loop in the current design — configure_msix_map
is only called during probe/reinit, not in a hot path — so exhaustion is not
a practical concern. Adding manual free calls would duplicate what devm already
does and risk double-free.
^ permalink raw reply
* Re: [PATCH net] net: dsa: Fix skb ownership in taggers
From: David Yang @ 2026-06-16 6:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Fainelli,
Jonas Gorski, Hauke Mehrtens, Kurt Kanzenbach, Woojung Huh,
UNGLinuxDriver, Chester A. Unal, Daniel Golle, Matthias Brugger,
AngeloGioacchino Del Regno, Wei Fang, Clark Wang,
Clément Léger, George McCollister, netdev,
Sashiko AI Review
In-Reply-To: <20260616-dsa-fix-free-skb-v1-1-fd30b35dcf66@kernel.org>
On Tue, Jun 16, 2026 at 6:33 AM Linus Walleij <linusw@kernel.org> wrote:
>
> The tag_8021q.c tagger calls vlan_insert_tag() in dsa_8021q_xmit().
> vlan_insert_tag() will consume the skb with kfree_skb() on failure
> and return NULL.
>
> When NULL is returned as error code to ->xmit() in dsa_user_xmit()
> it will free the same skb again leading to a double-free.
>
> The idea of dsa_user_xmit() and dsa_switch_rcv() dropping the skb
> they held before the call to ->xmit() and ->rcv() is conceptually
> wrong: the pattern elsewhere in the networking code is that consumers
> drop their skb:s on failure.
>
> Modify the ->xmit() and ->rcv() call sites to not drop the SKB if
> the taggers return NULL from any of these calls. Move those drops into
> the taggers so every callback error path that retains ownership consumes
> the skb before returning NULL.
>
> Keep the existing helper ownership rules: VLAN insertion helpers already
> free on failure (this is the case in tag_8021q.c), while deferred
> transmit paths either transfer the skb reference to worker context or
> hold a worker reference with skb_get() and drop the caller's reference.
>
> For SJA1105 meta RX, transfer the buffered stampable skb under the meta
> lock and return NULL while the skb is waiting for its meta frame: the
> skb is not dropped in this case.
>
> Reported-by: Sashiko AI Review <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260610153952.1685895-1-kuba@kernel.org/
> Suggested-by: Jakub Kicinski <kuba@kernel.org>
> Assisted-by: Codex:gpt-5-5
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Better to use goto err, but I'm fine with the current patch. In either case,
Acked-by: David Yang <mmyangfl@gmail.com> # yt921x
> ---
> net/dsa/tag_yt921x.c | 7 ++++++-
^ permalink raw reply
* Re: [PATCH v3 0/3] net: stmmac: L3/L4 filter bug fixes
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-06-16 6:57 UTC (permalink / raw)
To: Maxime Chevallier, netdev@vger.kernel.org
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, rmk+kernel@armlinux.org.uk,
Jose.Abreu@synopsys.com, linux-kernel@vger.kernel.org
In-Reply-To: <fbe4294d-98af-4817-97de-9b20df89a240@bootlin.com>
On 16/6/2026 2:06 pm, Maxime Chevallier wrote:
> Hi Nazim,
>
> On 6/16/26 06:26, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>
>> This series fixes three bugs in the stmmac L3/L4 TC flower filter
>> implementation for the XGMAC2 core. All three patches target net.
>>
>> The L3/L4 filter match count statistics patch (originally patch 4/4)
>> has been split out and will be sent separately against net-next per
>> Andrew Lunn's review of v1.
>>
>> Patch 1 fixes a register corruption bug in the L4 filter port configuration.
>> The XGMAC_L4_ADDR register holds both source and destination port match
>> values in a single register. The original code overwrites the entire register
>> when setting either field, silently erasing the other. This is fixed by
>> using a read-modify-write sequence.
>>
>> Patch 2 fixes the basic flow match parser to properly reject unsupported
>> offload requests with -EOPNOTSUPP instead of silently accepting them.
>> Unsupported cases include partial protocol masks, non-IPv4 network proto,
>> and non-TCP/UDP transport proto. Extack messages are now included so users
>> know exactly which part of the match is unsupported. The -EOPNOTSUPP is
>> also now returned directly instead of using break, which was silently
>> discarding the error on FLOW_CLS_REPLACE operations.
>>
>> Patch 3 fixes a stale action bug on filter deletion. When a filter entry
>> with a drop action is deleted, the action field was not reset, causing
>> it to persist and potentially affect subsequent filter configurations.
>>
>> All three patches fix the original L3/L4 filter implementation introduced in
>> 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower").
>>
>> Changes in v3:
>> - Patch 2: add extack messages to each -EOPNOTSUPP return (Jakub Kicinski)
>> - Patch 2: return -EOPNOTSUPP directly instead of break to avoid silently
>> reporting success on unsupported FLOW_CLS_REPLACE (Sashiko review)
>
> Please take a look at this page prior to reposting :
>
> https://netdev.bots.linux.dev/net-next.html
>
> There's also an announcement made on the netdev@ list when net-next
> opens/closes.
>
> You can't submit new series that target net-next during the merge window,
> this revision will have to wait 2 weeks.
>
> Maxime
>
Ah I see, Thanks Maxime :)
^ permalink raw reply
* Re: [PATCH net-next v3 2/4] udmabuf: emit one sg entry per pinned folio
From: Christian König @ 2026-06-16 7:04 UTC (permalink / raw)
To: Jakub Kicinski, Bobby Eshleman
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, Gerd Hoffmann, Vivek Kasireddy,
Sumit Semwal, Shuah Khan, netdev, linux-kernel, dri-devel,
linux-media, linaro-mm-sig, linux-kselftest, sdf, razor, daniel,
almasrymina, matttbe, skhawaja, dw, Bobby Eshleman
In-Reply-To: <20260615145757.0b2ddcf3@kernel.org>
On 6/15/26 23:57, Jakub Kicinski wrote:
> On Fri, 12 Jun 2026 09:25:58 -0700 Bobby Eshleman wrote:
>> dma_map_sgtable() does not always merge contiguous pages for us, so we
>> do this internally before exporting.
>>
>> Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
>> ---
>> drivers/dma-buf/udmabuf.c
>
> This will need at the very least an ack from DMABUF maintainers,
> so it's a bit late to consider it for 7.2
Sorry for not replying earlier. I already nailed Bobby with questions on the why and what from the DMA-buf side and while I don't have time to in deep review the code the high level rational looks sane to me.
Feel free to add Acked-by: Christian König <christian.koenig@amd.com>
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH net] octeontx2-pf: Fix leak of SQ timestamp buffer on teardown
From: Simon Horman @ 2026-06-16 7:10 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: amakarov, davem, jesse.brandeburg, kuba, linux-kernel, netdev,
richardcochran, andrew+netdev, edumazet, pabeni, sgoutham
In-Reply-To: <20260615030704.504536-1-rkannoth@marvell.com>
On Mon, Jun 15, 2026 at 08:37:04AM +0530, Ratheesh Kannoth wrote:
> The send-queue timestamp ring is allocated with qmem_alloc() when
> timestamping is used, but otx2_free_sq_res() never freed sq->timestamps,
> leaking that memory across ifdown and device removal. Add the missing
> qmem_free() alongside the other SQ companion buffers.
>
> Fixes: c9c12d339d93 ("octeontx2-pf: Add support for PTP clock")
> Cc: Aleksey Makarov <amakarov@marvell.com>
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net] octeontx2-af: npc: Log successful MCAM drop-on-non-hit install at debug level
From: Simon Horman @ 2026-06-16 7:14 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: kuba, linux-kernel, netdev, andrew+netdev, davem, edumazet,
pabeni, sgoutham
In-Reply-To: <20260615033157.535237-1-rkannoth@marvell.com>
On Mon, Jun 15, 2026 at 09:01:57AM +0530, Ratheesh Kannoth wrote:
> npc_install_mcam_drop_rule() used dev_err() after a successful
> rvu_mbox_handler_npc_mcam_write_entry() call, so normal installs appeared
> as errors in dmesg. Use dev_dbg() for the success path and keep dev_err()
> for real failures.
>
> Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM")
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net] net/smc: fix out-of-bounds read in smc_clcsock_data_ready()
From: D. Wythe @ 2026-06-16 7:16 UTC (permalink / raw)
To: Sechang Lim
Cc: D . Wythe, Dust Li, Sidraya Jayagond, Wenjia Zhang, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, David S . Miller, Mahanta Jambigi,
Tony Lu, Wen Gu, Simon Horman, Ursula Braun, Karsten Graul,
Guvenc Gulce, netdev, linux-rdma, linux-s390, bpf, linux-kernel
In-Reply-To: <20260614120931.4041687-1-rhkrqnwk98@gmail.com>
On Sun, Jun 14, 2026 at 12:09:30PM +0000, Sechang Lim wrote:
> smc_clcsock_data_ready() is installed on the listen socket and reads its
> sk_user_data as an smc_sock. A passive-open child inherits this callback,
> but sk_clone_lock() clears the child's sk_user_data because it is tagged
> SK_USER_DATA_NOCOPY. smc_tcp_syn_recv_sock() restores the child's af_ops,
> but the inherited sk_data_ready() is left in place until accept.
>
> In that window the child is established. A cgroup sock_ops program can run
> bpf_sock_hash_update() on it from tcp_init_transfer(); sk_psock_init()
> stores a sk_psock in the NULL sk_user_data. The inherited callback then
> reads sk_user_data via smc_clcsock_user_data(), which masks only
> SK_USER_DATA_NOCOPY, mistakes the sk_psock for an smc_sock, and reads a
> callback pointer past the end of the sk_psock:
>
> BUG: KASAN: slab-out-of-bounds in smc_clcsock_data_ready+0x84/0x200 net/smc/af_smc.c:2637
> Read of size 8 at addr ffff8880013b8674 by task syz.6.12484/67930
> <IRQ>
> smc_clcsock_data_ready+0x84/0x200 net/smc/af_smc.c:2637
> tcp_urg+0x24d/0x360 net/ipv4/tcp_input.c:6264
> tcp_rcv_state_process+0x280d/0x4940 net/ipv4/tcp_input.c:7336
> tcp_child_process+0x371/0xa50 net/ipv4/tcp_minisocks.c:1002
> tcp_v4_rcv+0x1eaa/0x2a00 net/ipv4/tcp_ipv4.c:2186
> ip_protocol_deliver_rcu+0x226/0x420 net/ipv4/ip_input.c:207
> ip_local_deliver_finish+0x35a/0x5f0 net/ipv4/ip_input.c:241
> __netif_receive_skb_one_core+0x1e5/0x210 net/core/dev.c:6216
> process_backlog+0x631/0x1470 net/core/dev.c:6682
> __napi_poll+0xb3/0x320 net/core/dev.c:7749
> net_rx_action+0x4fa/0xcb0 net/core/dev.c:7969
> handle_softirqs+0x236/0x800 kernel/softirq.c:622
> </IRQ>
>
> Allocated by task 67930:
> sk_psock_init+0x142/0x740 net/core/skmsg.c:766
> sock_map_link+0x646/0xdf0 net/core/sock_map.c:279
> sock_hash_update_common+0xd3/0x990 net/core/sock_map.c:1010
> bpf_sock_hash_update+0x114/0x170 net/core/sock_map.c:1229
> __cgroup_bpf_run_filter_sock_ops+0x74/0xa0 kernel/bpf/cgroup.c:1727
> tcp_init_transfer+0x1085/0x1100 net/ipv4/tcp_input.c:6693
> tcp_rcv_state_process+0x241e/0x4940 net/ipv4/tcp_input.c:7231
> tcp_child_process+0x371/0xa50 net/ipv4/tcp_minisocks.c:1002
>
> Restore the inherited sk_data_ready() in smc_tcp_syn_recv_sock(), where the
> child's sk_user_data is already cleared, rather than only at accept.
>
> Fixes: a60a2b1e0af1 ("net/smc: reduce active tcp_listen workers")
> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
> ---
> net/smc/af_smc.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index b5db69073e20..152971e8ad17 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -156,6 +156,12 @@ static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,
> if (child) {
> rcu_assign_sk_user_data(child, NULL);
>
> + /*
> + * the child inherited the listen-specific sk_data_ready();
> + * restore it here, as sk_user_data may be reused before accept
> + */
> + child->sk_data_ready = smc->clcsk_data_ready;
One concern:
smc_clcsock_user_data_rcu() together with refcount_inc_not_zero() only
pins the smc_sock; it does not guarantee anything about the lifetime or
consistency of smc->clcsk_data_ready. In the listen-close path,
smc_clcsock_restore_cb() clears that field under sk_callback_lock,
while smc_tcp_syn_recv_sock() reads it without any lock. These are
independent protection domains. If close wins the race,
child->sk_data_ready can end up NULL and the next data arrival will
crash.
Also, I don't object to this fix, but I'd rather see the underlying cause
addressed directly. The real issue seems to be the conflict between
SMC's sk_user_data and sk_psock. Maybe there is a cleaner solution, e.g.
always setting user_data.
> +
> /* v4-mapped sockets don't inherit parent ops. Don't restore. */
> if (inet_csk(child)->icsk_af_ops == inet_csk(sk)->icsk_af_ops)
> inet_csk(child)->icsk_af_ops = smc->ori_af_ops;
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH] net: ethtool: mm: Increase FPE verification retry count
From: Simon Horman @ 2026-06-16 7:19 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: netdev, andrew, kuba, davem, edumazet, pabeni, vladimir.oltean,
faizal.abdul.rahim, linux-kernel
In-Reply-To: <20260615072436.26128-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
+ Vladimir
On Mon, Jun 15, 2026 at 12:24:36AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> The current FPE verification retry count is set to 3. However,
> the IEEE 802.3br standard does not specify a fixed value for this.
> A retry count of 3 may be insufficient when the remote device is
> slow to respond during link-up. Increase the retry count to 20 to
> improve robustness.
>
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Vladimir, I'm wondering if you could take a look at this one.
> ---
> include/linux/ethtool.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index f51346a6a686..9a1b1f5d37a4 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -23,7 +23,7 @@
> #include <uapi/linux/net_tstamp.h>
>
> #define ETHTOOL_MM_MAX_VERIFY_TIME_MS 128
> -#define ETHTOOL_MM_MAX_VERIFY_RETRIES 3
> +#define ETHTOOL_MM_MAX_VERIFY_RETRIES 20
>
> struct compat_ethtool_rx_flow_spec {
> u32 flow_type;
> --
> 2.43.7
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] appletalk: move the protocol out of tree
From: Carsten Strotmann @ 2026-06-16 7:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: John Paul Adrian Glaubitz, davem, netdev, edumazet, pabeni,
andrew+netdev, horms, geert, chleroy, npiggin, mpe, maddy,
linux-mips, linux-m68k, linuxppc-dev
In-Reply-To: <20260615175535.5bc56cfc@kernel.org>
Hi,
I'm a user of AppleTalk and other "Retro"-Features in the Linux Kernel.
On 16 Jun 2026, at 2:55, Jakub Kicinski wrote:
> We can complain about the AI slop til the cows comes home.
> I don't like it, you don't like it. What difference does it make?
>
> If y'all have real solutions please share. Complaining about
> "commercial interests" and "nuk[ing] everything in a panic reaction"
> is not helpful.
the solution, as Adrian pointed out, is to leave these features in the Linux kernel but have them disabled by default. Maybe put a warning message in the kernel config tools that people should only enable these if they know what they are doing.
These "retro"-features should not pose any security risk of they are not compiled into a kernel.
Greetings
Carsten
^ permalink raw reply
* Re: [PATCH net] sctp: hold socket lock when dumping endpoints in sctp_diag
From: Simon Horman @ 2026-06-16 7:24 UTC (permalink / raw)
To: Xin Long
Cc: netdev, linux-sctp, davem, kuba, edumazet, pabeni,
marcelo.leitner, w, zdi-disclosures
In-Reply-To: <CADvbK_e062WLNVy+BbuNTNoJGBvQBR7PHp_BmxLwwSGq4O9_dw@mail.gmail.com>
On Mon, Jun 15, 2026 at 02:24:34PM -0400, Xin Long wrote:
> On Mon, Jun 15, 2026 at 7:04 AM Simon Horman <horms@kernel.org> wrote:
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > Full review at: https://netdev-ai.bots.linux.dev/sashiko/
...
> Low: #1, #2, #5, not really issues,
> but worth mentioning about it in changelog.
>
> Critical: #3, not valid.
> socket refcnt can't be 0 when traversing the chain under read_lock_bh().
>
> But it seems better to hold ep instead sk, and also to check
> ep->base.dead instead of sk_state CLOSED.
>
> Medium: #4, not valid.
> it's completely okay to dump duplicate or skip socks because of
> concurrent close() and listen() in diag.
>
> will post v2 with some improvements mentioned above.
Thanks, much appreciated.
^ permalink raw reply
* RE: [PATCH net v3] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
From: Tung Quang Nguyen @ 2026-06-16 7:24 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, aleksander.lobakin@intel.com,
tipc-discussion@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
jmaloy@redhat.com
In-Reply-To: <20260615114618.71249-1-doruk@0sec.ai>
>Subject: [PATCH net v3] tipc: fix slab-use-after-free Read in
>tipc_aead_decrypt_done
>
>tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to
>crypto_aead_decrypt(req) without taking a reference on the netns, unlike the
>encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g.
>the SIMD aead wrapper queuing to cryptd), the cryptd worker runs
>tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the
>meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-
>netns tipc_crypto, and the completion then reads it:
>tipc_aead_decrypt_done() dereferences aead->crypto->stats and
>aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead[]
>aead->crypto->and the node table -- reading freed memory.
>
>Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC +
>TIPC_CRYPTO):
>
> BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done
>(net/tipc/crypto.c:999)
> Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51
> Workqueue: events_unbound
> Call Trace:
> tipc_aead_decrypt_done (net/tipc/crypto.c:999)
> process_one_work (kernel/workqueue.c:3314)
> worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
> kthread (kernel/kthread.c:436)
> ret_from_fork (arch/x86/kernel/process.c:158)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
>
> Allocated by task 169:
> __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
> tipc_crypto_start (net/tipc/crypto.c:1502)
> tipc_init_net (net/tipc/core.c:72)
> ops_init (net/core/net_namespace.c:137)
> setup_net (net/core/net_namespace.c:446)
> copy_net_ns (net/core/net_namespace.c:579)
> create_new_namespaces (kernel/nsproxy.c:132)
> __x64_sys_unshare (kernel/fork.c:3316)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>
> Freed by task 8:
> kfree (mm/slub.c:6566)
> tipc_exit_net (net/tipc/core.c:119)
> cleanup_net (net/core/net_namespace.c:704)
> process_one_work (kernel/workqueue.c:3314)
> kthread (kernel/kthread.c:436)
>
>This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-
>use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt side.
>The encrypt path takes maybe_get_net(aead->crypto->net) before
>crypto_aead_encrypt() and drops it with put_net() on the synchronous return
>paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return
>keeps the reference for the async callback to release. The decrypt path was left
>without the equivalent guard.
>
>Mirror the encrypt-side fix on the decrypt path: take a net reference before
>crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it
>cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return,
>and drop it with put_net() on the synchronous success/error return and at the
>end of tipc_aead_decrypt_done().
>
>Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is
>flooded with crafted encrypted frames from an unknown peer (driving the
>cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The
>completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the
>stock aesni gcm(aes) now decrypts synchronously, so the async path was
>exercised via cryptd offload. The unguarded aead->crypto dereference in
>tipc_aead_decrypt_done() is the unpatched upstream path;
>tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the
>completion can outlive the free on any config where crypto_aead_decrypt()
>goes async.
>
>Found by 0sec automated security-research tooling (https://0sec.ai).
>
>Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
>Cc: stable@vger.kernel.org
>Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
>Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
>---
>v3:
> - Rewrite the changelog with the decoded stack trace and frame the
> reproduction on the current tree (v7.1-rc7); drop the v6.12.92
> references (Tung Quang Nguyen).
>v2:
> - Add Cc: stable@vger.kernel.org and Alexander Lobakin's Reviewed-by.
> No functional change.
> net/tipc/crypto.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
>diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c index
>6d3b6b89b1d1..84a6489da036 100644
>--- a/net/tipc/crypto.c
>+++ b/net/tipc/crypto.c
>@@ -941,12 +941,20 @@ static int tipc_aead_decrypt(struct net *net, struct
>tipc_aead *aead,
> goto exit;
> }
>
>+ /* Get net to avoid freed tipc_crypto when delete namespace */
>+ if (!maybe_get_net(aead->crypto->net)) {
>+ tipc_bearer_put(b);
>+ rc = -ENODEV;
>+ goto exit;
>+ }
>+
> /* Now, do decrypt */
> rc = crypto_aead_decrypt(req);
> if (rc == -EINPROGRESS || rc == -EBUSY)
> return rc;
>
> tipc_bearer_put(b);
>+ put_net(aead->crypto->net);
>
> exit:
> kfree(ctx);
>@@ -984,6 +992,7 @@ static void tipc_aead_decrypt_done(void *data, int err)
> }
>
> tipc_bearer_put(b);
>+ put_net(net);
> }
>
> static inline int tipc_ehdr_size(struct tipc_ehdr *ehdr)
>--
>2.43.0
>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
^ permalink raw reply
* [PATCH] net: mvneta: free/request IRQ across suspend/resume
From: Yun Zhou @ 2026-06-16 7:26 UTC (permalink / raw)
To: marcin.s.wojtas, andrew+netdev, davem, edumazet, kuba, pabeni,
bigeasy, clrkwllms, rostedt
Cc: netdev, linux-kernel, linux-rt-devel, yun.zhou
On PREEMPT_RT, the mvneta IRQ handler is force-threaded. Under high
network traffic, the IRQ can enter suspend with desc->depth == 1
(masked by the oneshot mechanism between handler invocations).
During suspend, the kernel increments depth to 2 and masks the
interrupt at the MPIC level (clearing the SRC_CTL CPU routing bit,
due to IRQCHIP_MASK_ON_SUSPEND). On resume, depth is decremented
back to 1, but since it does not reach 0, the unmask is never
called. The MPIC CPU routing remains cleared, permanently disabling
interrupt delivery.
Fix by freeing the IRQ in suspend and re-requesting it in resume.
This ensures a clean IRQ state (depth=0, proper hardware routing)
on every resume cycle, regardless of the pre-suspend depth. This
follows the approach used by other drivers (e.g. igb).
Fixes: 9768b45ceb0b ("net: mvneta: support suspend and resume")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
---
drivers/net/ethernet/marvell/mvneta.c | 28 +++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 0c061fb0ed07..e7e9a58dbe55 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -5819,6 +5819,20 @@ static int mvneta_suspend(struct device *device)
mvneta_stop_dev(pp);
rtnl_unlock();
+ /* Release IRQ to avoid stale MPIC mask state on resume.
+ * On PREEMPT_RT, forced-threaded oneshot IRQs may leave the
+ * interrupt masked (depth>0) at suspend time. This prevents
+ * resume_device_irqs() from restoring the MPIC CPU routing,
+ * permanently disabling the interrupt. Re-requesting the IRQ
+ * on resume guarantees a clean state.
+ */
+ if (pp->neta_armada3700)
+ free_irq(dev->irq, pp);
+ else {
+ on_each_cpu(mvneta_percpu_disable, pp, true);
+ free_percpu_irq(dev->irq, pp->ports);
+ }
+
for (queue = 0; queue < rxq_number; queue++) {
struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
@@ -5895,6 +5909,20 @@ static int mvneta_resume(struct device *device)
&pp->node_dead);
}
+ /* Re-request IRQ (see comment in mvneta_suspend) */
+ if (pp->neta_armada3700) {
+ err = request_irq(dev->irq, mvneta_isr, 0, dev->name, pp);
+ } else {
+ err = request_percpu_irq(dev->irq, mvneta_percpu_isr,
+ dev->name, pp->ports);
+ if (!err)
+ on_each_cpu(mvneta_percpu_enable, pp, true);
+ }
+ if (err) {
+ netdev_err(dev, "cannot request irq %d\n", dev->irq);
+ return err;
+ }
+
rtnl_lock();
mvneta_start_dev(pp);
rtnl_unlock();
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/5] mm: Make per-VMA locks available universally
From: Alice Ryhl @ 2026-06-16 7:32 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Andrew Morton, Arve Hjønnevåg,
Carlos Llamas, Christian Brauner, David Ahern, David S. Miller,
Greg Kroah-Hartman, Liam R. Howlett, linux-mm, Lorenzo Stoakes,
netdev, Shakeel Butt, Suren Baghdasaryan, Todd Kjos,
Vlastimil Babka
In-Reply-To: <20260610230411.617DD5E7@davehans-spike.ostc.intel.com>
On Wed, Jun 10, 2026 at 04:04:11PM -0700, Dave Hansen wrote:
> --- a/rust/kernel/mm.rs~unconditional-vma-locks 2026-06-10 15:57:54.051368539 -0700
> +++ b/rust/kernel/mm.rs 2026-06-10 15:57:54.078369499 -0700
> @@ -174,7 +174,6 @@ impl MmWithUser {
> /// When per-vma locks are disabled, this always returns `None`.
> #[inline]
> pub fn lock_vma_under_rcu(&self, vma_addr: usize) -> Option<VmaReadGuard<'_>> {
> - #[cfg(CONFIG_PER_VMA_LOCK)]
> {
> // SAFETY: Calling `bindings::lock_vma_under_rcu` is always okay given an mm where
> // `mm_users` is non-zero.
> @@ -188,12 +187,6 @@ impl MmWithUser {
> });
> }
> }
> -
> - // Silence warnings about unused variables.
> - #[cfg(not(CONFIG_PER_VMA_LOCK))]
> - let _ = vma_addr;
> -
> - None
This isn't quite right:
error[E0317]: `if` may be missing an `else` clause
--> rust/kernel/mm.rs:181:13
|
181 | / if !vma.is_null() {
182 | | return Some(VmaReadGuard {
... |
187 | | });
188 | | }
| |_____________^ expected `Option<VmaReadGuard<'_>>`, found `()`
|
= note: expected enum `core::option::Option<mm::VmaReadGuard<'_>>`
found unit type `()`
= note: `if` expressions without `else` evaluate to `()`
= help: consider adding an `else` block that evaluates to the expected type
This error is triggered because you deleted the return 'None' at the end
of the function.
I would like to suggest the following implementation
// SAFETY: Calling `bindings::lock_vma_under_rcu` is always okay given an mm where
// `mm_users` is non-zero.
let vma = unsafe { bindings::lock_vma_under_rcu(self.as_raw(), vma_addr) };
if vma.is_null() {
return None;
}
Some(VmaReadGuard {
// SAFETY: If `lock_vma_under_rcu` returns a non-null ptr, then it points at a valid
// vma. The vma is stable for as long as the vma read lock is held.
vma: unsafe { VmaRef::from_raw(vma) },
_nts: NotThreadSafe,
})
Thanks!
Alice
^ permalink raw reply
* net: thunderbolt: tbnet_poll() can overflow skb_shinfo()->frags[]
From: Maoyi Xie @ 2026-06-16 7:34 UTC (permalink / raw)
To: Mika Westerberg, Yehezkel Bernat
Cc: Andrew Lunn, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Hi all,
After the recent skb frags[] overflow fixes (t7xx, cdc-phonet, f_phonet), I
went looking for the same pattern. I think tbnet_poll() in
drivers/net/thunderbolt/main.c has it too. I would appreciate it if you could
take a look.
tbnet_poll() reassembles a ThunderboltIP packet that spans several frames into
one skb. It adds one rx fragment per frame.
skb = net->skb;
if (!skb) {
skb = build_skb(...);
...
net->skb = skb;
} else {
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
page, hdr_size, frame_size,
TBNET_RX_PAGE_SIZE - hdr_size);
}
Nothing checks skb_shinfo(skb)->nr_frags against MAX_SKB_FRAGS here. The frame
count comes from the peer, in the frame header. tbnet_check_frame() only bounds
it at the start of a packet.
if (frame_count == 0 || frame_count > TBNET_RING_SIZE / 4) {
net->stats.rx_length_errors++;
return false;
}
TBNET_RING_SIZE is 256, so frame_count can be as large as 64. MAX_SKB_FRAGS is 17
by default. Frame 0 builds the skb and every frame after it adds a fragment, so
nr_frags can reach 63. Once nr_frags hits MAX_SKB_FRAGS, skb_add_rx_frag() writes
one entry past skb_shinfo()->frags[]. The frame_size and MTU checks do not stop
this. With small frames, 64 fragments stay well under TBNET_MAX_MTU.
So a malicious or buggy peer can send a packet with frame_count between 19 and
64. The frames only need to increment the way tbnet_check_frame() wants. That
drives nr_frags past frags[] and overruns skb_shared_info.
The fix I had in mind mirrors f0813bcd2d9d ("net: wwan: t7xx: fix potential
skb->frags overflow in RX path") and 600dc40554dc ("net: usb: cdc-phonet: fix
skb frags[] overflow in rx_complete()"). Add the fragment only while there is
room, and drop the packet otherwise.
- } else {
+ } else if (skb_shinfo(skb)->nr_frags < MAX_SKB_FRAGS) {
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
page, hdr_size, frame_size,
TBNET_RX_PAGE_SIZE - hdr_size);
+ } else {
+ net->stats.rx_length_errors++;
+ __free_pages(page, TBNET_RX_PAGE_ORDER);
+ dev_kfree_skb_any(net->skb);
+ net->skb = NULL;
+ continue;
}
I do not have two Thunderbolt hosts, so this is from reading the code. I can put
together a focused reproducer if that helps.
Does this look like a real overflow? And is the MAX_SKB_FRAGS guard the right
place, or would you rather tighten the frame_count bound in tbnet_check_frame()?
It has been there since the driver was added (e69b6c02b4c3), so it is a stable
candidate. Happy to send a proper patch once you confirm.
Thanks,
Maoyi
https://maoyixie.com/
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: David Hildenbrand (Arm) @ 2026-06-16 7:38 UTC (permalink / raw)
To: Joanne Koong, Askar Safin
Cc: akpm, axboe, bernd, brauner, dhowells, fuse-devel, hch, jack,
linux-api, linux-fsdevel, linux-kernel, linux-mm, miklos, netdev,
patches, pfalcato, rostedt, torvalds, val, viro, willy
In-Reply-To: <CAJnrk1Z_V8TShvWV6zwTMQqXra3J4J5CL5ofFMm9DGoLj9whEw@mail.gmail.com>
On 6/16/26 08:38, Joanne Koong wrote:
> On Mon, Jun 15, 2026 at 9:15 PM Askar Safin <safinaskar@gmail.com> wrote:
>>
>> Joanne Koong <joannelkoong@gmail.com>:
>>>
>>> I think this is because of how libfuse handles eof / short reads. When
>>> it detects a short read, it fixes up the header length after the
>>> header was already vmspliced to the pipe because it assumes vmsplice
>>> mapped the header's page into the pipe by reference. It assumes that
>>> modifying the header length in place gets then reflected in what the
>>> pipe later splices out.
>>>
>>> The logic for this happens in fuse_send_data_iov() [1]:
>>> a) sets out->len = headerlen (16) + len (16384) = 16400 in the
>>> stack-allocated fuse_out_header
>>> b) vmsplices the header to the pipe
>>> c) splices the backing file to the pipe. if this hits EOF, it'll get
>>> back 15510 instead of 16384
>>> d) detects the short read [2], fixes up the stack out->len = 16 + 15510 = 15526
>>> e) splices the pipe to /dev/fuse
>>>
>>> After this patch, step b) is a straight copy which means step d)'s
>>> fixup doesn't modify what's in the pipe. This could be fixed up in
>>> libfuse to not depend on modify-after-vmsplice, but I don't think this
>>> helps for applications using already-released libfuse versions. I
>>> think this patch needs to be reverted.
>>>
>>> Thanks,
>>> Joanne
>>>
>>> [1] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L846
>>> [2] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L956
>>
>> Uh, this is very unfortunate. But I still want to remove vmsplice.
>> Maybe we can somehow save my patchsets? For example, let's return EINVAL
>> for this particular combination (writable pipe + SPLICE_F_NONBLOCK).
>
> writable pipe + SPLICE_F_NONBLOCK is a valid vmsplice call today, so I
> think returning -EINVAL would still cause regressions.
I recall that, after the vmsplice vs. fork security issue happened, vmsplice was
blocked in some container runtimes. e.g., [1] still seems to disable it, added
in 2021 [2].
So maybe one could at least assume that many containerized workloads should be
able to deal with vmsplice not being available nowadays. But in the general case
I'm afraid Joanne is right.
[1] https://github.com/containers/common/blob/main/pkg/seccomp/seccomp.json
[2]
https://github.com/containers/common/commit/7ced5daafa0e36102eb931050ba3ff99f42bdfac
--
Cheers,
David
^ permalink raw reply
* RE: [PATCH net] tipc: free bearer discoverer via RCU to fix tipc_disc_rcv UAF
From: Tung Quang Nguyen @ 2026-06-16 7:50 UTC (permalink / raw)
To: Samuel Page
Cc: 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, stable@vger.kernel.org, Jon Maloy
In-Reply-To: <20260615150009.1734270-1-sam@bynar.io>
>Subject: [PATCH net] tipc: free bearer discoverer via RCU to fix tipc_disc_rcv
>UAF
>
>bearer_disable() tears down a bearer's discovery object with
>tipc_disc_delete(), which frees the struct tipc_discoverer with a plain,
>synchronous kfree(). The discovery receive path, however, still reads that
>object under RCU in softirq context:
>
> tipc_udp_recv() // udp_media.c, rcu_dereference(ub->bearer)
> -> tipc_rcv() // node.c
> -> tipc_disc_rcv() // discover.c
> -> tipc_disc_addr_trial_msg(b->disc, ...) // reads d->net etc.
>
>tipc_udp_recv() only gates this path on test_bit(0, &b->up), which is a TOCTOU
>check: an RX softirq that observes b->up == 1 before
>bearer_disable() does clear_bit_unlock(0, &b->up) can still be executing inside
>tipc_disc_rcv() when bearer_disable() reaches
>
> if (b->disc)
> tipc_disc_delete(b->disc);
>
>and kfree()s the discoverer. The reader then dereferences freed memory (d-
>>net, inlined into tipc_disc_rcv()) in softirq context [0].
>
>The bearer itself is freed RCU-safely (tipc_bearer_put() -> kfree_rcu(b, rcu))
>because the RX path runs under RCU, but the discoverer hanging off b->disc is
>freed synchronously. The same b->disc is also touched under rcu_read_lock()
>by tipc_disc_add_dest()/tipc_disc_remove_dest().
>
>Free the discoverer with the same RCU lifetime as its bearer. Add an rcu_head
>to struct tipc_discoverer and defer the kfree_skb()/kfree() to an RCU callback
>so any in-flight reader that already loaded b->disc completes before the
>memory is released. The timer is still shut down synchronously up front with
>timer_shutdown_sync() (which can sleep and must not run from the RCU
>callback), and shutting it down before the grace period prevents the periodic
>LINK_REQUEST timer from rearming or re-entering the object.
>
>This mirrors the existing TIPC pattern of pairing call_rcu() with a cleanup
>callback (see tipc_node_free()/tipc_aead_free()).
>
>[0]: (trailing page/memory-state dump trimmed)
>BUG: KASAN: slab-use-after-free in tipc_disc_addr_trial_msg
>net/tipc/discover.c:149 [inline]
>BUG: KASAN: slab-use-after-free in tipc_disc_rcv+0xe7c/0x103c
>net/tipc/discover.c:236 Read of size 8 at addr ffff000028f07428 by task
>ksoftirqd/0/15
>
>CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.11 #3 PREEMPT
>Hardware name: linux,dummy-virt (DT) Call trace:
> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C) __dump_stack
>lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120 print_address_description
>mm/kasan/report.c:378 [inline]
> print_report+0x118/0x5d8 mm/kasan/report.c:482
> kasan_report+0xb0/0xf4 mm/kasan/report.c:595
>__asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
>tipc_disc_addr_trial_msg net/tipc/discover.c:149 [inline]
>tipc_disc_rcv+0xe7c/0x103c net/tipc/discover.c:236 tipc_rcv+0x1884/0x2b1c
>net/tipc/node.c:2126
> tipc_udp_recv+0x22c/0x684 net/tipc/udp_media.c:393
> udp_queue_rcv_one_skb+0x898/0x1798 net/ipv4/udp.c:2441
> udp_queue_rcv_skb+0x1b0/0xa44 net/ipv4/udp.c:2518
> udp_unicast_rcv_skb+0x13c/0x348 net/ipv4/udp.c:2678
>__udp4_lib_rcv+0x1aec/0x246c net/ipv4/udp.c:2754
> udp_rcv+0x78/0xa0 net/ipv4/udp.c:2936
> ip_protocol_deliver_rcu+0x68/0x410 net/ipv4/ip_input.c:207
> ip_local_deliver_finish+0x28c/0x4b4 net/ipv4/ip_input.c:241 NF_HOOK
>include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312
>[inline] ip_local_deliver+0x29c/0x2ec net/ipv4/ip_input.c:262 dst_input
>include/net/dst.h:480 [inline] ip_rcv_finish net/ipv4/ip_input.c:453 [inline]
>ip_rcv_finish net/ipv4/ip_input.c:439 [inline] NF_HOOK
>include/linux/netfilter.h:318 [inline] NF_HOOK include/linux/netfilter.h:312
>[inline]
> ip_rcv+0x21c/0x258 net/ipv4/ip_input.c:573
> __netif_receive_skb_one_core+0x110/0x184 net/core/dev.c:6195
> __netif_receive_skb+0x2c/0x170 net/core/dev.c:6308
> process_backlog+0x178/0x488 net/core/dev.c:6659
> __napi_poll+0xa8/0x540 net/core/dev.c:7726 napi_poll net/core/dev.c:7789
>[inline]
> net_rx_action+0x360/0x964 net/core/dev.c:7946
> handle_softirqs+0x2f0/0x7b0 kernel/softirq.c:622 run_ksoftirqd
>kernel/softirq.c:1063 [inline]
> run_ksoftirqd+0x6c/0x88 kernel/softirq.c:1055
> smpboot_thread_fn+0x65c/0x958 kernel/smpboot.c:160
> kthread+0x39c/0x444 kernel/kthread.c:436
> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
>
>Allocated by task 68873:
> kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57
>kasan_save_track+0x20/0x3c mm/kasan/common.c:78
> kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570
>poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
> __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415 kasan_kmalloc
>include/linux/kasan.h:263 [inline]
> __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385 kmalloc_noprof
>include/linux/slab.h:950 [inline]
> tipc_disc_create+0xdc/0x5e0 net/tipc/discover.c:356
> tipc_enable_bearer+0x8b8/0xf94 net/tipc/bearer.c:348
> __tipc_nl_bearer_enable+0x2a8/0x398 net/tipc/bearer.c:1047
> tipc_nl_bearer_enable+0x2c/0x48 net/tipc/bearer.c:1056
> genl_family_rcv_msg_doit+0x1e4/0x2c0 net/netlink/genetlink.c:1114
>genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
> genl_rcv_msg+0x4e8/0x750 net/netlink/genetlink.c:1209
>netlink_rcv_skb+0x204/0x3cc net/netlink/af_netlink.c:2550
> genl_rcv+0x3c/0x54 net/netlink/genetlink.c:1218 netlink_unicast_kernel
>net/netlink/af_netlink.c:1318 [inline]
> netlink_unicast+0x638/0x930 net/netlink/af_netlink.c:1344
> netlink_sendmsg+0x798/0xc68 net/netlink/af_netlink.c:1894
>sock_sendmsg_nosec net/socket.c:727 [inline]
> __sock_sendmsg+0xe0/0x128 net/socket.c:742
> __sys_sendto+0x230/0x2f4 net/socket.c:2206 __do_sys_sendto
>net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline]
>__arm64_sys_sendto+0xc4/0x13c net/socket.c:2209 __invoke_syscall
>arch/arm64/kernel/syscall.c:35 [inline]
> invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49
> el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132
>do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0xac
>arch/arm64/kernel/entry-common.c:724
> el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743
> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596
>
>Freed by task 60072:
> kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57
>kasan_save_track+0x20/0x3c mm/kasan/common.c:78
> kasan_save_free_info+0x4c/0x74 mm/kasan/generic.c:584
>poison_slab_object mm/kasan/common.c:253 [inline]
> __kasan_slab_free+0x88/0xb8 mm/kasan/common.c:285 kasan_slab_free
>include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline]
>slab_free mm/slub.c:6170 [inline]
> kfree+0x14c/0x458 mm/slub.c:6488
> tipc_disc_delete+0x50/0x68 net/tipc/discover.c:393
> bearer_disable+0x18c/0x278 net/tipc/bearer.c:418
> tipc_bearer_stop+0xe0/0x198 net/tipc/bearer.c:757
> tipc_net_stop+0x110/0x178 net/tipc/net.c:159 tipc_exit_net+0x80/0x19c
>net/tipc/core.c:112 ops_exit_list net/core/net_namespace.c:199 [inline]
> ops_undo_list+0x244/0x694 net/core/net_namespace.c:252
> cleanup_net+0x3a0/0x830 net/core/net_namespace.c:702
> process_one_work+0x628/0xd38 kernel/workqueue.c:3289
>process_scheduled_works kernel/workqueue.c:3372 [inline]
> worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453
> kthread+0x39c/0x444 kernel/kthread.c:436
> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
>
>Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash
>values")
>Cc: stable@vger.kernel.org
>Assisted-by: Bynario AI
>Signed-off-by: Samuel Page <sam@bynar.io>
>---
> net/tipc/discover.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
>diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
>3e54d2df5683..844975b691ef 100644
>--- a/net/tipc/discover.c
>+++ b/net/tipc/discover.c
>@@ -49,6 +49,7 @@
>
> /**
> * struct tipc_discoverer - information about an ongoing link setup request
>+ * @rcu: RCU head used to free the structure after a grace period
> * @bearer_id: identity of bearer issuing requests
> * @net: network namespace instance
> * @dest: destination address for request messages @@ -60,6 +61,7 @@
> * @timer_intv: current interval between requests (in ms)
> */
> struct tipc_discoverer {
>+ struct rcu_head rcu;
> u32 bearer_id;
> struct tipc_media_addr dest;
> struct net *net;
>@@ -382,6 +384,17 @@ int tipc_disc_create(struct net *net, struct tipc_bearer
>*b,
> return 0;
> }
>
>+/* RCU callback: free the discoverer only after any concurrent
>+ * tipc_disc_rcv() softirq reader of bearer->disc has finished.
>+ */
>+static void tipc_disc_free_rcu(struct rcu_head *rp) {
>+ struct tipc_discoverer *d = container_of(rp, struct tipc_discoverer,
>+rcu);
A similar patch was submitted 6 days ago: https://patchwork.kernel.org/project/netdevbpf/patch/20260610153349.2546041-2-bestswngs@gmail.com/
I do not receive updated patch from the submitter yet.
Your patch has the same coding style issue (long line, over 80 columns), see linux/Documentation/process/coding-style.rst
If you break the long line into 2 lines and submit again, I think I can acknowledge your patch.
>+
>+ kfree_skb(d->skb);
>+ kfree(d);
>+}
>+
> /**
> * tipc_disc_delete - destroy object sending periodic link setup requests
> * @d: ptr to link dest structure
>@@ -389,8 +402,7 @@ int tipc_disc_create(struct net *net, struct tipc_bearer
>*b, void tipc_disc_delete(struct tipc_discoverer *d) {
> timer_shutdown_sync(&d->timer);
>- kfree_skb(d->skb);
>- kfree(d);
>+ call_rcu(&d->rcu, tipc_disc_free_rcu);
> }
>
> /**
>
>base-commit: 47186409c092cd7dd70350999186c700233e854d
>--
>2.54.0
>
^ permalink raw reply
* Re: [PATCH] swiotlb: avoid double copy with swiotlb on tx socket
From: kernel test robot @ 2026-06-16 8:01 UTC (permalink / raw)
To: Luigi Rizzo, rizzo.unipi, m.szyprowski, robin.murphy, willemb,
kuniyu, davem, edumazet, kuba, pabeni
Cc: llvm, oe-kbuild-all, gregkh, rafael, akpm, david, netdev,
linux-mm, iommu, driver-core, linux-kernel
In-Reply-To: <20260615234220.3946885-1-lrizzo@google.com>
Hi Luigi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on linus/master v7.1 next-20260615]
[cannot apply to driver-core/driver-core-testing driver-core/driver-core-next driver-core/driver-core-linus]
[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/Luigi-Rizzo/swiotlb-avoid-double-copy-with-swiotlb-on-tx-socket/20260616-074655
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20260615234220.3946885-1-lrizzo%40google.com
patch subject: [PATCH] swiotlb: avoid double copy with swiotlb on tx socket
config: loongarch-allnoconfig (https://download.01.org/0day-ci/archive/20260616/202606161519.z7SY98jp-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260616/202606161519.z7SY98jp-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/202606161519.z7SY98jp-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> mm/page_alloc.c:721:17: warning: unused variable 'folio' [-Wunused-variable]
721 | struct folio *folio = (struct folio *)page;
| ^~~~~
1 warning generated.
--
>> Warning: kernel/dma/swiotlb.c:95 cannot understand function prototype: 'atomic_t global_device_serial = ATOMIC_INIT(0);'
>> Warning: kernel/dma/swiotlb.c:2087 function parameter 'where_debug_only' not described in 'swiotlb_free_pages'
>> Warning: kernel/dma/swiotlb.c:2087 function parameter 'where_debug_only' not described in 'swiotlb_free_pages'
vim +/folio +721 mm/page_alloc.c
717
718 void swiotlb_destroy_compound_page(struct page *page, unsigned int order)
719 {
720 if (order > 0) {
> 721 struct folio *folio = (struct folio *)page;
722
723 __ClearPageHead(page);
724 page[1].flags.f &= ~PAGE_FLAGS_SECOND;
725 #ifdef NR_PAGES_IN_LARGE_FOLIO
726 folio->_nr_pages = 0;
727 #endif
728 for (int i = 1; i < (1 << order); i++) {
729 page[i].mapping = NULL;
730 clear_compound_head(&page[i]);
731 }
732 }
733 }
734 #endif /* CONFIG_SWIOTLB */
735
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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