* [PATCH net 1/9] netfilter: xt_nat: reject unsupported target families
From: Florian Westphal @ 2026-07-10 14:37 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260710143733.29741-1-fw@strlen.de>
From: Wyatt Feng <bronzed_45_vested@icloud.com>
xt_nat SNAT and DNAT target handlers assume IP-family conntrack state
is present and can dereference a NULL pointer when instantiated from an
unsupported family through nft_compat. A bridge-family compat rule can
therefore trigger a NULL-dereference in nf_nat_setup_info().
Reject non-IP families in xt_nat_checkentry() so unsupported targets
cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT
compat users and leave the runtime fast path unchanged.
[ The crash was fixed via
9dbba7e694ec ("netfilter: nft_compat: ebtables emulation must reject non-bridge targets"),
so this patch is no longer critical.
Nevertheless, NAT is only relevant for ipv4/ipv6, so this extra
family check is a good idea in any case. ]
Fixes: c7232c9979cb ("netfilter: add protocol independent NAT core")
Cc: stable@vger.kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_nat.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/netfilter/xt_nat.c b/net/netfilter/xt_nat.c
index b4f7bbc3f3ca..51c7f7ce88d9 100644
--- a/net/netfilter/xt_nat.c
+++ b/net/netfilter/xt_nat.c
@@ -26,6 +26,15 @@ static int xt_nat_checkentry_v0(const struct xt_tgchk_param *par)
static int xt_nat_checkentry(const struct xt_tgchk_param *par)
{
+ switch (par->family) {
+ case NFPROTO_IPV4:
+ case NFPROTO_IPV6:
+ case NFPROTO_INET:
+ break;
+ default:
+ return -EINVAL;
+ }
+
return nf_ct_netns_get(par->net, par->family);
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 2/9] netfilter: ecache: fix inverted time_after() check
From: Florian Westphal @ 2026-07-10 14:37 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260710143733.29741-1-fw@strlen.de>
From: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
ecache_work_evict_list() redelivers DESTROY events for conntracks that
were moved to the per-netns dying_list after event delivery failed. It
sets a 10ms deadline:
stop = jiffies + ECACHE_MAX_JIFFIES
but then tests:
time_after(stop, jiffies)
This condition is true while the deadline is still in the future, so the
worker returns STATE_RESTART after the first successful redelivery in the
usual case. ecache_work() maps STATE_RESTART to delay 0, which turns the
redelivery path into one dying conntrack per workqueue dispatch and makes
the sent > 16 batching/cond_resched() path effectively unreachable.
A conntrack netlink listener whose receive queue is congested can make
DESTROY event delivery fail with -ENOBUFS. With sustained conntrack
churn, entries then accumulate on the dying_list and are only drained at
the degraded one-entry-per-dispatch rate once delivery succeeds again,
wasting CPU on back-to-back workqueue reschedules and prolonging
conntrack memory/resource pressure.
In a KASAN QEMU test with CONFIG_NF_CONNTRACK_EVENTS=y and
nf_conntrack.enable_hooks=1, a congested DESTROY listener caused 8192
nf_ct_delete() calls to return false and move entries to the dying_list.
After closing the listener, the unfixed kernel needed 7670 ecache_work()
entries to destroy 7669 conntracks. With this change, the same 8192
entries were destroyed by 2 ecache_work() entries.
Swap the comparison so the worker restarts only after the deadline has
expired.
Fixes: 2ed3bf188b33 ("netfilter: ecache: use dedicated list for event redelivery")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nf_conntrack_ecache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_ecache.c b/net/netfilter/nf_conntrack_ecache.c
index 9df159448b89..cc8d8e85169f 100644
--- a/net/netfilter/nf_conntrack_ecache.c
+++ b/net/netfilter/nf_conntrack_ecache.c
@@ -77,7 +77,7 @@ static enum retry_state ecache_work_evict_list(struct nf_conntrack_net *cnet)
hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
hlist_nulls_add_head(&ct->tuplehash[IP_CT_DIR_REPLY].hnnode, &evicted_list);
- if (time_after(stop, jiffies)) {
+ if (time_after(jiffies, stop)) {
ret = STATE_RESTART;
break;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 0/9] netfilter: updates for net
From: Florian Westphal @ 2026-07-10 14:37 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
Hi,
The following patchset contains Netfilter fixes for *net*.
These are fixes for bugs except patches 6 and 9 which fix issues added in
last PR and 7.1-rc1.
1) Reject unsupported target families in xt_nat_checkentry().
From Wyatt Feng.
2) Fix inverted time_after() check in ecache_work_evict_list().
Causes pointless work rescheds and thus way longer time to
clear the pending event backlog. From Yizhou Zhao.
3) Fix a use-after-free in br_ip6_fragment() caused by a dangling prevhdr
pointer. From Xiang Mei.
4) Fix incorrect conntrack zone comparison in nf_conncount tuple
deduplication. Pass IP_CT_DIR_ORIGINAL, not zone direction.
From Yizhou Zhao.
5) Add bridge tunnel flowtable regression test for a bug that
got fixed in the previous PR. From Zhengyang Chen.
6) Use the correct direction when setting up tunnel routes in the flowtable
xmit path. From Pablo Neira Ayuso. This fixes a bug added in the
previous PR.
7) Reload IP header after potential skb head reallocation in IPVS.
8) Fix incorrect IPv6 transport offsets in TCP application code. Correct the
ICMPv6 header offset to ensure proper checksumming with extension headers,
from Julian Anastasov. this is a followup to the previous PR.
9) Remove null-termination requirement for xt_physdev masks, this broke
device names with 15 characters.
Please, pull these changes from:
The following changes since commit 4fa349156043dc119721d067329714179f501749:
net/iucv: take a reference on the socket found in afiucv_hs_rcv() (2026-07-10 16:24:43 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-26-07-10
for you to fetch changes up to f468c48d488d0ea2df3422b3e1dfafae1611e853:
netfilter: xt_physdev: masks are not c-strings (2026-07-10 16:28:47 +0200)
----------------------------------------------------------------
netfilter pull request nf-26-07-10
----------------------------------------------------------------
Florian Westphal (2):
ipvs: reload ip header after head reallocation
netfilter: xt_physdev: masks are not c-strings
Julian Anastasov (1):
ipvs: fix more places with wrong ipv6 transport offsets
Pablo Neira Ayuso (1):
netfilter: flowtable: use correct direction to set up tunnel route
Wyatt Feng (1):
netfilter: xt_nat: reject unsupported target families
Xiang Mei (Microsoft) (1):
netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()
Yizhou Zhao (2):
netfilter: ecache: fix inverted time_after() check
netfilter: nf_conncount: fix zone comparison in tuple dedup
Zhengyang Chen (1):
selftests: netfilter: add bridge tunnel flowtable regression
net/ipv6/netfilter.c | 4 +-
net/netfilter/ipvs/ip_vs_app.c | 10 ++--
net/netfilter/ipvs/ip_vs_core.c | 3 +-
net/netfilter/ipvs/ip_vs_xmit.c | 6 +-
net/netfilter/nf_conncount.c | 6 +-
net/netfilter/nf_conntrack_ecache.c | 2 +-
net/netfilter/nf_flow_table_core.c | 6 +-
net/netfilter/xt_nat.c | 9 +++
net/netfilter/xt_physdev.c | 5 --
.../selftests/net/netfilter/nft_flowtable.sh | 55 +++++++++++++++++++
10 files changed, 81 insertions(+), 25 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH net v2] net: dpaa: fix mode setting
From: Michael Walle @ 2026-07-10 14:22 UTC (permalink / raw)
To: Madalin Bucur, Sean Anderson, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Russell King
Cc: netdev, linux-kernel, Michael Walle
Before converting to the phylink interface, the init function would have
set the correct I/F mode depending on the maximum link speed of an
interface. After converting to phylink, the established link speed
is used to determine this setting and is set in the .link_up()
callback. The callback isn't called because the link is never
established between the PCS and a connected SGMII PHY.
To fix it, don't use the current speed, but set the mode depending on
the interface (which implies the maximum speed) in .mac_config().
Fixes: 5d93cfcf7360 ("net: dpaa: Convert to phylink")
Suggested-by: Sean Anderson <sean.anderson@linux.dev>
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
FWIW, I dropped setting a non-reserved mode in init(). The hardware
default is 0 and the mac_config() will set a valid mode anyway.
Changes in v2:
- the setting is/was based on the maximum speed, not the current
speed. thus, move the setting into mac_config().
- Link to v1: https://lore.kernel.org/r/20260706121011.1948906-1-mwalle@kernel.org/
.../net/ethernet/freescale/fman/fman_dtsec.c | 26 ++++++++++---------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman_dtsec.c b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
index fe35703c509e..7075f93bab49 100644
--- a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
+++ b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
@@ -900,22 +900,28 @@ static void dtsec_mac_config(struct phylink_config *config, unsigned int mode,
{
struct mac_device *mac_dev = fman_config_to_mac(config);
struct dtsec_regs __iomem *regs = mac_dev->fman_mac->regs;
- u32 tmp;
+ u32 ecntrl, maccfg2;
+
+ maccfg2 = ioread32be(®s->maccfg2);
+ maccfg2 &= ~(MACCFG2_NIBBLE_MODE | MACCFG2_BYTE_MODE);
switch (state->interface) {
case PHY_INTERFACE_MODE_RMII:
- tmp = DTSEC_ECNTRL_RMM;
+ ecntrl = DTSEC_ECNTRL_RMM;
+ maccfg2 |= MACCFG2_NIBBLE_MODE;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
- tmp = DTSEC_ECNTRL_GMIIM | DTSEC_ECNTRL_RPM;
+ ecntrl = DTSEC_ECNTRL_GMIIM | DTSEC_ECNTRL_RPM;
+ maccfg2 |= MACCFG2_BYTE_MODE;
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
case PHY_INTERFACE_MODE_2500BASEX:
- tmp = DTSEC_ECNTRL_TBIM | DTSEC_ECNTRL_SGMIIM;
+ ecntrl = DTSEC_ECNTRL_TBIM | DTSEC_ECNTRL_SGMIIM;
+ maccfg2 |= MACCFG2_BYTE_MODE;
break;
default:
dev_warn(mac_dev->dev, "cannot configure dTSEC for %s\n",
@@ -923,7 +929,8 @@ static void dtsec_mac_config(struct phylink_config *config, unsigned int mode,
return;
}
- iowrite32be(tmp, ®s->ecntrl);
+ iowrite32be(ecntrl, ®s->ecntrl);
+ iowrite32be(maccfg2, ®s->maccfg2);
}
static void dtsec_link_up(struct phylink_config *config, struct phy_device *phy,
@@ -948,15 +955,10 @@ static void dtsec_link_up(struct phylink_config *config, struct phy_device *phy,
iowrite32be(tmp, ®s->ecntrl);
tmp = ioread32be(®s->maccfg2);
- tmp &= ~(MACCFG2_NIBBLE_MODE | MACCFG2_BYTE_MODE | MACCFG2_FULL_DUPLEX);
- if (speed >= SPEED_1000)
- tmp |= MACCFG2_BYTE_MODE;
- else
- tmp |= MACCFG2_NIBBLE_MODE;
-
if (duplex == DUPLEX_FULL)
tmp |= MACCFG2_FULL_DUPLEX;
-
+ else
+ tmp &= ~MACCFG2_FULL_DUPLEX;
iowrite32be(tmp, ®s->maccfg2);
mac_dev->update_speed(mac_dev, speed);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH bpf] bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
From: Daniel Borkmann @ 2026-07-10 14:32 UTC (permalink / raw)
To: Jose Fernandez (Anthropic), Eric Dumazet, Neal Cardwell,
Kuniyuki Iwashima, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrii Nakryiko, Yonghong Song, Martin KaFai Lau,
Jiayuan Chen, Emil Tsalapatis
Cc: netdev, linux-kernel, bpf, Ben Cressey
In-Reply-To: <alD1FJjR5r5n5Eau@linux.dev>
Hi Jose,
On 7/10/26 3:44 PM, Jose Fernandez (Anthropic) wrote:
> Hi all,
>
> Gentle ping. This has Reviewed-by from Jiayuan Chen and Emil Tsalapatis
> and no outstanding objections since Jun 29. Is anything else needed for
> bpf-fixes?
>
> On the automated review's flag about the pre-existing double-put on the
> bpf_iter_tcp_realloc_batch() failure path (cur_sk/end_sk not reset
> before seq_stop, so cookies can be re-put as pointers): agreed it is
> real, and it predates this change. As Jiayuan noted, it is a separate,
> pre-existing issue best addressed on its own; I kept this patch minimal
> for stable.
Given TCP, it would be good to still get an Ack from Kuniyuki or Eric and
then we can ship it. Are you planning to also follow-up with the other pre-
existing issue finding?
Thanks a lot,
Daniel
^ permalink raw reply
* Re: [PATCH net] net/iucv: take a reference on the socket found in afiucv_hs_rcv()
From: patchwork-bot+netdevbpf @ 2026-07-10 14:30 UTC (permalink / raw)
To: Bryam Vargas
Cc: pabeni, kuba, edumazet, davem, twinkler, wintera, nagamani, horms,
netdev, linux-kernel, linux-s390
In-Reply-To: <20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sun, 05 Jul 2026 22:24:36 -0500 you wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock,
> drops the lock, and then passes the socket to the afiucv_hs_callback_*()
> handlers without holding a reference. AF_IUCV sockets are not
> RCU-protected and are freed synchronously by iucv_sock_kill() ->
> sock_put(), so a concurrent close can free the socket in the window
> between read_unlock() and the handler, which then dereferences freed
> memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()).
>
> [...]
Here is the summary with links:
- [net] net/iucv: take a reference on the socket found in afiucv_hs_rcv()
https://git.kernel.org/netdev/net/c/4fa349156043
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2] bnge/bng_re: fix ring ID widths
From: Vikas Gupta @ 2026-07-10 14:25 UTC (permalink / raw)
To: Przemek Kitszel
Cc: netdev, linux-kernel, linux-rdma, leonro, jgg, bhargava.marreddy,
rahul-rg.gupta, vsrama-krishna.nemani, rajashekar.hudumula,
ajit.khaparde, Siva Reddy Kallam, Dharmender Garg,
Yendapally Reddy Dhananjaya Reddy, davem, edumazet, kuba, pabeni,
andrew+netdev, horms
In-Reply-To: <c108a5ec-8740-431e-849d-581c136f404d@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]
On Fri, Jul 10, 2026 at 3:36 PM Przemek Kitszel
<przemyslaw.kitszel@intel.com> wrote:
>
> On 7/4/26 18:47, Vikas Gupta wrote:
> > Firmware requires more than 16 bits to address TX ring IDs for its
> > internal QP management. Widen the associated HSI ring ID fields to
> > 32 bits. The values firmware assigns remain within 24 bits, bounded
> > by the hardware doorbell XID field.
> >
> > RX, completion, and NQ ring IDs are unaffected and remain 16-bit.
>
> Here you mention Rx is unaffected. But you touch multiple places that
> are Rx specific (some comments below).
The fw_ring_id field belongs to bnge_ring_struct, a common struct
shared by all ring types. Widening it to u32 applies uniformly across
TX, RX, CP, and NQ rings at the struct level.
I believe the commit message is incomplete but the intent was that
firmware assigns values within 16-bit range for all ring types
except TX, which requires the wider field.
Please let me know if this clarifies.
>
> [..]
>
> > --- a/drivers/net/ethernet/broadcom/bnge/bnge.h
> > +++ b/drivers/net/ethernet/broadcom/bnge/bnge.h
> > @@ -36,6 +36,7 @@ struct bnge_pf_info {
> > };
> >
> > #define INVALID_HW_RING_ID ((u16)-1)
> > +#define INVALID_HW_RING_ID_32BIT (U32_MAX)
>
> OK, there is much more usage of INVALID_HW_RING_ID than places touched
> by this patch.
INVALID_HW_RING_ID applies to 16-bit fields such as those in
bnge_ring_grp_info (rx_fw_ring_id, agg_fw_ring_id, nq_fw_ring_id)
and vnic fields.
INVALID_HW_RING_ID_32BIT applies to ring_struct.fw_ring_id (u32), all
instances of which are updated in this patch.
Thanks,
Vikas
>
> [...]
>
> > +++ b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
> > @@ -1327,12 +1327,12 @@ static int bnge_alloc_core(struct bnge_net *bn)
> > return rc;
> > }
> >
> > -u16 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr)
> > +u32 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr)
>
> and here you change Rx ring ID width.
>
> > {
> > return rxr->rx_cpr->ring_struct.fw_ring_id;
> > }
> >
> > -u16 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr)
> > +u32 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr)
> > {
> > return txr->tx_cpr->ring_struct.fw_ring_id;
> > }
> > @@ -1375,12 +1375,12 @@ static void bnge_init_nq_tree(struct bnge_net *bn)
> > struct bnge_nq_ring_info *nqr = &bn->bnapi[i]->nq_ring;
> > struct bnge_ring_struct *ring = &nqr->ring_struct;
> >
> > - ring->fw_ring_id = INVALID_HW_RING_ID;
> > + ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
> > for (j = 0; j < nqr->cp_ring_count; j++) {
> > struct bnge_cp_ring_info *cpr = &nqr->cp_ring_arr[j];
> >
> > ring = &cpr->ring_struct;
> > - ring->fw_ring_id = INVALID_HW_RING_ID;
> > + ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
> > }
> > }
> > }
> > @@ -1637,7 +1637,7 @@ static void bnge_init_one_rx_ring_rxbd(struct bnge_net *bn,
>
> ditto Rx
>
> >
> > ring = &rxr->rx_ring_struct;
> > bnge_init_rxbd_pages(ring, type);
> > - ring->fw_ring_id = INVALID_HW_RING_ID;
> > + ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
> > }
> >
> > static void bnge_init_one_agg_ring_rxbd(struct bnge_net *bn,
> > @@ -1647,7 +1647,7 @@ static void bnge_init_one_agg_ring_rxbd(struct bnge_net *bn,
>
> ditto Rx, and in some other places too
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5465 bytes --]
^ permalink raw reply
* Re: [PATCH net v2] gve: fix Rx queue stall on alloc failure
From: Przemek Kitszel @ 2026-07-10 14:24 UTC (permalink / raw)
To: Harshitha Ramamurthy
Cc: joshwash, andrew+netdev, davem, edumazet, kuba, pabeni, willemb,
jordanrhee, netdev, nktgrg, maolson, thostet, csully, bcf,
maciej.fijalkowski, linux-kernel, stable, Eddie Phillips
In-Reply-To: <20260709211906.3322883-1-hramamurthy@google.com>
> @@ -400,6 +414,26 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx)
> }
>
> rx->fill_cnt += num_posted;
> +
> + /* If the queue has fewer than GVE_RX_BUF_THRESH_DQO descriptors
> + * visible to the hardware, the hardware is in danger of starving
> + * and cannot trigger interrupts.
> + *
> + * We use a threshold of 32 because a single maximum-sized RSC
> + * packet can consume up to 19 descriptors in the Rx path. Lower
> + * thresholds (e.g., 8 or 16) would be unsafe as they could cause
> + * the device to drop/stall on a maximum-sized RSC packet.
> + *
> + * Start the timer to periodically reschedule NAPI and recover.
> + */
> + num_bufs_avail_to_hw =
> + ((bufq->tail & ~(GVE_RX_BUF_THRESH_DQO - 1)) -
> + bufq->head) & bufq->mask;
> +
> + if (num_bufs_avail_to_hw < GVE_RX_BUF_THRESH_DQO) {
nice bit-arith tricks, but perhaps a simpler condiion like:
if (num_avail_slots + num_posted < GVE_RX_BUF_THRESH_DQO)
would be sufficient?
> + mod_timer(&rx->starvation_timer,
> + jiffies + msecs_to_jiffies(GVE_RX_NAPI_RESCHED_MS));
> + }
> }
^ permalink raw reply
* RE: [PATCH net v4] tipc: fix u16 MTU truncation in media and bearer MTU validation
From: Tung Quang Nguyen @ 2026-07-10 14:23 UTC (permalink / raw)
To: Vadim Fedorenko
Cc: netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
AutonomousCodeSecurity@microsoft.com,
tgopinath@linux.microsoft.com, kys@microsoft.com,
jmaloy@redhat.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
Cen Zhang (Microsoft)
In-Reply-To: <a5bc092d-3312-4b1c-94cc-4a8bed6c6588@linux.dev>
>Subject: Re: [PATCH net v4] tipc: fix u16 MTU truncation in media and bearer
>MTU validation
>
>On 10/07/2026 13:57, Tung Quang Nguyen wrote:
>>> Subject: [PATCH net v4] tipc: fix u16 MTU truncation in media and
>>> bearer MTU validation
>>>
>>> Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied
>>> MTU values but only enforce a minimum bound, not a maximum. When a
>>> user sets the MTU to a value exceeding U16_MAX (65535), it passes
>>> validation but is silently truncated when assigned to u16 fields
>>> l->mtu and
>>> l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000)
>>> truncate to 0, causing a division by zero in
>>> tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu /
>>> ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce
>>> small incorrect MTU values, resulting in link malfunction behaviors.
>>
>> Yes, this is a bug. I can reproduce the same div-by-zero.
>>
>>>
>>> Crash stack (triggered as unprivileged user via user namespace):
>>>
>>> tipc_link_set_queue_limits net/tipc/link.c:2531
>>> tipc_link_create net/tipc/link.c:520
>>> tipc_node_check_dest net/tipc/node.c:1279
>>> tipc_disc_rcv net/tipc/discover.c:252
>>> tipc_rcv net/tipc/node.c:2129
>>> tipc_udp_recv net/tipc/udp_media.c:392
>>>
>>> Two independent paths lack the upper bound check:
>>> 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET)
>2.
>>> inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET)
>>>
>>> Fix both by rejecting MTU values above U16_MAX.
>>>
>>> Fixes: 901271e0403a ("tipc: implement configuration of UDP media
>>> MTU")
>>> Reported-by: AutonomousCodeSecurity@microsoft.com
>>> Closes: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-
>>> CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com
>>> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
>>> ---
>>> v4: Add .min check value
>>> v3: Use nla_policy check to limit MTU max value as suggested by Vadim
>>> v2: Solved format issue
>>> Link: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-
>>> CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com
>>>
>>> net/tipc/netlink.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c index
>>> 8336a9664703..811438c44542 100644
>>> --- a/net/tipc/netlink.c
>>> +++ b/net/tipc/netlink.c
>>> @@ -113,12 +113,17 @@ const struct nla_policy
>>> tipc_nl_node_policy[TIPC_NLA_NODE_MAX + 1] = { };
>>>
>>> /* Properties valid for media, bearer and link */
>>> +static const struct netlink_range_validation tipc_nl_mtu_range = {
>>> + .min = TIPC_MIN_BEARER_MTU,
>>
>> Adding lower threshold checking introduces two issues:
>> 1. Existing function tipc_udp_mtu_bad() can never return "true".
>
>it can. if MTU is in the range [TIPC_MIN_BEARER_MTU,
>TIPC_MIN_BEARER_MTU
>+ sizeof(iphdr) + sizeof(udphdr)]
The context I was talking about is error path (mtu < min) as shown in examples. This makes adding .min check redundant.
>
>> 2. Breaking user-space applications looking for error message " Error: MTU
>value is out-of-range". Look at the error messages before and after your patch:
>> [Before patch]
>> node1 ~ # tipc bearer set mtu 15 media udp name UDP0
>> Error: MTU value is out-of-range.
>> kernel answers: Invalid argument
>>
>> [After patch]
>> node1 ~ # tipc bearer set mtu 15 media udp name UDP0 kernel answers:
>> Numerical result out of range
>
>that's interesting, because this error message belongs to 9p scope...
>
>anyways, we can keep v3 of this patch with .max value set only
>
>
>>
>>> + .max = U16_MAX,
>>> +};
>>> +
>>> const struct nla_policy tipc_nl_prop_policy[TIPC_NLA_PROP_MAX + 1] = {
>>> [TIPC_NLA_PROP_UNSPEC] = { .type = NLA_UNSPEC },
>>> [TIPC_NLA_PROP_PRIO] = { .type = NLA_U32 },
>>> [TIPC_NLA_PROP_TOL] = { .type = NLA_U32 },
>>> [TIPC_NLA_PROP_WIN] = { .type = NLA_U32 },
>>> - [TIPC_NLA_PROP_MTU] = { .type = NLA_U32 },
>>> + [TIPC_NLA_PROP_MTU] =
>>> NLA_POLICY_FULL_RANGE(NLA_U32, &tipc_nl_mtu_range),
>>> [TIPC_NLA_PROP_BROADCAST] = { .type = NLA_U32 },
>>> [TIPC_NLA_PROP_BROADCAST_RATIO] = { .type = NLA_U32 }
>>> };
>>> --
>>> 2.53.0
>>
^ permalink raw reply
* Re: [PATCH net-next 0/3] vxlan: RCU protect vxlan_config and enable RTNL-less fill_info
From: Paolo Abeni @ 2026-07-10 14:22 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: Simon Horman, Kuniyuki Iwashima, Ido Schimmel, Andrew Lunn,
netdev, eric.dumazet
In-Reply-To: <991ec032-c6fe-4236-be22-323a9e3cb07e@redhat.com>
On 7/10/26 4:20 PM, Paolo Abeni wrote:
> On 7/8/26 6:04 PM, Eric Dumazet wrote:
>> This patch series converts VXLAN configuration (`struct vxlan_config`)
>> to be RCU-protected, allowing lockless readers and enabling RTNL-less
>> `vxlan_fill_info()` netlink link info dumping.
>>
>> Work has been split into three distinct parts:
>>
>> 1. Refactor helper functions in RX, TX, MDB, VNIFILTER, and OVS paths to
>> accept a `const struct vxlan_config *cfg` pointer (or pass specific
>> fields such as `flags`/`saddr_family`) rather than accessing
>> `vxlan->cfg` directly.
>>
>> 2. Convert `vxlan->cfg` from an embedded struct into an RCU-protected
>> pointer (`struct vxlan_config __rcu *cfg`), dynamically allocated on
>> device creation or changelink, and freed via `kfree_rcu()`. Update
>> offload drivers (`mlxsw`) and OVS (`vport-vxlan.c`) accordingly.
>>
>> 3. Update `vxlan_fill_info()` to run under `rcu_read_lock()` instead of
>> relying on RTNL lock, completing the transition to lockless link info
>> dumping for VXLAN devices.
>
> I *suspect* this is triggering RCU splat in forwarding self-tests:
>
> [ 1955.481960][T11074] =============================
oops, sashiko already spotted it:
https://sashiko.dev/#/patchset/20260708160411.1355008-1-edumazet%40google.com
/P
^ permalink raw reply
* Re: [PATCH net v3 2/3] net: ethernet: oa_tc6: Improvement in buffer overflow handling
From: Simon Horman @ 2026-07-10 14:20 UTC (permalink / raw)
To: Selvamani.Rajagopal
Cc: Simon Horman, parthiban.veerasooran, andrew+netdev, pier.beruto,
davem, edumazet, kuba, pabeni, netdev, linux-kernel, andrew,
Parthiban.Veerasooran
In-Reply-To: <20260705-fix-race-condition-and-crash-v3-2-3e51841e4d08@onsemi.com>
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/
---
net: ethernet: oa_tc6: Improvement in buffer overflow handling
This patch teaches the oa_tc6 rx path to detect when tail + length would
exceed skb->end, abandon the current rx_skb, and resume on the next
data chunk carrying a start_valid bit. It also propagates -EAGAIN as a
recoverable error through the chunk/footer processing and the outer
SPI transfer loop.
> diff --git a/drivers/net/ethernet/oa_tc6.c b/drivers/net/ethernet/oa_tc6.c
> index 5b24cce4f9b5..a6b8762f6052 100644
> --- a/drivers/net/ethernet/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6.c
[ ... ]
> @@ -931,8 +966,7 @@ static int oa_tc6_prcs_rx_chunk_payload(struct oa_tc6 *tc6, u8 *data,
> /* Process the chunk with only rx frame end */
> if (end_valid && !start_valid) {
> size = end_byte_offset + 1;
> - oa_tc6_prcs_rx_frame_end(tc6, data, size);
> - return 0;
> + return oa_tc6_prcs_rx_frame_end(tc6, data, size);
> }
>
> /* Process the chunk with previous rx frame end and next rx frame
[High]
Now that oa_tc6_prcs_rx_frame_end() returns int (and can return -EAGAIN
via oa_tc6_update_rx_skb() when tail + size > end), should the
"previous rx frame end + next rx frame start" branch also observe the
return value? That branch is not shown in the diff, but in the
resulting file it reads:
if (start_valid && end_valid && start_byte_offset > end_byte_offset) {
if (tc6->rx_skb) {
size = end_byte_offset + 1;
oa_tc6_prcs_rx_frame_end(tc6, data, size);
}
size = OA_TC6_CHUNK_PAYLOAD_SIZE - start_byte_offset;
return oa_tc6_prcs_rx_frame_start(tc6,
&data[start_byte_offset],
size);
}
If oa_tc6_prcs_rx_frame_end() here returns -EAGAIN, oa_tc6_look_for_new_frame()
has already set tc6->rx_buf_overflow = true and cleared rx_skb. Execution
then falls through to oa_tc6_prcs_rx_frame_start(), which allocates a
fresh rx_skb and copies the start bytes, but tc6->rx_buf_overflow stays
true because the guard
if (start_valid && tc6->rx_buf_overflow)
tc6->rx_buf_overflow = false;
is only evaluated on chunk entry. Subsequent ongoing chunks (no
start_valid) then hit the earlier
if (tc6->rx_buf_overflow)
return 0;
path and are silently dropped, and the partial rx_skb is later thrown
away by the next allocate_rx_skb() -> cleanup_ongoing_rx_skb(), which
also increments rx_dropped. Is this the intended behaviour for the
oversubscribed/chunk-loss scenario the patch is targeting?
[ ... ]
> @@ -972,8 +1004,9 @@ static u32 oa_tc6_get_rx_chunk_footer(struct oa_tc6 *tc6, u16 footer_offset)
> static int oa_tc6_process_spi_data_rx_buf(struct oa_tc6 *tc6, u16 length)
> {
> u16 no_of_rx_chunks = length / OA_TC6_CHUNK_SIZE;
> + bool retry = false;
> + int ret = 0;
> u32 footer;
> - int ret;
>
> /* All the rx chunks in the receive SPI data buffer are examined here */
> for (int i = 0; i < no_of_rx_chunks; i++) {
> @@ -982,8 +1015,11 @@ static int oa_tc6_process_spi_data_rx_buf(struct oa_tc6 *tc6, u16 length)
> OA_TC6_CHUNK_PAYLOAD_SIZE);
>
> ret = oa_tc6_process_rx_chunk_footer(tc6, footer);
> - if (ret)
> - return ret;
> + if (ret) {
> + if (ret != -EAGAIN)
> + return ret;
> + retry = true;
> + }
>
> /* If there is a data valid chunks then process it for the
> * information needed to determine the validity and the location
> @@ -995,12 +1031,25 @@ static int oa_tc6_process_spi_data_rx_buf(struct oa_tc6 *tc6, u16 length)
>
> ret = oa_tc6_prcs_rx_chunk_payload(tc6, payload,
> footer);
> - if (ret)
> - return ret;
> + if (ret) {
> + if (ret != -ENOMEM && ret != -EAGAIN)
> + return ret;
> + retry = true;
> + }
> }
> }
[Medium]
Is it intentional that a real -ENOMEM from oa_tc6_prcs_rx_chunk_payload()
(originating in oa_tc6_allocate_rx_skb() -> netdev_alloc_skb_ip_align())
is now folded into the retry path and converted to -EAGAIN at the end
of this function?
Before this patch, -ENOMEM propagated up through oa_tc6_try_spi_transfer()
and produced a netdev_err("Device error: %d", ret) plus
oa_tc6_free_ongoing_skbs() cleanup. With this change, the outer while
loop treats -EAGAIN as non-fatal, so sustained memory exhaustion is
reported only as increments to stats.rx_dropped from
oa_tc6_allocate_rx_skb().
The commit message describes the change as being about buffer overflow
errors; is the change in visibility for allocation failures intended?
>
> - return 0;
> + /* As a recoverable error, not bailing out on error code
> + * -EAGAIN. If subsequent loop iterations, if any, succeeds,
> + * error code would be overwritten. retry flag helps to
> + * make the caller to continue and retry.
> + */
> + if (retry) {
> + ret = -EAGAIN;
> + oa_tc6_look_for_new_frame(tc6);
> + }
> +
> + return ret;
> }
[High]
Can this unconditional oa_tc6_look_for_new_frame() discard a frame that
was successfully started later in the same buffer?
Consider a buffer where iteration N returns -EAGAIN from
oa_tc6_process_rx_chunk_footer() due to STATUS0 rx overflow (which
already sets rx_buf_overflow and clears rx_skb), and a later iteration
N+K carries a start_valid chunk that clears rx_buf_overflow via
if (start_valid && tc6->rx_buf_overflow)
tc6->rx_buf_overflow = false;
allocates a fresh rx_skb in oa_tc6_prcs_rx_frame_start(), and writes
the start bytes without further error. retry is still true from
iteration N, so on loop exit the terminal oa_tc6_look_for_new_frame()
frees that newly-started rx_skb (incrementing rx_dropped) and re-sets
rx_buf_overflow = true.
On the next SPI transfer, the ongoing chunks of that frame are then
dropped by the top-of-function
if (tc6->rx_buf_overflow)
return 0;
guard in oa_tc6_prcs_rx_chunk_payload() until yet another start_valid
arrives. Would it be safer to only call oa_tc6_look_for_new_frame()
here if the last iteration was still in an errored state, e.g. by
tracking the outcome of the most recent chunk rather than an aggregate
retry flag?
[ ... ]
^ permalink raw reply
* Re: [PATCH net-next 0/3] vxlan: RCU protect vxlan_config and enable RTNL-less fill_info
From: Paolo Abeni @ 2026-07-10 14:20 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: Simon Horman, Kuniyuki Iwashima, Ido Schimmel, Andrew Lunn,
netdev, eric.dumazet
In-Reply-To: <20260708160411.1355008-1-edumazet@google.com>
On 7/8/26 6:04 PM, Eric Dumazet wrote:
> This patch series converts VXLAN configuration (`struct vxlan_config`)
> to be RCU-protected, allowing lockless readers and enabling RTNL-less
> `vxlan_fill_info()` netlink link info dumping.
>
> Work has been split into three distinct parts:
>
> 1. Refactor helper functions in RX, TX, MDB, VNIFILTER, and OVS paths to
> accept a `const struct vxlan_config *cfg` pointer (or pass specific
> fields such as `flags`/`saddr_family`) rather than accessing
> `vxlan->cfg` directly.
>
> 2. Convert `vxlan->cfg` from an embedded struct into an RCU-protected
> pointer (`struct vxlan_config __rcu *cfg`), dynamically allocated on
> device creation or changelink, and freed via `kfree_rcu()`. Update
> offload drivers (`mlxsw`) and OVS (`vport-vxlan.c`) accordingly.
>
> 3. Update `vxlan_fill_info()` to run under `rcu_read_lock()` instead of
> relying on RTNL lock, completing the transition to lockless link info
> dumping for VXLAN devices.
I *suspect* this is triggering RCU splat in forwarding self-tests:
[ 1955.481960][T11074] =============================
[ 1955.482076][T11074] WARNING: suspicious RCU usage
[ 1955.482190][T11074] 7.2.0-rc2-virtme #1 Not tainted
[ 1955.482304][T11074] -----------------------------
[ 1955.482886][T11074] drivers/net/vxlan/vxlan_core.c:1872 suspicious rcu_dereference_check() usage!
[ 1955.483087][T11074]
[ 1955.483087][T11074] other info that might help us debug this:
[ 1955.483087][T11074]
[ 1955.483312][T11074]
[ 1955.483312][T11074] rcu_scheduler_active = 2, debug_locks = 1
[ 1955.483489][T11074] 1 lock held by arping/11074:
[ 1955.483623][T11074] #0: ffffffffbad91d60 (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit+0x204/0x1b90
[ 1955.483836][T11074]
[ 1955.483836][T11074] stack backtrace:
[ 1955.483977][T11074] CPU: 0 UID: 0 PID: 11074 Comm: arping Not tainted 7.2.0-rc2-virtme #1 PREEMPT(full)
[ 1955.483980][T11074] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1955.483982][T11074] Call Trace:
[ 1955.483983][T11074] <TASK>
[ 1955.483984][T11074] dump_stack_lvl+0x6f/0xa0
[ 1955.483990][T11074] lockdep_rcu_suspicious.cold+0x37/0x89
[ 1955.483995][T11074] arp_reduce.isra.0+0x9b9/0x1080 [vxlan]
[ 1955.484003][T11074] ? mark_usage+0x61/0x170
[ 1955.484007][T11074] ? __lock_acquire+0x518/0xc20
[ 1955.484010][T11074] ? vxlan_nl2conf+0x5b30/0x5b30 [vxlan]
[ 1955.484015][T11074] ? lock_acquire.part.0+0xbc/0x260
[ 1955.484017][T11074] ? find_held_lock+0x2b/0x80
[ 1955.484020][T11074] ? __lock_release.isra.0+0x6b/0x1a0
[ 1955.484025][T11074] ? vxlan_xmit+0x128b/0x1660 [vxlan]
[ 1955.484029][T11074] vxlan_xmit+0x128b/0x1660 [vxlan]
[ 1955.484034][T11074] ? rcu_lockdep_current_cpu_online+0x39/0x1b0
[ 1955.484039][T11074] dev_hard_start_xmit+0xf4/0x620
[ 1955.484042][T11074] ? validate_xmit_skb+0x72/0x9a0
[ 1955.484045][T11074] __dev_queue_xmit+0xc1a/0x1b90
[ 1955.484047][T11074] ? _copy_from_iter+0x1bb/0x1810
[ 1955.484052][T11074] ? __alloc_skb+0x342/0x5f0
[ 1955.484055][T11074] ? _copy_from_iter_flushcache+0x1970/0x1970
[ 1955.484057][T11074] ? ref_tracker_alloc+0x2e7/0x430
[ 1955.484060][T11074] ? netdev_core_pick_tx+0x2c0/0x2c0
[ 1955.484064][T11074] ? packet_parse_headers+0x325/0x830
[ 1955.484067][T11074] ? __asan_memset+0x27/0x50
[ 1955.484070][T11074] ? packet_parse_headers+0x325/0x830
[ 1955.484073][T11074] ? skb_copy_datagram_from_iter+0xf3/0x6a0
[ 1955.484075][T11074] ? packet_release+0xc70/0xc70
[ 1955.484079][T11074] packet_snd+0xfad/0x1990
[ 1955.484085][T11074] ? tpacket_snd+0x19e0/0x19e0
[ 1955.484087][T11074] ? __might_fault+0x97/0x140
[ 1955.484093][T11074] ? __might_fault+0x97/0x140
[ 1955.484095][T11074] ? __might_fault+0x97/0x140
[ 1955.484098][T11074] __sys_sendto+0x2aa/0x400
[ 1955.484101][T11074] ? __ia32_sys_getpeername+0xd0/0xd0
[ 1955.484110][T11074] ? do_user_addr_fault+0x325/0xe30
[ 1955.484116][T11074] __x64_sys_sendto+0xe4/0x1f0
[ 1955.484117][T11074] ? trace_irq_enable.constprop.0+0x9b/0x160
[ 1955.484121][T11074] ? lockdep_hardirqs_on+0x8c/0x130
[ 1955.484123][T11074] ? do_syscall_64+0x82/0x590
[ 1955.484126][T11074] do_syscall_64+0x117/0x590
[ 1955.484127][T11074] ? trace_hardirqs_off+0xd/0x30
[ 1955.484129][T11074] ? exc_page_fault+0xee/0x100
[ 1955.484132][T11074] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 1955.484134][T11074] RIP: 0033:0x7f138c3ec54e
[ 1955.484138][T11074] Code: 4d 89 d8 e8 b4 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 03 ff ff ff 0f 1f 00 f3 0f 1e fa
[ 1955.484139][T11074] RSP: 002b:00007ffc648f74e0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 1955.484142][T11074] RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007f138c3ec54e
[ 1955.484143][T11074] RDX: 000000000000001c RSI: 00007ffc648f7560 RDI: 0000000000000005
[ 1955.484144][T11074] RBP: 00007ffc648f74f0 R08: 00007ffc648f79e0 R09: 0000000000000014
[ 1955.484145][T11074] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
[ 1955.484146][T11074] R13: 00007ffc648f7910 R14: ffffffffffffffe8 R15: 0000000000000000
full log at:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-dbg/results/728082/83-test-vxlan-nh-sh/stderr
Tentatively setting the series to 'changes requested'
/P
^ permalink raw reply
* Re: Question: net: phy: realtek: RTL8211FS SGMII bridge mode support
From: Jacky Huang @ 2026-07-10 14:17 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Jacky Huang, Andrew Lunn, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Daniel Golle, Vladimir Oltean, netdev, linux-kernel
In-Reply-To: <9d4bab68-6383-4b8d-a9d0-144b348e937c@bootlin.com>
Hi Maxime,
Thanks for the feedback! I had not considered the SFP or additional PHY case
before.
The hardware we plan to support has the SGMII side permanently connected to
an Ethernet switch.
MAC - RGMII - RTL8211FS - SGMII - Ethernet switch
The switch is initialized from a configuration EEPROM. There is no SFP or
separate PHY on the SGMII link.
I will take another look at how the SGMII-side status and in-band aneg should
be handled.
In addition, after reviewing the board-level strap design, I found that the
intended mode may not always be selected reliably, so I still need to consider
a strap-override flow.
Thanks again,
Jacky
^ permalink raw reply
* Re: [PATCH net] ipv4: fib: free fib_alias with kfree_rcu() on insert error path
From: patchwork-bot+netdevbpf @ 2026-07-10 14:10 UTC (permalink / raw)
To: Weiming Shi
Cc: netdev, dsahern, idosch, edumazet, kuba, pabeni, davem, horms,
xmei5, linux-kernel
In-Reply-To: <20260704171421.1786806-1-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 4 Jul 2026 10:14:21 -0700 you wrote:
> fib_table_insert() publishes new_fa into the leaf's fa_list with
> fib_insert_alias() before calling the fib entry notifiers. When a
> notifier fails, the error path removes new_fa with fib_remove_alias()
> (hlist_del_rcu) and frees it right away with kmem_cache_free().
>
> fib_table_lookup() walks that list under rcu_read_lock() only, so a
> concurrent lookup that already reached new_fa keeps reading it after the
> free:
>
> [...]
Here is the summary with links:
- [net] ipv4: fib: free fib_alias with kfree_rcu() on insert error path
https://git.kernel.org/netdev/net/c/f2f152e94a67
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net] mac802154: hold an interface reference across the scan worker
From: Ibrahim Hashimov @ 2026-07-10 14:09 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, linux-wpan, netdev, linux-kernel, stable
mac802154_scan_worker() captures the scanning sub-interface once under
RCU:
sdata = IEEE802154_WPAN_DEV_TO_SUB_IF(scan_req->wpan_dev);
and then, after rcu_read_unlock() and outside the rtnl, keeps
dereferencing sdata->dev: in the channel-change and restart failure
traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev) for
active scans, in the final dev_dbg(), and in the end_scan
mac802154_scan_cleanup_locked() path. Nothing keeps that netdev alive
for the duration of the worker iteration.
A concurrent teardown of the scanning interface -- userspace issuing
NL802154_CMD_DEL_INTERFACE (ieee802154_if_remove() ->
unregister_netdevice()), or a full PHY removal via
ieee802154_unregister_hw() -> ieee802154_remove_interfaces() -- can run
as soon as the worker drops the rtnl between its two short
drv_set_channel()/drv_start() sections. The netdev is not freed
synchronously by unregister_netdevice(): it is queued to net_todo_list
and freed later from netdev_run_todo(), which drops the rtnl mutex
(__rtnl_unlock()) *before* netdev_wait_allrefs_any()/free_netdev(). The
freeing therefore runs with the rtnl not held, on whichever task next
drains net_todo_list. Holding the rtnl in the worker does not prevent
it, and the per-PHY IEEE802154_IS_SCANNING flag does not identify the
specific interface: a subsequent NEW_INTERFACE + TRIGGER_SCAN re-arms
the flag, so a stale worker iteration sails past an is-scanning recheck
and dereferences the already-freed netdev.
Triggering the race requires CAP_NET_ADMIN: both
NL802154_CMD_TRIGGER_SCAN and NL802154_CMD_DEL_INTERFACE are
GENL_ADMIN_PERM, reachable only from the initial user namespace, so
the attacker is a locally privileged (CAP_NET_ADMIN) user, not an
unprivileged local user or a remote peer.
KASAN slab-use-after-free, kworker reading the freed
net_device/ieee802154_sub_if_data (kmalloc-cg-4k) allocated and freed by
the racing NEW_INTERFACE/DEL_INTERFACE task:
BUG: KASAN: slab-use-after-free in mac802154_scan_worker+0x... [mac802154]
Read of size 8 ... by task kworker/u8:N
Workqueue: phy0-mac-cmds mac802154_scan_worker [mac802154]
mac802154_scan_worker
process_one_work
(also hit via ieee802154_mlme_tx_locked() from the beacon-request path
and via _dev_err()/__dev_printk() formatting sdata->dev->dev)
Fix it by taking a reference on the interface while the RCU read lock is
still held -- so the netdev cannot be freed before the refcount is
raised -- and releasing it at every exit of the worker past that point.
This keeps sdata->dev valid for the whole iteration.
The reference does not defer the free indefinitely and does not
deadlock the single-threaded mac_wq. Each worker iteration drops the
reference before it requeues itself, and a teardown started while the
reference is held simply blocks in netdev_run_todo() until the current
iteration returns. It cannot be the worker's own rtnl_unlock() that
blocks on the reference either: the unregistering task removes the
netdev from net_todo_list under the rtnl (list_replace_init() in
netdev_run_todo() runs before __rtnl_unlock()), so it always owns the
todo entry, and the worker acquires the rtnl only afterwards -- the
blocking netdev_wait_allrefs_any() therefore always runs on the
teardown task, never on the worker.
Verified on a v6.19 KASAN build: racing DEL_INTERFACE against an
in-flight TRIGGER_SCAN reliably tripped a slab-use-after-free KASAN
report inside mac802154_scan_worker() before this patch, and the
same reproducer no longer triggers it with the fix applied.
Fixes: 57588c71177f ("mac802154: Handle passive scanning")
Cc: stable@vger.kernel.org
Assisted-by: AuditCode-AI:2026.07
Signed-off-by: Ibrahim Hashimov <security@auditcode.ai>
---
net/mac802154/scan.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 0a31ac8d8415..48e661031cc0 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -209,6 +209,26 @@ void mac802154_scan_worker(struct work_struct *work)
return;
}
+ /* From here on sdata->dev is dereferenced after rcu_read_unlock() and
+ * outside the rtnl: in the dev_err()/dev_dbg() traces below, in
+ * mac802154_transmit_beacon_req() (skb->dev = sdata->dev) and in the
+ * end_scan mac802154_scan_cleanup_locked() call. A concurrent teardown
+ * of that interface (NL802154_CMD_DEL_INTERFACE ->
+ * ieee802154_if_remove(), or a full PHY removal via
+ * ieee802154_unregister_hw()) can unregister the netdev; the actual
+ * free then runs asynchronously from netdev_run_todo() with the rtnl
+ * already dropped, so neither holding the rtnl nor the per-PHY
+ * IEEE802154_IS_SCANNING flag keeps sdata->dev alive here. Pin it with
+ * a reference taken while we still hold the RCU read lock (so the
+ * netdev cannot be freed before we bump the refcount) and drop it at
+ * every exit below. This blocks the teardown's netdev_run_todo() until
+ * this worker iteration is done; it cannot self-deadlock because the
+ * unregistering task claims the net_todo_list entry under the rtnl, so
+ * the blocking netdev_wait_allrefs_any() always runs on that task, not
+ * on this single-threaded worker.
+ */
+ dev_hold(sdata->dev);
+
wpan_phy = scan_req->wpan_phy;
scan_req_type = scan_req->type;
scan_req_duration = scan_req->duration;
@@ -262,12 +282,14 @@ void mac802154_scan_worker(struct work_struct *work)
"Scan page %u channel %u for %ums\n",
page, channel, jiffies_to_msecs(scan_duration));
queue_delayed_work(local->mac_wq, &local->scan_work, scan_duration);
+ dev_put(sdata->dev);
return;
end_scan:
rtnl_lock();
mac802154_scan_cleanup_locked(local, sdata, false);
rtnl_unlock();
+ dev_put(sdata->dev);
}
int mac802154_trigger_scan_locked(struct ieee802154_sub_if_data *sdata,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v3 00/20] driver core: count references of the platform device's fwnode, not OF node
From: Greg Kroah-Hartman @ 2026-07-10 14:09 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Vinod Koul, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Andy Shevchenko,
Joerg Roedel, Will Deacon, Robin Murphy, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Matthew Brost, Thomas Hellström, Rodrigo Vivi,
David Airlie, Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu,
Philipp Zabel, Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86,
mfd, stable, Manuel Ebner, Wolfram Sang, Konrad Dybcio
In-Reply-To: <20260706-pdev-fwnode-ref-v3-0-1ff028e33779@oss.qualcomm.com>
On Mon, Jul 06, 2026 at 02:44:12PM +0200, Bartosz Golaszewski wrote:
> Platform device core provides helper interfaces for dealing with
> dynamically created platform devices. Most users should use
> platform_device_register_full() which encapsulates most of the
> operations but some modules will want to use the split approach of
> calling platform_device_alloc() + platform_device_add() separately for
> various reasons.
>
> With many platform devices now using dynamic software nodes as their
> primary firmware nodes and with the platform device interface being
> extended to also better cover the use-cases of secondary software nodes,
> I believe it makes sense to switch to counting the references of all
> kinds of firmware nodes.
>
> To that end, I identified all users of platform_device_alloc() that also
> assign dev.of_node or dev.fwnode manually. I noticed five cases where
> the references are not increased as they should (patches 1-5 fix these
> users) and provided three new functions in platform_device.h that now
> become the preferred interfaces for assigning firmware nodes to dynamic
> platform devices (in line with platform_device_add_data(),
> platform_device_add_resources(), etc.). The bulk of the patches in this
> series are small driver conversions to port all users to going through
> the new functions that now encapsulate the refcount logic. With that
> done, the final patch seamlessly switches to counting the references of
> all firmware node types.
>
> This effort is prerequisite of removing platform_device_release_full()
> and unifying the release path for dynamic platform devices using
> unmanaged software nodes.
>
> Merging strategy: The entire series should go through the driver core
> tree, possibly with an immutable branch provided to solve any potential
> conflicts though these are rather unlikely.
I've added this to the driver-core-testing branch now, thanks!
greg k-h
^ permalink raw reply
* Re: [PATCH net v4] tipc: fix u16 MTU truncation in media and bearer MTU validation
From: Vadim Fedorenko @ 2026-07-10 14:02 UTC (permalink / raw)
To: Tung Quang Nguyen, Cen Zhang (Microsoft)
Cc: netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
AutonomousCodeSecurity@microsoft.com,
tgopinath@linux.microsoft.com, kys@microsoft.com,
jmaloy@redhat.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org
In-Reply-To: <GV1P189MB1988A52C474B5F7D7A9EC00CC6FD2@GV1P189MB1988.EURP189.PROD.OUTLOOK.COM>
On 10/07/2026 13:57, Tung Quang Nguyen wrote:
>> Subject: [PATCH net v4] tipc: fix u16 MTU truncation in media and bearer MTU
>> validation
>>
>> Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied
>> MTU values but only enforce a minimum bound, not a maximum. When a user
>> sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is
>> silently truncated when assigned to u16 fields l->mtu and
>> l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000)
>> truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which
>> computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values
>> (e.g. 65537-131071) produce small incorrect MTU values, resulting in link
>> malfunction behaviors.
>
> Yes, this is a bug. I can reproduce the same div-by-zero.
>
>>
>> Crash stack (triggered as unprivileged user via user namespace):
>>
>> tipc_link_set_queue_limits net/tipc/link.c:2531
>> tipc_link_create net/tipc/link.c:520
>> tipc_node_check_dest net/tipc/node.c:1279
>> tipc_disc_rcv net/tipc/discover.c:252
>> tipc_rcv net/tipc/node.c:2129
>> tipc_udp_recv net/tipc/udp_media.c:392
>>
>> Two independent paths lack the upper bound check:
>> 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2.
>> inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET)
>>
>> Fix both by rejecting MTU values above U16_MAX.
>>
>> Fixes: 901271e0403a ("tipc: implement configuration of UDP media MTU")
>> Reported-by: AutonomousCodeSecurity@microsoft.com
>> Closes: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-
>> CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com
>> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
>> ---
>> v4: Add .min check value
>> v3: Use nla_policy check to limit MTU max value as suggested by Vadim
>> v2: Solved format issue
>> Link: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-
>> CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com
>>
>> net/tipc/netlink.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c index
>> 8336a9664703..811438c44542 100644
>> --- a/net/tipc/netlink.c
>> +++ b/net/tipc/netlink.c
>> @@ -113,12 +113,17 @@ const struct nla_policy
>> tipc_nl_node_policy[TIPC_NLA_NODE_MAX + 1] = { };
>>
>> /* Properties valid for media, bearer and link */
>> +static const struct netlink_range_validation tipc_nl_mtu_range = {
>> + .min = TIPC_MIN_BEARER_MTU,
>
> Adding lower threshold checking introduces two issues:
> 1. Existing function tipc_udp_mtu_bad() can never return "true".
it can. if MTU is in the range [TIPC_MIN_BEARER_MTU, TIPC_MIN_BEARER_MTU
+ sizeof(iphdr) + sizeof(udphdr)]
> 2. Breaking user-space applications looking for error message " Error: MTU value is out-of-range". Look at the error messages before and after your patch:
> [Before patch]
> node1 ~ # tipc bearer set mtu 15 media udp name UDP0
> Error: MTU value is out-of-range.
> kernel answers: Invalid argument
>
> [After patch]
> node1 ~ # tipc bearer set mtu 15 media udp name UDP0
> kernel answers: Numerical result out of range
that's interesting, because this error message belongs to 9p scope...
anyways, we can keep v3 of this patch with .max value set only
>
>> + .max = U16_MAX,
>> +};
>> +
>> const struct nla_policy tipc_nl_prop_policy[TIPC_NLA_PROP_MAX + 1] = {
>> [TIPC_NLA_PROP_UNSPEC] = { .type = NLA_UNSPEC },
>> [TIPC_NLA_PROP_PRIO] = { .type = NLA_U32 },
>> [TIPC_NLA_PROP_TOL] = { .type = NLA_U32 },
>> [TIPC_NLA_PROP_WIN] = { .type = NLA_U32 },
>> - [TIPC_NLA_PROP_MTU] = { .type = NLA_U32 },
>> + [TIPC_NLA_PROP_MTU] =
>> NLA_POLICY_FULL_RANGE(NLA_U32, &tipc_nl_mtu_range),
>> [TIPC_NLA_PROP_BROADCAST] = { .type = NLA_U32 },
>> [TIPC_NLA_PROP_BROADCAST_RATIO] = { .type = NLA_U32 }
>> };
>> --
>> 2.53.0
>
^ permalink raw reply
* Re: [PATCH net-next] net: chelsio: cxgb4: Use str_plural() in mem_intr_handler()
From: patchwork-bot+netdevbpf @ 2026-07-10 14:00 UTC (permalink / raw)
To: Thorsten Blum
Cc: bharat, andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <20260704121010.201016-3-thorsten.blum@linux.dev>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 4 Jul 2026 14:10:11 +0200 you wrote:
> Replace the manual ternary "s" pluralization with str_plural() to
> simplify the code.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Here is the summary with links:
- [net-next] net: chelsio: cxgb4: Use str_plural() in mem_intr_handler()
https://git.kernel.org/netdev/net-next/c/d5d7554052f3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 2/2] module: Bring includes in linux/kmod.h up to date
From: Aaron Tomlin @ 2026-07-10 13:57 UTC (permalink / raw)
To: Petr Pavlu
Cc: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Pavel Machek, Len Brown, Andrew Morton, Danilo Krummrich,
Nikolay Aleksandrov, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Howells,
Jarkko Sakkinen, Paul Moore, James Morris, Serge E. Hallyn,
Kentaro Takeda, Tetsuo Handa, linux-edac, linux-kernel, drbd-dev,
linux-block, greybus-dev, linuxppc-dev, linux-acpi, linux-fbdev,
dri-devel, linux-fsdevel, linux-nfs, ocfs2-devel, cgroups,
linux-modules, linux-pm, driver-core, bridge, netdev, keyrings,
linux-security-module
In-Reply-To: <20260708154510.6794-3-petr.pavlu@suse.com>
On Wed, Jul 08, 2026 at 05:44:30PM +0200, Petr Pavlu wrote:
> Including linux/kmod.h alone results in 1.5 MB of preprocessed output, even
> though it provides only a few functions and macros.
>
> The header currently depends on:
>
> * __printf() -> linux/compiler_attributes.h,
> * ENOSYS -> linux/errno.h,
> * bool -> linux/types.h.
>
> Include only these files, reducing the preprocessed output to 10 kB.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> include/linux/kmod.h | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index 9a07c3215389..b9474a62a568 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -2,17 +2,9 @@
> #ifndef __LINUX_KMOD_H__
> #define __LINUX_KMOD_H__
>
> -/*
> - * include/linux/kmod.h
> - */
> -
> -#include <linux/umh.h>
> -#include <linux/gfp.h>
> -#include <linux/stddef.h>
> +#include <linux/compiler_attributes.h>
> #include <linux/errno.h>
> -#include <linux/compiler.h>
> -#include <linux/workqueue.h>
> -#include <linux/sysctl.h>
> +#include <linux/types.h>
>
> #ifdef CONFIG_MODULES
> /* modprobe exit status on success, -ve on error. Return value
> --
> 2.54.0
>
LGTM. Thank you.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH net 1/2] net: macb: reprogram TBQP after shuffling the TX ring on link-up
From: Théo Lebrun @ 2026-07-10 13:56 UTC (permalink / raw)
To: Kevin Hao, Taedcke, Christian
Cc: christian.taedcke, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
Robert Hancock, netdev, linux-kernel, linux-rt-devel, stable
In-Reply-To: <ak2-XJHVc3Cg6ZEk@xiaowei>
Hello Kevin & Christian,
On Wed Jul 8, 2026 at 5:05 AM CEST, Kevin Hao wrote:
>> I agree that the TRM says the transmit pointer is reset while TE is low. My
>> question is whether this describes an internal pointer being reloaded from TBQP,
>> or whether TBQP itself is restored to the original ring base.
>
> The Zynq UltraScale TRM [1] describes the receive-buffer queue pointer as follows:
>
> An internal counter represents the receive-buffer queue pointer and it is not
> visible through the CPU interface.
>
> I could not find a similar description for the transmit-buffer queue pointer,
> but I believe it behaves the same way. From a software perspective, it should
> be safe to assume that the TBQP is reset to point to the start of the transmit
> descriptor list upon reset. This assumption is supported by the description
> of the transmit_q_ptr (GEM) Register [2]:
>
> Reading this register returns the location of the descriptor currently being accessed.
> Since the DMA handles two frames at once, this may not necessarily be pointing to the
> current frame being transmitted.
>
> [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
> [2] https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/transmit_q_ptr-GEM-Register
For what it's worth, I agree with Kevin.
It should be rather easy to detect if the patch is needed, with more
logging. Dump TBQP before link-down & dump it at link-up. The code
expects TBQP to reset to the ring start automatically whereas this
commit message says the TBQP after link-up is some offset into the ring.
Lastly, the cover letter mentions that [PATCH 1/2] alone isn't enough.
But it doesn't mention that [PATCH 2/2] alone doesn't solve the issue.
This would be a useful test as well.
On Tue Jul 7, 2026 at 3:36 PM CEST, Taedcke, Christian wrote:
> Thank you for the quick review! This is my first Linux kernel
> contribution, so I appreciate your feedback here.
Welcome!
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net] nfc: llcp: bound the remaining LLCP TLV parsers to their buffers
From: Simon Horman @ 2026-07-10 13:48 UTC (permalink / raw)
To: doruk
Cc: Simon Horman, david, oe-linux-nfc, david.laight.linux, netdev,
linux-kernel, stable
In-Reply-To: <20260705115607.60844-1-doruk@0sec.ai>
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/
---
nfc: llcp: bound the remaining LLCP TLV parsers to their buffers
The commit adds pointer-based bounds to nfc_llcp_parse_gb_tlv(),
nfc_llcp_parse_connection_tlv() and nfc_llcp_connect_sn(), replacing
the previous u8 offset walk which could wrap and produce an unbounded
TLV loop. It cites the size_t underflow of "skb->len - LLCP_HEADER_SIZE"
as one of the failure modes it wants to close.
> diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
> index 291f26facbf3..1a0a2f4aca70 100644
> --- a/net/nfc/llcp_commands.c
> +++ b/net/nfc/llcp_commands.c
[ ... ]
> @@ -243,17 +246,21 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock *sock,
> const u8 *tlv_array, u16 tlv_array_len)
> {
> const u8 *tlv = tlv_array;
> - u8 type, length, offset = 0;
> + const u8 *tlv_end = tlv_array + tlv_array_len;
> + u8 type, length;
>
> pr_debug("TLV array length %d\n", tlv_array_len);
>
> if (sock == NULL)
> return -ENOTCONN;
>
> - while (offset < tlv_array_len) {
> + while (tlv + 2 < tlv_end) {
> type = tlv[0];
> length = tlv[1];
>
> + if (tlv + 2 + length > tlv_end)
> + break;
> +
[High]
Is the size_t underflow the commit message mentions actually addressed
for nfc_llcp_parse_connection_tlv()?
The two callers, nfc_llcp_recv_connect() and nfc_llcp_recv_cc() in
net/nfc/llcp_core.c, still compute the length at the call site as
skb->len - LLCP_HEADER_SIZE and hand it to the parser:
nfc_llcp_parse_connection_tlv(new_sock, &skb->data[LLCP_HEADER_SIZE],
skb->len - LLCP_HEADER_SIZE);
and
nfc_llcp_parse_connection_tlv(llcp_sock, &skb->data[LLCP_HEADER_SIZE],
skb->len - LLCP_HEADER_SIZE);
If skb->len is 0 or 1, that subtraction (size_t at the call site,
truncated to the u16 tlv_array_len parameter) becomes 0xFFFE or 0xFFFF.
Inside the parser, that value now feeds:
const u8 *tlv_end = tlv_array + tlv_array_len;
while (tlv + 2 < tlv_end) {
...
if (tlv + 2 + length > tlv_end)
break;
so tlv_end points roughly 64 KiB past &skb->data[LLCP_HEADER_SIZE] and
neither the loop condition nor the per-TLV check catches the walk
leaving the skb.
The commit message calls this out as one of the motivations:
"Dropping the u8 offset also removes the wrap, and for very short
connect frames this avoids the size_t underflow of
'skb->len - LLCP_HEADER_SIZE'."
That mitigation is applied inside nfc_llcp_connect_sn() by using
skb_tail_pointer(skb) directly, but the equivalent change is not made
for the connection TLV path. nfc_llcp_rx_skb() has no minimum-length
guard, so a received CONNECT or CC PDU with skb->len < LLCP_HEADER_SIZE
still reaches these callers.
Would it make sense to either guard skb->len >= LLCP_HEADER_SIZE
before the two call sites, or take the same skb_tail_pointer() based
approach used in nfc_llcp_connect_sn() so the parser derives its bound
from the skb rather than from an untrusted subtraction?
> diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
> index dc65c719f35f..5e1881199238 100644
> --- a/net/nfc/llcp_core.c
> +++ b/net/nfc/llcp_core.c
> @@ -849,13 +849,16 @@ static struct nfc_llcp_sock *nfc_llcp_sock_get_sn(struct nfc_llcp_local *local,
> static const u8 *nfc_llcp_connect_sn(const struct sk_buff *skb, size_t *sn_len)
> {
> u8 type, length;
> - const u8 *tlv = &skb->data[2];
> - size_t tlv_array_len = skb->len - LLCP_HEADER_SIZE, offset = 0;
> + const u8 *tlv = &skb->data[LLCP_HEADER_SIZE];
> + const u8 *tlv_end = skb_tail_pointer(skb);
>
> - while (offset < tlv_array_len) {
> + while (tlv + 2 < tlv_end) {
^ permalink raw reply
* Re: [PATCH v4] r8169: migrate Rx path to page_pool, prepare for XDP
From: Atharva Potdar @ 2026-07-10 13:48 UTC (permalink / raw)
To: Simon Horman
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, romieu, netdev
In-Reply-To: <20260709170151.1577992-2-horms@kernel.org>
Hi Simon,
Thanks for the review. v5 addresses all three points:
- Introduced tp->rx_buf_sz to fix the DMA overflow and skb_put() panic.
- Fixed rtl8169_rx_clear() to iterate all NUM_RX_DESC entries.
- Fixed rtl_reset_work() to repopulate NULL slots before re-arming.
Will send v5 as a new thread.
Atharva
^ permalink raw reply
* Re: [PATCH bpf] bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
From: Jose Fernandez (Anthropic) @ 2026-07-10 13:44 UTC (permalink / raw)
To: Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrii Nakryiko,
Yonghong Song, Martin KaFai Lau, Jiayuan Chen, Emil Tsalapatis
Cc: netdev, linux-kernel, bpf, Ben Cressey
In-Reply-To: <20260620-bpf-iter-tcp-refcnt-v1-1-883bf9e69495@linux.dev>
Hi all,
Gentle ping. This has Reviewed-by from Jiayuan Chen and Emil Tsalapatis
and no outstanding objections since Jun 29. Is anything else needed for
bpf-fixes?
On the automated review's flag about the pre-existing double-put on the
bpf_iter_tcp_realloc_batch() failure path (cur_sk/end_sk not reset
before seq_stop, so cookies can be re-put as pointers): agreed it is
real, and it predates this change. As Jiayuan noted, it is a separate,
pre-existing issue best addressed on its own; I kept this patch minimal
for stable.
Thanks,
Jose
^ permalink raw reply
* [PATCH net-next v9 9/9] selftests: net: Add a test for BIG TCP in UDP tunnels
From: Alice Mikityanska @ 2026-07-10 13:42 UTC (permalink / raw)
To: Daniel Borkmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Xin Long, Willem de Bruijn, Willem de Bruijn,
David Ahern, Nikolay Aleksandrov
Cc: Shuah Khan, Stanislav Fomichev, Andrew Lunn, Simon Horman,
Florian Westphal, netdev, Alice Mikityanska
In-Reply-To: <20260710134242.216538-1-alice.kernel@fastmail.im>
From: Alice Mikityanska <alice@isovalent.com>
The test sets up VXLAN and GENEVE tunnels over IPv4 and IPv6 and runs
IPv4 and IPv6 traffic through them with BIG TCP enabled. It checks that
a non-negligible amount of big aggregated packets are seen by setting up
iptables counters.
Check the number of packets on both TX and RX sides to verify that GSO
packets are valid and not dropped. Capture on the lower netdev (veth),
when checksum offload is on, to verify that encapsulated BIG TCP packets
can get to their destination. In the test with TX checksum offload off,
software GSO splits aggregated VXLAN packets before passing them to
veth, so capture inside the tunnel instead to check that the big packets
are not dropped.
Check that the amount of SACKs is negligible. On unsupported kernels,
some amount of broken GSO packets bigger than 65536 bytes can be
produced in VXLAN tunnels, but they don't reach the destination. Seeing
TCP SACKs is a sign that such packets could have been dropped (in such
cases, the amount of SACKs is a few times bigger than the number of
attempts to send BIG TCP packets).
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
---
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/big_tcp_tunnels.sh | 188 ++++++++++++++++++
2 files changed, 189 insertions(+)
create mode 100755 tools/testing/selftests/net/big_tcp_tunnels.sh
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 708d960ae07d..4cb0a0bc1eea 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -13,6 +13,7 @@ TEST_PROGS := \
arp_ndisc_untracked_subnets.sh \
bareudp.sh \
big_tcp.sh \
+ big_tcp_tunnels.sh \
bind_bhash.sh \
bpf_offload.py \
bridge_stp_mode.sh \
diff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh
new file mode 100755
index 000000000000..d6513ed8d4e8
--- /dev/null
+++ b/tools/testing/selftests/net/big_tcp_tunnels.sh
@@ -0,0 +1,188 @@
+#!/usr/bin/env bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels.
+
+SERVER_NS=$(mktemp -u server-XXXXXXXX)
+SERVER_IP4="192.168.1.1"
+SERVER_IP6="2001:db8::1:1"
+SERVER_IP4_TUN="192.168.2.1"
+SERVER_IP6_TUN="2001:db8::2:1"
+
+CLIENT_NS=$(mktemp -u client-XXXXXXXX)
+CLIENT_IP4="192.168.1.2"
+CLIENT_IP6="2001:db8::1:2"
+CLIENT_IP4_TUN="192.168.2.2"
+CLIENT_IP6_TUN="2001:db8::2:2"
+
+: "${PACKETS_THRESHOLD:=1000}"
+
+# Kselftest framework requirement - SKIP code is 4.
+ksft_skip=4
+
+setup() {
+ ip netns add "$SERVER_NS"
+ ip netns add "$CLIENT_NS"
+ ip -netns "$SERVER_NS" link add link1 type veth peer name link0 netns "$CLIENT_NS"
+
+ ip -netns "$CLIENT_NS" link set link0 up
+ ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4/24" dev link0
+ ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6/112" dev link0 nodad
+ ip -netns "$CLIENT_NS" link set link0 \
+ gso_max_size 196608 gso_ipv4_max_size 196608 \
+ gro_max_size 196608 gro_ipv4_max_size 196608
+ ip -netns "$SERVER_NS" link set link1 up
+ ip -netns "$SERVER_NS" addr replace "$SERVER_IP4/24" dev link1
+ ip -netns "$SERVER_NS" addr replace "$SERVER_IP6/112" dev link1 nodad
+ ip -netns "$SERVER_NS" link set link1 \
+ gso_max_size 196608 gso_ipv4_max_size 196608 \
+ gro_max_size 196608 gro_ipv4_max_size 196608
+
+ ip netns exec "$SERVER_NS" netserver >/dev/null
+}
+
+setup_tunnel() {
+ if [ "$2" = 4 ]; then
+ SERVER_IP="$SERVER_IP4"
+ CLIENT_IP="$CLIENT_IP4"
+ echo "Setting up ${1^^} over IPv4, veth tx csum offload $3"
+ else
+ SERVER_IP="$SERVER_IP6"
+ CLIENT_IP="$CLIENT_IP6"
+ echo "Setting up ${1^^} over IPv6, veth tx csum offload $3"
+ fi
+
+ if [ "$1" = vxlan ]; then
+ ip -netns "$CLIENT_NS" link add tun0 type vxlan \
+ id 5001 remote "$SERVER_IP" local "$CLIENT_IP" dev link0 dstport 4789
+ else
+ ip -netns "$CLIENT_NS" link add tun0 type geneve \
+ id 5001 remote "$SERVER_IP"
+ fi
+ ip -netns "$CLIENT_NS" link set tun0 up
+ ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4_TUN/24" dev tun0
+ ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6_TUN/112" dev tun0 nodad
+ ip -netns "$CLIENT_NS" link set tun0 \
+ gso_max_size 196608 gso_ipv4_max_size 196608 \
+ gro_max_size 196608 gro_ipv4_max_size 196608
+ if [ "$1" = vxlan ]; then
+ ip -netns "$SERVER_NS" link add tun1 type vxlan \
+ id 5001 remote "$CLIENT_IP" local "$SERVER_IP" dev link1 dstport 4789
+ else
+ ip -netns "$SERVER_NS" link add tun1 type geneve \
+ id 5001 remote "$CLIENT_IP"
+ fi
+ ip -netns "$SERVER_NS" link set tun1 up
+ ip -netns "$SERVER_NS" addr replace "$SERVER_IP4_TUN/24" dev tun1
+ ip -netns "$SERVER_NS" addr replace "$SERVER_IP6_TUN/112" dev tun1 nodad
+ ip -netns "$SERVER_NS" link set tun1 \
+ gso_max_size 196608 gso_ipv4_max_size 196608 \
+ gro_max_size 196608 gro_ipv4_max_size 196608
+
+ ip netns exec "$CLIENT_NS" ethtool -K link0 tx-checksumming "$3" > /dev/null
+ ip netns exec "$SERVER_NS" ethtool -K link1 tx-checksumming "$3" > /dev/null
+}
+
+cleanup_tunnel() {
+ ip -netns "$CLIENT_NS" link del tun0
+ ip -netns "$SERVER_NS" link del tun1
+}
+
+cleanup() {
+ ip netns pids "$SERVER_NS" | xargs -r kill
+ ip netns pids "$CLIENT_NS" | xargs -r kill
+ ip netns del "$SERVER_NS"
+ ip netns del "$CLIENT_NS"
+ rm -rf "$WORKDIR"
+}
+
+do_test() {
+ # When tx csum offload is off, software GSO is performed before passing the
+ # packet to veth. Check BIG TCP packets inside the VXLAN tunnel to verify
+ # the software checksum path: if the checksum code is broken, these packets
+ # will be dropped.
+ if [ "$3" = on ]; then
+ CAPTURE_IFACE='link'
+ if [ "$1" = 4 ]; then
+ IPTABLES=iptables
+ else
+ IPTABLES=ip6tables
+ fi
+ else
+ CAPTURE_IFACE='tun'
+ if [ "$2" = 4 ]; then
+ IPTABLES=iptables
+ else
+ IPTABLES=ip6tables
+ fi
+ fi
+ if [ "$2" = 4 ]; then
+ IPTABLES_SACK=iptables
+ else
+ IPTABLES_SACK=ip6tables
+ fi
+
+ ip netns exec "$SERVER_NS" "$IPTABLES" -w -t raw -I PREROUTING -i "${CAPTURE_IFACE}1" -m length ! --length 0:65535 -m comment --comment "bigtcp"
+ ip netns exec "$CLIENT_NS" "$IPTABLES" -w -t raw -I OUTPUT -o "${CAPTURE_IFACE}0" -m length ! --length 0:65535 -m comment --comment "bigtcp"
+ ip netns exec "$SERVER_NS" "$IPTABLES_SACK" -w -t raw -I OUTPUT -o "tun1" -p tcp -m tcp --tcp-flags ACK ACK --tcp-option 5 -m comment --comment "sack"
+
+ if [ "$2" = 4 ]; then
+ SERVER_IP="$SERVER_IP4_TUN"
+ echo "Running IPv4 traffic in the tunnel"
+ else
+ SERVER_IP="$SERVER_IP6_TUN"
+ echo "Running IPv6 traffic in the tunnel"
+ fi
+
+ ip netns exec "$CLIENT_NS" netperf -t TCP_STREAM -l 5 -H "$SERVER_IP" -- \
+ -m 80000 > /dev/null
+
+ PACKETS_SERVER=$(ip netns exec "$SERVER_NS" "$IPTABLES-save" -c -t raw | sed -rn '/ --comment bigtcp/{s/^\[([0-9]+):.*/\1/p;q}')
+ PACKETS_CLIENT=$(ip netns exec "$CLIENT_NS" "$IPTABLES-save" -c -t raw | sed -rn '/ --comment bigtcp/{s/^\[([0-9]+):.*/\1/p;q}')
+ PACKETS_SACK=$(ip netns exec "$SERVER_NS" "$IPTABLES_SACK-save" -c -t raw | sed -rn '/ --comment sack/{s/^\[([0-9]+):.*/\1/p;q}')
+ ip netns exec "$SERVER_NS" "$IPTABLES" -w -t raw -D PREROUTING -i "${CAPTURE_IFACE}1" -m length ! --length 0:65535 -m comment --comment "bigtcp"
+ ip netns exec "$CLIENT_NS" "$IPTABLES" -w -t raw -D OUTPUT -o "${CAPTURE_IFACE}0" -m length ! --length 0:65535 -m comment --comment "bigtcp"
+ ip netns exec "$SERVER_NS" "$IPTABLES_SACK" -w -t raw -D OUTPUT -o "tun1" -p tcp -m tcp --tcp-flags ACK ACK --tcp-option 5 -m comment --comment "sack"
+
+ echo "Captured BIG TCP RX packets: $PACKETS_SERVER"
+ echo "Captured BIG TCP TX packets: $PACKETS_CLIENT"
+ echo "Captured TCP SACK packets: $PACKETS_SACK"
+ [ "$PACKETS_SERVER" -gt "$PACKETS_THRESHOLD" ] || return 1
+ [ "$PACKETS_CLIENT" -gt "$PACKETS_THRESHOLD" ] || return 1
+ [ "$PACKETS_SACK" -lt "$(( PACKETS_CLIENT / 2 ))" ] || return 1
+}
+
+if ! netperf -V &> /dev/null; then
+ echo "SKIP: Could not run test without netperf tool"
+ exit "$ksft_skip"
+fi
+
+if ! iptables --version &> /dev/null; then
+ echo "SKIP: Could not run test without iptables tool"
+ exit "$ksft_skip"
+fi
+
+if ! ethtool --version &> /dev/null; then
+ echo "SKIP: Could not run test without ethtool tool"
+ exit "$ksft_skip"
+fi
+
+if ! ip link help 2>&1 | grep gso_ipv4_max_size &> /dev/null; then
+ echo "SKIP: Could not run test without gso/gro_ipv4_max_size supported in ip-link"
+ exit "$ksft_skip"
+fi
+
+WORKDIR=$(mktemp -d)
+trap cleanup EXIT
+setup
+for tunnel in vxlan geneve; do
+ for tun_family in 4 6; do
+ for traffic_family in 4 6; do
+ for csum_offload in on off; do
+ setup_tunnel "$tunnel" "$tun_family" "$csum_offload" || exit "$?"
+ do_test "$tun_family" "$traffic_family" "$csum_offload" || exit "$?"
+ cleanup_tunnel
+ done
+ done
+ done
+done
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v9 8/9] geneve: Enable BIG TCP packets
From: Alice Mikityanska @ 2026-07-10 13:42 UTC (permalink / raw)
To: Daniel Borkmann, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Xin Long, Willem de Bruijn, Willem de Bruijn,
David Ahern, Nikolay Aleksandrov
Cc: Shuah Khan, Stanislav Fomichev, Andrew Lunn, Simon Horman,
Florian Westphal, netdev, Alice Mikityanska
In-Reply-To: <20260710134242.216538-1-alice.kernel@fastmail.im>
From: Alice Mikityanska <alice@isovalent.com>
From: Daniel Borkmann <daniel@iogearbox.net>
In Cilium we do support BIG TCP, but so far the latter has only been
enabled for direct routing use-cases. A lot of users rely on Cilium
with vxlan/geneve tunneling though. The underlying kernel infra for
tunneling has not been supporting BIG TCP up to this point.
Given we do now, bump tso_max_size for geneve netdevs up to GSO_MAX_SIZE
to allow the admin to use BIG TCP with geneve tunnels.
BIG TCP on geneve disabled:
Standard MTU:
# netperf -H 10.1.0.2 -t TCP_STREAM -l60
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.0.2 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 30.00 37391.34
8k MTU:
# netperf -H 10.1.0.2 -t TCP_STREAM -l60
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.0.2 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
262144 32768 32768 60.00 58030.19
BIG TCP on geneve enabled:
Standard MTU:
# netperf -H 10.1.0.2 -t TCP_STREAM -l60
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.0.2 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 30.00 40891.57
8k MTU:
# netperf -H 10.1.0.2 -t TCP_STREAM -l60
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.0.2 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
262144 32768 32768 60.00 61458.39
Example receive side:
swapper 0 [008] 3682.509996: net:netif_receive_skb: dev=geneve0 skbaddr=0xffff8f3b0a781800 len=129492
ffffffff8cfe3aaa __netif_receive_skb_core.constprop.0+0x6ca ([kernel.kallsyms])
ffffffff8cfe3aaa __netif_receive_skb_core.constprop.0+0x6ca ([kernel.kallsyms])
ffffffff8cfe47dd __netif_receive_skb_list_core+0xed ([kernel.kallsyms])
ffffffff8cfe4e52 netif_receive_skb_list_internal+0x1d2 ([kernel.kallsyms])
ffffffff8cfe573c napi_complete_done+0x7c ([kernel.kallsyms])
ffffffff8d046c23 gro_cell_poll+0x83 ([kernel.kallsyms])
ffffffff8cfe586d __napi_poll+0x2d ([kernel.kallsyms])
ffffffff8cfe5f8d net_rx_action+0x20d ([kernel.kallsyms])
ffffffff8c35d252 handle_softirqs+0xe2 ([kernel.kallsyms])
ffffffff8c35d556 __irq_exit_rcu+0xd6 ([kernel.kallsyms])
ffffffff8c35d81e irq_exit_rcu+0xe ([kernel.kallsyms])
ffffffff8d2602b8 common_interrupt+0x98 ([kernel.kallsyms])
ffffffff8c000da7 asm_common_interrupt+0x27 ([kernel.kallsyms])
ffffffff8d2645c5 cpuidle_enter_state+0xd5 ([kernel.kallsyms])
ffffffff8cf6358e cpuidle_enter+0x2e ([kernel.kallsyms])
ffffffff8c3ba932 call_cpuidle+0x22 ([kernel.kallsyms])
ffffffff8c3bfb5e do_idle+0x1ce ([kernel.kallsyms])
ffffffff8c3bfd79 cpu_startup_entry+0x29 ([kernel.kallsyms])
ffffffff8c30a6c2 start_secondary+0x112 ([kernel.kallsyms])
ffffffff8c2c142d common_startup_64+0x13e ([kernel.kallsyms])
Example transmit side:
swapper 0 [002] 3403.688687: net:net_dev_xmit: dev=enp10s0f0np0 skbaddr=0xffff8af31d104ae8 len=129556 rc=0
ffffffffa75e19c3 dev_hard_start_xmit+0x173 ([kernel.kallsyms])
ffffffffa75e19c3 dev_hard_start_xmit+0x173 ([kernel.kallsyms])
ffffffffa7653823 sch_direct_xmit+0x143 ([kernel.kallsyms])
ffffffffa75e2780 __dev_queue_xmit+0xc70 ([kernel.kallsyms])
ffffffffa76a1205 ip_finish_output2+0x265 ([kernel.kallsyms])
ffffffffa76a1577 __ip_finish_output+0x87 ([kernel.kallsyms])
ffffffffa76a165b ip_finish_output+0x2b ([kernel.kallsyms])
ffffffffa76a179e ip_output+0x5e ([kernel.kallsyms])
ffffffffa76a19d5 ip_local_out+0x35 ([kernel.kallsyms])
ffffffffa770d0e5 iptunnel_xmit+0x185 ([kernel.kallsyms])
ffffffffc179634e nf_nat_used_tuple_new.cold+0x1129 ([kernel.kallsyms])
ffffffffc179d3e0 geneve_xmit+0x920 ([kernel.kallsyms])
ffffffffa75e18af dev_hard_start_xmit+0x5f ([kernel.kallsyms])
ffffffffa75e1d3f __dev_queue_xmit+0x22f ([kernel.kallsyms])
ffffffffa76a1205 ip_finish_output2+0x265 ([kernel.kallsyms])
ffffffffa76a1577 __ip_finish_output+0x87 ([kernel.kallsyms])
ffffffffa76a165b ip_finish_output+0x2b ([kernel.kallsyms])
ffffffffa76a179e ip_output+0x5e ([kernel.kallsyms])
ffffffffa76a1de2 __ip_queue_xmit+0x1b2 ([kernel.kallsyms])
ffffffffa76a2135 ip_queue_xmit+0x15 ([kernel.kallsyms])
ffffffffa76c70a2 __tcp_transmit_skb+0x522 ([kernel.kallsyms])
ffffffffa76c931a tcp_write_xmit+0x65a ([kernel.kallsyms])
ffffffffa76ca3b9 __tcp_push_pending_frames+0x39 ([kernel.kallsyms])
ffffffffa76c1fb6 tcp_rcv_established+0x276 ([kernel.kallsyms])
ffffffffa76d3957 tcp_v4_do_rcv+0x157 ([kernel.kallsyms])
ffffffffa76d6053 tcp_v4_rcv+0x1243 ([kernel.kallsyms])
ffffffffa769b8ea ip_protocol_deliver_rcu+0x2a ([kernel.kallsyms])
ffffffffa769bab7 ip_local_deliver_finish+0x77 ([kernel.kallsyms])
ffffffffa769bb4d ip_local_deliver+0x6d ([kernel.kallsyms])
ffffffffa769abe7 ip_sublist_rcv_finish+0x37 ([kernel.kallsyms])
ffffffffa769b713 ip_sublist_rcv+0x173 ([kernel.kallsyms])
ffffffffa769bde2 ip_list_rcv+0x102 ([kernel.kallsyms])
ffffffffa75e4868 __netif_receive_skb_list_core+0x178 ([kernel.kallsyms])
ffffffffa75e4e52 netif_receive_skb_list_internal+0x1d2 ([kernel.kallsyms])
ffffffffa75e573c napi_complete_done+0x7c ([kernel.kallsyms])
ffffffffa7646c23 gro_cell_poll+0x83 ([kernel.kallsyms])
ffffffffa75e586d __napi_poll+0x2d ([kernel.kallsyms])
ffffffffa75e5f8d net_rx_action+0x20d ([kernel.kallsyms])
ffffffffa695d252 handle_softirqs+0xe2 ([kernel.kallsyms])
ffffffffa695d556 __irq_exit_rcu+0xd6 ([kernel.kallsyms])
ffffffffa695d81e irq_exit_rcu+0xe ([kernel.kallsyms])
ffffffffa78602b8 common_interrupt+0x98 ([kernel.kallsyms])
ffffffffa6600da7 asm_common_interrupt+0x27 ([kernel.kallsyms])
ffffffffa78645c5 cpuidle_enter_state+0xd5 ([kernel.kallsyms])
ffffffffa756358e cpuidle_enter+0x2e ([kernel.kallsyms])
ffffffffa69ba932 call_cpuidle+0x22 ([kernel.kallsyms])
ffffffffa69bfb5e do_idle+0x1ce ([kernel.kallsyms])
ffffffffa69bfd79 cpu_startup_entry+0x29 ([kernel.kallsyms])
ffffffffa690a6c2 start_secondary+0x112 ([kernel.kallsyms])
ffffffffa68c142d common_startup_64+0x13e ([kernel.kallsyms])
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Co-developed-by: Alice Mikityanska <alice@isovalent.com>
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Cc: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
---
drivers/net/geneve.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 011bf9d833ca..a1639ad53077 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1745,6 +1745,8 @@ static void geneve_setup(struct net_device *dev)
dev->max_mtu = IP_MAX_MTU - GENEVE_BASE_HLEN - dev->hard_header_len;
netif_keep_dst(dev);
+ netif_set_tso_max_size(dev, GSO_MAX_SIZE);
+
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE | IFF_NO_QUEUE;
dev->lltx = true;
--
2.54.0
^ permalink raw reply related
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