* Re: [PATCH v3 2/3] net/smc: bound the receive length to the RMB in smc_rx_recvmsg()
From: Dust Li @ 2026-06-19 3:31 UTC (permalink / raw)
To: Bryam Vargas
Cc: Wenjia Zhang, D . Wythe, Sidraya Jayagond, Eric Dumazet,
David S . Miller, Mahanta Jambigi, Wen Gu, Simon Horman,
Ursula Braun, Stefan Raspl, Tony Lu, Paolo Abeni, Jakub Kicinski,
netdev, linux-s390, linux-rdma, linux-kernel
In-Reply-To: <20260618221106.236699-1-hexlabsecurity@proton.me>
On 2026-06-18 22:11:12, Bryam Vargas wrote:
>On Fri, 19 Jun 2026 00:03:17 +0800, Dust Li wrote:
>> Once we validate the CDC message at the input boundary (as in the
>> previous patch), bytes_to_rcv can never exceed rmb_desc->len, so
>> this check becomes unreachable. So I don't think this patch is needed.
>
>This one I'd actually like to keep, and let me walk through why -- I don't think the
>boundary check closes it.
>
>bytes_to_rcv isn't set to a cursor count, it's a running accumulator:
>smc_cdc_msg_recv_action does atomic_add(diff_prod, &bytes_to_rcv), where
>diff_prod = smc_curs_diff(rmb_desc->len, old, new). So bounding each cursor's count at
>the boundary doesn't bound the sum of the deltas.
>
>The differing-wrap branch of smc_curs_diff returns (len - old.count) + new.count,
>which is up to 2*len-1 even when both cursors pass count <= len. With len=16, a prod
>going (0,0) -> (1,15) gives diff=31, so bytes_to_rcv is already 31 > len after one
>message; alternating wrap 0<->1 at count=15 keeps adding ~len and eventually wraps the
>atomic_t negative. I have an A/B for this -- happy to send it along.
Glad to see you A/B test, I think we can decide after we see the real
issue.
>
>So to make this truly unreachable from the boundary check, we'd need to bound
>prod - cons <= len there, not just the absolute count. The consumer-side clamp is two
>lines and race-free against the tasklet, so my preference would be to keep it as a
>backstop -- but if you'd rather fold it into a stronger boundary check instead, I'm
>open to that.
Another thing I'd worry about is if this really happens, should we also
abort the connection like what we did in patch #1 ?
Best regards,
Dust
^ permalink raw reply
* Re: [PATCH v3 1/3] net/smc: bound the wire-controlled producer cursor to the RMB
From: Dust Li @ 2026-06-19 3:26 UTC (permalink / raw)
To: Bryam Vargas
Cc: Wenjia Zhang, D . Wythe, Sidraya Jayagond, Eric Dumazet,
David S . Miller, Mahanta Jambigi, Wen Gu, Simon Horman,
Ursula Braun, Stefan Raspl, Tony Lu, Paolo Abeni, Jakub Kicinski,
netdev, linux-s390, linux-rdma, linux-kernel
In-Reply-To: <20260618221057.236673-1-hexlabsecurity@proton.me>
On 2026-06-18 22:11:05, Bryam Vargas wrote:
>On Thu, 18 Jun 2026 22:29:20 +0800, Dust Li wrote:
>> once we detect that the peer is misbehaving, I think the right action is
>> to abort the connection and record the event, rather than silently clamp.
>[...]
>> u32 prod_count = ntohs(cdc->prod.count);
>> ...
>> cdc->prod.wrap > 1 || cdc->cons.wrap > 1) {
>
>Thanks for taking a look, Dust. I'm on board with the direction for net-next --
>aborting and recording a bad CDC is cleaner than clamping something we already know
>we can't trust, and as you say, the clamp just papers over the peer bug. So: minimal
>clamp stays for -stable, and net-next gets the wire-boundary check + abort (through
>abort_work, with an smc_stats counter and a ratelimited warn).
That's greate. Then I think we can move on in this direction.
>
>A few things I ran into on the check itself, though:
>
>- count is __be32, so it wants ntohl() rather than ntohs() -- ntohs() ends up reading
> the wrong half.
Right
>
>- I'd drop the wrap > 1 tests. wrap is a free-running counter (smc_curs_add does
> wrap++), so a connection that legitimately wraps its RMB ends up with wrap > 1; and
> since it's a __be16 read raw, on little-endian wrap==1 already reads as 0x0100 and
> we'd abort on the very first wrap. I don't think there's a sane upper bound to put
> on wrap.
Agree
>
>- the check is typed for SMC-R, but the SMC-D path hands a host-order smcd_cdc_msg to
> smc_cdc_msg_recv() cast as smc_cdc_msg (smc_cdc.c:456), so ntohl/ntohs would
> double-swap it there. The simplest thing I found is one check on the host cursor
> right after smc_cdc_msg_to_host(), before the diff/atomic_add block -- that covers
> SMC-R and SMC-D in one place.
Agree
>
>Minor: >= len rather than > len (count is an offset in [0,len)), and peer_rmbe_size
>is signed so worth guarding. The cons vs peer_rmbe_size bound looks right to me.
No problem
Best regards,
Dust
^ permalink raw reply
* net: wwan: iosm: possible out of bounds read in the MUX downlink decoder
From: Maoyi Xie @ 2026-06-19 3:05 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg; +Cc: netdev, linux-kernel
Hi all,
I think mux_dl_adb_decode() in drivers/net/wwan/iosm/iosm_ipc_mux_codec.c can
read past the downlink buffer when the modem reports a large table index. I
would appreciate it if you could take a look.
The decoder takes the table offset straight from the device ADB header.
block = skb->data;
adbh = (struct mux_adbh *)block;
adth_index = le32_to_cpu(adbh->first_table_index);
if (adth_index < 1)
goto adb_decode_err;
...
adth = (struct mux_adth *)(block + adth_index);
first_table_index is a device le32 and the only check is that it is not
zero. After that adth points at block + adth_index with no upper bound and
the code reads adth->table_length and the datagram table from there. The
downlink buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE, 2048 bytes, so an index
past 2048 reads past the slab object.
mux_dl_process_dg() has the same issue further down. It reads
dg->datagram_index and dg->datagram_length per entry, bounded only by the
device block_length, which is itself never checked against skb->len.
The protocol layer below only caps the total transfer at the pipe buffer
size and skb_put()s it, so skb->len is at most 2048, but none of these
in band offsets and lengths are checked against it.
The data here comes from the modem, so it is device input we should not
trust, especially with an external or compromised PCIe baseband. It fires on
a normal downlink receive once the iosm net device is up.
I reproduced the adth_index read under KASAN on 7.1-rc7. With an index that
fits the buffer the read stays inside. With an index past the buffer KASAN
reports a slab out of bounds read past the downlink buffer.
The fix I have in mind validates every device offset and length against
skb->len before use, rejecting an adth_index that leaves no room for a
struct mux_adth and a datagram that runs past the buffer.
Does this look like a real bug to you? The aggregation decoder has moved
around over the years, so I am not certain of the exact introducing commit.
1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") is the
broadly cited landing point. I am happy to send a proper patch.
Thanks,
Maoyi
https://maoyixie.com/
^ permalink raw reply
* Re: [PATCH bpf v3 1/2] bpf, sockmap: fix use-after-free when the stream parser resizes the skb
From: Sechang Lim @ 2026-06-19 1:54 UTC (permalink / raw)
To: John Fastabend; +Cc: Jiayuan Chen, netdev, bpf, linux-kernel, Jakub Kicinski
In-Reply-To: <ajQwWe4SC1M7MtJa@john-p8>
On Thu, Jun 18, 2026 at 11:01:58AM -0700, John Fastabend wrote:
>On Thu, Jun 18, 2026 at 07:56:34PM +0800, Jiayuan Chen wrote:
>>
>>On 6/18/26 6:27 PM, Sechang Lim wrote:
>>>sk_psock_strp_parse() runs the BPF_PROG_TYPE_SK_SKB stream-parser program
>>>to find the length of the next message. strparser assembles a message out
>>>of several received skbs by chaining them onto the head's frag_list and
>>>recording where to append the next one in strp->skb_nextp:
>>>
>>> *strp->skb_nextp = skb;
>>> strp->skb_nextp = &skb->next;
>>>
>>>and then calls the parser on the head:
>>>
>>> len = (*strp->cb.parse_msg)(strp, head);
>>
>>[...]
>>
>>>unaffected and may still modify the skb.
>>>
>>>Fixes: 8a31db561566 ("bpf: add access to sock fields and pkt data from sk_skb programs")
>>
>>Is the Fixes tag correct ?
>>
>>Anyway, I don't think this patch is a fix; it's more of a hardening.
>>So no Fixes tag needed, IMO.
Thanks for your review, dropping the Fixes tag in v4.
>>
>>
>>>Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
>>>---
>
>[...]
>
>>
>>
>>CI failed:
>>https://github.com/kernel-patches/bpf/actions/runs/27754218839/job/82113319982
>> Failed stream parser bpf prog attach
>>
>>Hi John
>>I noticed that bpf_skb_pull_data was added to the skmsg test:
>>https://github.com/torvalds/linux/commit/82a8616889d506cb690cfc0afb2ccadda120461d
>>
>>Can we drop bpf_skb_pull_data in parser prog(sockmap_parse_prog.c) ?
>>And are there any scenarios where we need to modify skb len when
>>using strparser ?
>
>We should never modify the skb from strparser. Just remove any tests
>that do this and state its not safe. We haven't used strparser progs
>for a long time anyways.
Thanks for your review. Will do in v4.
Best,
Sechang
^ permalink raw reply
* Re: [PATCH net v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
From: patchwork-bot+netdevbpf @ 2026-06-19 1:40 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: jmaloy, davem, edumazet, kuba, pabeni, horms, aleksander.lobakin,
tung.quang.nguyen, tipc-discussion, netdev, linux-kernel, stable
In-Reply-To: <20260617075818.37431-1-doruk@0sec.ai>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 09:58:18 +0200 you wrote:
> 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->crypto->aead[] and the node table -- reading freed memory.
>
> [...]
Here is the summary with links:
- [net,v4] tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done
https://git.kernel.org/netdev/net/c/bda3348872a2
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-next v2] net: rds: check cmsg_len before reading rds_rdma_args in size pass
From: patchwork-bot+netdevbpf @ 2026-06-19 1:40 UTC (permalink / raw)
To: Michael Bommarito
Cc: achender, davem, kuba, pabeni, edumazet, horms, netdev,
linux-rdma, rds-devel, linux-kernel
In-Reply-To: <20260617023146.2780077-1-michael.bommarito@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 22:31:46 -0400 you wrote:
> rds_rm_size() handles RDS_CMSG_RDMA_ARGS after only CMSG_OK() and then
> calls rds_rdma_extra_size(), which reads args->local_vec_addr and
> args->nr_local without first checking that cmsg_len covers struct
> rds_rdma_args. The other two RDS_CMSG_RDMA_ARGS consumers already guard
> this: rds_rdma_bytes() in rds_sendmsg() and rds_cmsg_rdma_args() in
> rds_cmsg_send() both reject cmsg_len < CMSG_LEN(sizeof(struct
> rds_rdma_args)). Add the same check to rds_rm_size() so all three RDMA
> args passes are consistent.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: rds: check cmsg_len before reading rds_rdma_args in size pass
https://git.kernel.org/netdev/net/c/e5c00023270e
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] eth: fbnic: take netif_addr_lock_bh() around rx mode address programming
From: patchwork-bot+netdevbpf @ 2026-06-19 1:40 UTC (permalink / raw)
To: Daniel Zahka
Cc: alexanderduyck, kuba, kernel-team, andrew+netdev, davem, edumazet,
pabeni, sanmanpradhan, netdev, linux-kernel
In-Reply-To: <20260617-linux-fbnic-hwaddr-v1-1-3f9f5dee7f99@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 03:39:49 -0700 you wrote:
> When __fbnic_set_rx_mode() is called from contexts other than
> .ndo_set_rx_mode_async(), the uc and mc addr lists are accessed
> without the addr lock that __hw_addr_sync_dev() and
> __hw_addr_unsync_dev() require. Wrap these unprotected accesses with
> netif_addr_lock_bh(). fbnic_clear_rx_mode() has similar issues.
>
> Fixes: eb690ef8d1c2 ("eth: fbnic: Add L2 address programming")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
>
> [...]
Here is the summary with links:
- [net] eth: fbnic: take netif_addr_lock_bh() around rx mode address programming
https://git.kernel.org/netdev/net/c/96e7f9122aae
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC PATCH 1/2] landlock: fix TCP Fast Open connection bypass
From: Bryam Vargas @ 2026-06-19 1:39 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Mickaël Salaün, Günther Noack, Mikhail Ivanov,
Paul Moore, Eric Dumazet, Neal Cardwell, linux-security-module,
netdev, linux-kernel
In-Reply-To: <e0c7b502-931e-481e-89b0-b47687d2b942@buffet.re>
Thanks, that settles it: MPTCP is out of scope by design, not a gap.
I read 854277e2cc8c ("landlock: Fix non-TCP sockets restriction"). It
changed the sock->type != SOCK_STREAM test to !sk_is_tcp(sock->sk),
dropping SMC/MPTCP/SCTP from the TCP rights on purpose, and 3d4033985ff5
pins that with a "MPTCP actions are not restricted" selftest. So my
"|| sk_protocol == IPPROTO_MPTCP" suggestion was wrong: it would revert
that decision and break the selftest. Please disregard it.
That leaves the series complete as-is on this axis. Keeping both the v0
guard and the 2/2 selftest sk_is_tcp()-only is correct, and the
Tested-by stands for the TCP and IPv6 fast-open path the patch fixes.
Bryam
^ permalink raw reply
* Re: [PATCH v2 0/1] selftests: net: fix file owner for broadcast_ether_dst test
From: patchwork-bot+netdevbpf @ 2026-06-19 1:30 UTC (permalink / raw)
To: Ross Porter
Cc: linux-kselftest, netdev, davem, edumazet, kuba, pabeni, horms,
shuah, oscmaes92, bacs, linux-kernel
In-Reply-To: <20260617061039.79717-1-ross.porter@canonical.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 18:10:38 +1200 you wrote:
> The broadcast_ether_dst test can spuriously fail due to file
> permissions, depending on which flags tcpdump is compiled with: If
> tcpdump is compiled with the `--with-user` flag then tcpdump will
> step down to the provided user after opening the device. In this
> case the test fails due to permission issues, as the output file
> is owned by a different user.
> Debian ships tcpdump with this flag enabled, so this bug
> appears as part of our kernel testing.
>
> [...]
Here is the summary with links:
- [v2,1/1] selftests: net: fix file owner for broadcast_ether_dst test
https://git.kernel.org/netdev/net/c/b8613e979200
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-next v1] net: wangxun: don't advertise IFF_SUPP_NOFCS
From: patchwork-bot+netdevbpf @ 2026-06-19 1:30 UTC (permalink / raw)
To: Rongguang Wei; +Cc: netdev, jiawenwu, mengyuanlou, pabeni, kuba, weirongguang
In-Reply-To: <20260617092854.133992-1-clementwei90@163.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 17:28:54 +0800 you wrote:
> From: Rongguang Wei <weirongguang@kylinos.cn>
>
> Like commit a24162f18825("i40e: don't advertise IFF_SUPP_NOFCS"),
> ngbe and txgbe also advertises IFF_SUPP_NOFCS and allowing users
> to use the SO_NOFCS socket option. But the driver does not check
> skb->no_fcs, so this option is silently ignored.
>
> [...]
Here is the summary with links:
- [net-next,v1] net: wangxun: don't advertise IFF_SUPP_NOFCS
https://git.kernel.org/netdev/net/c/0ec4b7859870
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] gve: fix header buffer corruption with header-split and HW-GRO
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Joshua Washington
Cc: netdev, hramamurthy, andrew+netdev, davem, edumazet, kuba, pabeni,
willemb, thostet, ziweixiao, pkaligineedi, jeroendb, linux-kernel,
nktgrg, stable, jordanrhee
In-Reply-To: <20260617013208.3781453-1-joshwash@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 18:32:08 -0700 you wrote:
> From: Ankit Garg <nktgrg@google.com>
>
> The DQO RX datapath programs a per-buffer-queue-descriptor
> header_buf_addr at post time and reads the split header back at
> completion time. Both the post and the read currently index the
> header buffer by queue position rather than by the buffer's identity:
>
> [...]
Here is the summary with links:
- [net] gve: fix header buffer corruption with header-split and HW-GRO
https://git.kernel.org/netdev/net/c/d676c9a73bdc
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] net: ena: clean up XDP TX queues when regular TX setup fails
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Dawei Feng
Cc: akiyano, darinzon, andrew+netdev, davem, edumazet, kuba, pabeni,
ast, daniel, hawk, john.fastabend, sdf, sameehj, netdev,
linux-kernel, bpf, jianhao.xu, stable
In-Reply-To: <20260616142424.4005130-1-dawei.feng@seu.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 22:24:24 +0800 you wrote:
> create_queues_with_size_backoff() creates XDP TX queues before setting
> up the regular TX path. If the subsequent allocation or creation of
> regular TX queues fails, the error handling paths omit the teardown of the
> XDP TX queues, leading to a resource leak.
>
> Fix this by explicitly destroying the XDP TX queue subset at the two
> missing failure points.
>
> [...]
Here is the summary with links:
- [net] net: ena: clean up XDP TX queues when regular TX setup fails
https://git.kernel.org/netdev/net/c/1bd6676254b4
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] selftests: vlan_bridge_binding: Fix flaky operational state check
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, kuba, pabeni, edumazet, petrm, horms, razor
In-Reply-To: <20260617104323.1069457-1-idosch@nvidia.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 13:43:23 +0300 you wrote:
> check_operstate() busy waits for up to one second for the operational
> state to change to the expected state. This is not enough since carrier
> loss events can be delayed by the kernel for up to one second (see
> __linkwatch_run_queue()), leading to sporadic failures.
>
> Fix by increasing the busy wait period to two seconds.
>
> [...]
Here is the summary with links:
- [net] selftests: vlan_bridge_binding: Fix flaky operational state check
https://git.kernel.org/netdev/net/c/4045f1c3d68e
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] net: thunderbolt: Fix frags[] overflow by bounding frame_count
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Maoyi Xie
Cc: mika.westerberg, YehezkelShB, andrew+netdev, kuba, pabeni, davem,
edumazet, netdev, linux-kernel
In-Reply-To: <178163152194.2486768.14724194232649760778@maoyixie.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 01:38:41 +0800 you wrote:
> tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The
> first frame goes into the skb linear area and every further frame is added as
> a page fragment.
>
> skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
> page, hdr_size, frame_size,
> TBNET_RX_PAGE_SIZE - hdr_size);
>
> [...]
Here is the summary with links:
- [net] net: thunderbolt: Fix frags[] overflow by bounding frame_count
https://git.kernel.org/netdev/net/c/55d9895f8997
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 v4] flow_dissector: check device type before reading ETH_ADDRS
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Zhou, Yun
Cc: davem, edumazet, kuba, pabeni, horms, netdev, linux-kernel,
qingfang.deng
In-Reply-To: <20260616123057.482154-1-yun.zhou@windriver.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 20:30:57 +0800 you wrote:
> __skb_flow_dissect() unconditionally reads 12 bytes from eth_hdr(skb)
> when FLOW_DISSECTOR_KEY_ETH_ADDRS is requested. This assumes the skb
> has a valid Ethernet header at mac_header, which is not always the case.
>
> The problem can be triggered by:
> 1. Creating a TUN device in L3 mode (IFF_TUN, hard_header_len=0)
> 2. Attaching a multiq qdisc with a flower filter matching on eth_src
> 3. Sending a packet through AF_PACKET
>
> [...]
Here is the summary with links:
- [v4] flow_dissector: check device type before reading ETH_ADDRS
https://git.kernel.org/netdev/net/c/bf6e8af2c8be
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] netconsole: don't drop the last byte of a full-sized message
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Breno Leitao
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, asantostc, gustavold, kernel-team
In-Reply-To: <20260616-max_print_chunk-v1-1-8dc125d67083@debian.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 09:09:52 -0700 you wrote:
> nt->buf is exactly MAX_PRINT_CHUNK bytes, but scnprintf() reserves one
> byte for its NUL terminator, so a non-fragmented payload of exactly
> MAX_PRINT_CHUNK loses its last byte (emitted as a stray NUL in the
> release path). Grow nt->buf to MAX_PRINT_CHUNK + 1 and bound the
> scnprintf() calls with sizeof(nt->buf); the transmitted length stays
> capped at MAX_PRINT_CHUNK.
>
> [...]
Here is the summary with links:
- [net] netconsole: don't drop the last byte of a full-sized message
https://git.kernel.org/netdev/net/c/c0ebe492329a
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 v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
From: patchwork-bot+netdevbpf @ 2026-06-19 1:20 UTC (permalink / raw)
To: Andrea della Porta
Cc: netdev, theo.lebrun, nicolas.ferre, claudiu.beznea, andrew+netdev,
davem, edumazet, kuba, pabeni, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, nb, lukasz, sjaeckel
In-Reply-To: <468f480454a314303bac6a54780b153f689f2267.1781598350.git.andrea.porta@suse.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 15:23:03 +0200 you wrote:
> From: Lukasz Raczylo <lukasz@raczylo.com>
>
> The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on
> the TX queue.
> While the exact root cause is not yet fully understood, it is likely
> related to a hardware issue where a TSTART write to the NCR register
> is missed, preventing the transmission from being kicked off.
>
> [...]
Here is the summary with links:
- [v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
https://git.kernel.org/netdev/net/c/e438ec3e9e95
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] selftests: vlan_bridge_binding: Fix flaky operational state check
From: Jakub Kicinski @ 2026-06-19 1:17 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, pabeni, edumazet, petrm, horms, razor
In-Reply-To: <20260617104323.1069457-1-idosch@nvidia.com>
On Wed, 17 Jun 2026 13:43:23 +0300 Ido Schimmel wrote:
> check_operstate() busy waits for up to one second for the operational
> state to change to the expected state. This is not enough since carrier
> loss events can be delayed by the kernel for up to one second (see
> __linkwatch_run_queue()), leading to sporadic failures.
>
> Fix by increasing the busy wait period to two seconds.
Thanks!!
^ permalink raw reply
* [PATCH] net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit
From: Jan Klos @ 2026-06-19 1:15 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, Russell King, netdev; +Cc: Jan Klos, linux-kernel
On RTL8127A connected to a link partner that advertises 10000baseT
speed cannot be changed to anything other than 10000baseT as 10GbE
is always advertised regardless of any setting. Fix this by
clearing MDIO_AN_10GBT_CTRL_ADV10G bit in rtl822x_config_aneg()'s
call to phy_modify_mmd_changed().
Signed-off-by: Jan Klos <honza.klos@gmail.com>
---
drivers/net/phy/realtek/realtek_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 27268811f564..b65d0f5fa1a0 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -1802,7 +1802,8 @@ static int rtl822x_config_aneg(struct phy_device *phydev)
ret = phy_modify_mmd_changed(phydev, MDIO_MMD_VEND2,
RTL_MDIO_AN_10GBT_CTRL,
MDIO_AN_10GBT_CTRL_ADV2_5G |
- MDIO_AN_10GBT_CTRL_ADV5G, adv);
+ MDIO_AN_10GBT_CTRL_ADV5G |
+ MDIO_AN_10GBT_CTRL_ADV10G, adv);
if (ret < 0)
return ret;
}
base-commit: 7d8297e26b4e20b5d1c3c3fe51fe81a1c7fbc823
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] net: mvneta: re-enable percpu interrupt on resume
From: Zhou, Yun @ 2026-06-19 1:15 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: marcin.s.wojtas, andrew+netdev, davem, edumazet, kuba, pabeni,
maxime.chevallier, netdev, linux-kernel
In-Reply-To: <20260618155337._cxJpvd0@linutronix.de>
On 6/18/2026 11:53 PM, Sebastian Andrzej Siewior wrote:
> On 2026-06-18 23:45:51 [+0800], Zhou, Yun wrote:
>>> Having a NAPI instance with IRQ per queue and those configured and
>>> spread among CPUs should cause less trouble and is what others do.
>>> In fact is the only net driver using per-CPU interrupts.
>>>
>> It is a SoC limitation. Armada XP's MPIC provides a single shared
>> interrupt for the ethernet controller with per-CPU masking for
>> interrupt steering — there are no per-queue MSI vectors. The percpu
>> IRQ model was the only way to distribute interrupt handling across
>> CPUs given this hardware constraint.
>
> Is this a hardware constraint or more a software design choice? From the
> other comment it read like it could be changed.
> There is nothing wrong to provide 4 interrupts for a device from the
> device-tree and then allocate and request all four. This requires that
> SMP affinity is supported properly in order to spread it across CPU. You
> would also be able to reduce the amount of queues/ interrupts via
> ethtool if you would like to isolate a CPU for NOHZ reasons.
>
This is a hardware constraint, not a software design choice.
On MPIC platforms (armada-370/XP/38x), the mvneta interrupt (e.g.
hwirq 8) is a per-CPU hardware interrupt line (hwirq < 29 in MPIC).
It is a single physical interrupt source that MPIC routes to all CPUs
simultaneously — each CPU has its own per-CPU mask register to
independently control whether it responds to that same line.
There are not 4 separate hardware interrupt lines that could be
individually allocated. The irqchip driver (irq-armada-370-xp.c)
marks these hwirqs as IRQ_PER_CPU_DEVID in mpic_irq_map():
if (mpic_is_percpu_irq(hwirq)) {
irq_set_percpu_devid(virq);
irq_set_chip_and_handler(virq, &mpic_irq_chip,
handle_percpu_devid_irq);
}
This means request_percpu_irq() is the only valid registration
method — a plain request_irq() would fail with -EINVAL because the
irq descriptor requires IRQ_PER_CPU_DEVID semantics.
The multi-interrupt approach (like MSI-X NICs) would require the
hardware to provide multiple distinct interrupt lines per port,
which this SoC does not have.
BR,
Yun
^ permalink raw reply
* Re: [PATCH net V2 0/3] net/mlx5e: Fix crashes in dynamic per-channel stats and HV VHCA agent
From: Jakub Kicinski @ 2026-06-19 1:14 UTC (permalink / raw)
To: Tariq Toukan
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, netdev, Paolo Abeni,
Cosmin Ratiu, Eran Ben Elisha, Feng Liu, Haiyang Zhang,
Lama Kayal, Leon Romanovsky, linux-kernel, linux-rdma, Mark Bloch,
Nimrod Oren, Saeed Mahameed
In-Reply-To: <20260617140127.573117-1-tariqt@nvidia.com>
On Wed, 17 Jun 2026 17:01:24 +0300 Tariq Toukan wrote:
> Since per-channel stats were converted to be allocated and published
> lazily at first channel open in commit fa691d0c9c08 ("net/mlx5e:
> Allocate per-channel stats dynamically at first usage"),
> priv->channel_stats[] and priv->stats_nch are filled in
> incrementally during interface bring-up. This opened a window in
> which the various stats readers - most of them reachable from
> userspace via netlink/netdev stats queries - can race with
> mlx5e_open_channel() on another CPU and observe partially
> initialized state. The HV VHCA stats agent, which is created
> before the channels are opened, hits related problems of its own.
>
> This series by Feng fixes the resulting crashes.
No longer(?) applies:
Applying: net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation
Applying: net/mlx5e: Fix HV VHCA stats agent registration race
Applying: net/mlx5e: Fix publication race for priv->channel_stats[]
error: patch failed: drivers/net/ethernet/mellanox/mlx5/core/en_main.c:5533
error: drivers/net/ethernet/mellanox/mlx5/core/en_main.c: patch does not apply
Patch failed at 0003 net/mlx5e: Fix publication race for priv->channel_stats[]
--
pw-bot: cr
^ permalink raw reply
* AppArmor: TCP Fast Open bypasses connect mediation (last unaddressed LSM)
From: Bryam Vargas @ 2026-06-19 1:11 UTC (permalink / raw)
To: John Johansen, linux-security-module, apparmor
Cc: Paul Moore, James Morris, Serge E . Hallyn, Mickael Salaun,
Stephen Smalley, Matthieu Buffet, Mikhail Ivanov, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Hello John, and LSM folks,
I have been working on the Landlock TCP Fast Open connect bypass [1]. Stephen
Smalley's SELinux fix for the same issue [3] -- "Similar to Landlock, SELinux was
not updated when TCP Fast Open support was introduced ..." -- made me go back and
check the rest of the connect-mediating LSMs, since I had only been looking at
Landlock. With Landlock [2], SELinux [3], and now TOMOYO [4] all getting fixes,
AppArmor is the last one with the same gap and no fix yet.
Root cause (shared with the others)
-----------------------------------
security_socket_connect() has a single call site, net/socket.c (the connect(2)
syscall). TCP Fast Open performs an implicit connect inside sendmsg:
tcp_sendmsg -> tcp_sendmsg_fastopen -> __inet_stream_connect(..., is_sendmsg=1)
-> sk->sk_prot->connect() net/ipv4/{tcp.c,af_inet.c}
This never calls security_socket_connect(); the only LSM hook on the path is
security_socket_sendmsg(). mptcp_sendmsg_fastopen reaches the same code and is a
second producer.
AppArmor
--------
apparmor_socket_connect() requests AA_MAY_CONNECT; apparmor_socket_sendmsg() (via
aa_sock_msg_perm) requests AA_MAY_SEND. These are distinct bits, and apparmor_parser
compiles them independently: "network send inet stream," yields accept mask 0x02
while "network connect inet stream," yields 0x40. So an egress-restriction profile
that grants send but not connect is bypassed by MSG_FASTOPEN.
Reproduced on 6.12.88 with apparmor active. Under a profile granting the inet/inet6
stream lifecycle except connect:
aa-exec -p egress_restricted -- ./probe
[TCP ] connect(2)=EACCES(blocked) sendto(MSG_FASTOPEN)=OK(reached) => connection established
[TCP6] connect(2)=EACCES(blocked) sendto(MSG_FASTOPEN)=OK(reached) => connection established
(The coarse "network inet stream," idiom grants connect anyway, so this only bites the
fine-grained "allow send, deny connect" policy that the asymmetry is meant to serve.)
Fix
---
Same shape as the TOMOYO [4] and SELinux [3] fixes: in apparmor_socket_sendmsg (or
aa_sock_msg_perm), when MSG_FASTOPEN is set and msg_name carries a destination on a
not-yet-connected stream socket, additionally require aa_sk_perm(OP_CONNECT,
AA_MAY_CONNECT, sk). I am happy to send that patch and the reproducer.
(A single core check in __inet_stream_connect(), gated on is_sendmsg, would have
covered all five LSMs and both the TCP and MPTCP producers in one place -- the kernel
already mediates the analogous implicit-connect-on-send for AF_UNIX via
security_unix_may_send and for SCTP via security_sctp_bind_connect. But since the
other four LSMs are taking per-hook fixes, AppArmor matching them is the consistent
move; mentioning the core option only in case it is preferred.)
[1] Landlock: LANDLOCK_ACCESS_NET_CONNECT_TCP bypass via TCP Fast Open (report)
https://lore.kernel.org/r/20260616201615.275032-1-hexlabsecurity@proton.me
[2] landlock: fix TCP Fast Open connection bypass (Matthieu Buffet)
https://lore.kernel.org/r/20260617180526.15627-2-matthieu@buffet.re
[3] selinux: check connect-related permissions on TCP Fast Open (Stephen Smalley)
https://lore.kernel.org/r/20260618175513.112443-2-stephen.smalley.work@gmail.com
[4] tomoyo: Enforce connect policy in TCP Fast Open (Matthieu Buffet)
https://lore.kernel.org/r/20260619002207.61104-1-matthieu@buffet.re
Thanks,
Bryam Vargas
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: fix foe_check_time allocation size
From: patchwork-bot+netdevbpf @ 2026-06-19 1:10 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161119471.2163752.14373384830691569758@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 19:52:36 +0800 you wrote:
> foe_check_time is declared as u16 pointer but was allocated with
> only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
>
> When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
> it writes beyond the allocated buffer, causing heap buffer overflow and
> potential kernel crash.
>
> [...]
Here is the summary with links:
- [v2,net] net: airoha: fix foe_check_time allocation size
https://git.kernel.org/netdev/net/c/5c121ee63568
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 v3] net: pch_gbe: handle TX skb allocation failure
From: patchwork-bot+netdevbpf @ 2026-06-19 1:10 UTC (permalink / raw)
To: Ruoyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, masa-korg,
netdev, linux-kernel
In-Reply-To: <20260615125043.3537046-1-ruoyuw560@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 15 Jun 2026 20:50:42 +0800 you wrote:
> pch_gbe_alloc_tx_buffers() allocates an skb for each TX descriptor and
> then passes the returned pointer to skb_reserve(). If netdev_alloc_skb()
> fails, skb_reserve() dereferences NULL.
>
> Make pch_gbe_alloc_tx_buffers() return an error when an skb allocation
> fails. On failure, let pch_gbe_alloc_tx_buffers() clean the partially
> allocated TX ring before returning the error. While bringing the device
> up, release the RX buffer pool through a shared cleanup helper before
> unwinding the IRQ setup.
>
> [...]
Here is the summary with links:
- [net,v3] net: pch_gbe: handle TX skb allocation failure
https://git.kernel.org/netdev/net/c/a0aa6bf985aa
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 v3] octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF
From: patchwork-bot+netdevbpf @ 2026-06-19 1:10 UTC (permalink / raw)
To: Junrui Luo
Cc: sgoutham, lcherian, gakula, hkelam, sbhatta, andrew+netdev, davem,
edumazet, kuba, pabeni, netdev, linux-kernel, danisjiang, stable
In-Reply-To: <SYBPR01MB78811656934E713B77DA6CEDAFE62@SYBPR01MB7881.ausprd01.prod.outlook.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 15 Jun 2026 23:04:27 +0800 you wrote:
> rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct
> index into the LMT map table to read another function's LMTLINE
> physical base address and copy it into the caller's own LMT map table
> entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the
> IRQ source, but req->base_pcifunc is a separate payload field and is
> not sanitized.
>
> [...]
Here is the summary with links:
- [net,v3] octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF
https://git.kernel.org/netdev/net/c/8cdcf3d2caac
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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