* 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
* Re: [PATCH net 0/2] devlink: Fix a couple parent ref leaks
From: patchwork-bot+netdevbpf @ 2026-06-19 1:10 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: netdev, jiri, davem, edumazet, kuba, pabeni, horms,
michal.wilczynski, cjubran, mbloch, tariqt
In-Reply-To: <20260616110633.1449432-1-cratiu@nvidia.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 14:06:31 +0300 you wrote:
> These two patches fix parent ref leaks on errors.
>
> Cosmin Ratiu (2):
> devlink: Fix parent ref leak in devl_rate_node_create()
> devlink: Fix parent ref leak on tc-bw failure
>
> net/devlink/rate.c | 25 ++++++++++++++-----------
> 1 file changed, 14 insertions(+), 11 deletions(-)
Here is the summary with links:
- [net,1/2] devlink: Fix parent ref leak in devl_rate_node_create()
https://git.kernel.org/netdev/net/c/ba45106342bb
- [net,2/2] devlink: Fix parent ref leak on tc-bw failure
https://git.kernel.org/netdev/net/c/ba81a8b80f04
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 0/2] dpaa2-switch: reject VLAN uppers while bridged
From: patchwork-bot+netdevbpf @ 2026-06-19 1:00 UTC (permalink / raw)
To: Ioana Ciornei
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev, f.fainelli,
vladimir.oltean, linux-kernel
In-Reply-To: <20260618092813.432535-1-ioana.ciornei@nxp.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 18 Jun 2026 12:28:11 +0300 you wrote:
> The dpaa2-switch driver does not support VLAN uppers on its ports while
> they are bridged. The check which should have prevented a port with a
> VLAN upper to join bridge was poorly refactored and didn't actually
> return an error. Patch 2/2 fixes that.
>
> On the other hand, the driver didn't reject the addition of a VLAN upper
> while bridged. Patch 1/2 fixes that.
>
> [...]
Here is the summary with links:
- [net,v2,1/2] dpaa2-switch: do not accept VLAN uppers while bridged
(no matching commit)
- [net,v2,2/2] dpaa2-switch: fix VLAN upper check not rejecting bridge join
https://git.kernel.org/netdev/net/c/ed2294f94e34
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] dpaa2-switch: fix VLAN upper check not rejecting bridge join
From: patchwork-bot+netdevbpf @ 2026-06-19 1:00 UTC (permalink / raw)
To: Ioana Ciornei
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev, f.fainelli,
vladimir.oltean, linux-kernel
In-Reply-To: <20260616105430.3725910-1-ioana.ciornei@nxp.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 13:54:30 +0300 you wrote:
> The blamed commit refactored the prechangeupper event handling but
> failed to actually return an error in case
> dpaa2_switch_prevent_bridging_with_8021q_upper() detected a 802.1q upper
> on a port which tries to join a bridge. Fix this by returning err
> instead of 0.
>
> Fixes: 45035febc495 ("net: dpaa2-switch: refactor prechangeupper sanity checks")
> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
>
> [...]
Here is the summary with links:
- [net] dpaa2-switch: fix VLAN upper check not rejecting bridge join
https://git.kernel.org/netdev/net/c/ed2294f94e34
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: llc: make empty have static storage duration
From: patchwork-bot+netdevbpf @ 2026-06-19 1:00 UTC (permalink / raw)
To: Wentao Guan; +Cc: kuba, joel.granados, netdev, linux-kernel, zhanjun, niecheng1
In-Reply-To: <20260616064053.690154-1-guanwentao@uniontech.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 16 Jun 2026 14:40:53 +0800 you wrote:
> Make empty have static storage duration (like net/sysctl_net.c does) to
> avoid a potential use-after-return and keep consistent with
> __register_sysctl_table @table 'should not be free'd after registration'.
>
> Fixes: 73dbd8cf7947 ("net: Remove ctl_table sentinel elements from several networking subsystems")
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
>
> [...]
Here is the summary with links:
- [net] net: llc: make empty have static storage duration
https://git.kernel.org/netdev/net/c/d31deeab707b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net v2] net/sched: fix partial tx_queue_len change rollback
From: Jakub Kicinski @ 2026-06-19 0:59 UTC (permalink / raw)
To: Chenguang Zhao
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman, netdev
In-Reply-To: <20260615031824.314112-1-zhaochenguang@kylinos.cn>
On Mon, 15 Jun 2026 11:18:24 +0800 Chenguang Zhao wrote:
> When dev_qdisc_change_tx_queue_len() fails partway through updating
> per-tx-queue qdiscs, previously updated queues were left at the new
> size while netif_change_tx_queue_len() only restored dev->tx_queue_len.
>
> Pass the original queue length and roll back successfully updated
> queues on failure.
I don't think it matters. Also net-next is closed.
--
pw-bot: reject
^ permalink raw reply
* Re: [PATCH net v2 0/2] net: ethernet: sunplus: spl2sw: fix of_node refcount leaks
From: Jakub Kicinski @ 2026-06-19 0:56 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Wells Lu, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, netdev, linux-kernel, Shitalkumar Gandhi
In-Reply-To: <cover.1781552725.git.shitalkumar.gandhi@cambiumnetworks.com>
On Tue, 16 Jun 2026 01:20:30 +0530 Shitalkumar Gandhi wrote:
> This series fixes of_node refcount leaks in the Sunplus SP7021 ethernet
> driver, found by inspection. Compile-tested only; no SP7021 hardware
> available here.
>
> Patch 1/2 fixes the phy_node leak in the remove path.
> Patch 2/2 fixes multiple leaks in the probe path and depends on the
> cleanup contract from patch 1/2.
Wells Lu, please review.
--
mping: SUNPLUS ETHERNET DRIVER
^ permalink raw reply
* Re: [PATCH net] net: llc: make empty have static storage duration
From: Jakub Kicinski @ 2026-06-19 0:52 UTC (permalink / raw)
To: Wentao Guan; +Cc: joel.granados, netdev, linux-kernel, zhanjun, niecheng1
In-Reply-To: <20260616064053.690154-1-guanwentao@uniontech.com>
On Tue, 16 Jun 2026 14:40:53 +0800 Wentao Guan wrote:
> Make empty have static storage duration (like net/sysctl_net.c does) to
> avoid a potential use-after-return and keep consistent with
> __register_sysctl_table @table 'should not be free'd after registration'.
>
> Fixes: 73dbd8cf7947 ("net: Remove ctl_table sentinel elements from several networking subsystems")
> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
> ---
> net/llc/sysctl_net_llc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/llc/sysctl_net_llc.c b/net/llc/sysctl_net_llc.c
> index c8d88e2508fce..15f1e5d88f208 100644
> --- a/net/llc/sysctl_net_llc.c
> +++ b/net/llc/sysctl_net_llc.c
> @@ -47,7 +47,7 @@ static struct ctl_table_header *llc_station_header;
>
> int __init llc_sysctl_init(void)
> {
> - struct ctl_table empty[1] = {};
> + static struct ctl_table empty[1] = {};
> llc2_timeout_header = register_net_sysctl(&init_net, "net/llc/llc2/timeout", llc2_timeout_table);
> llc_station_header = register_net_sysctl_sz(&init_net, "net/llc/station", empty, 0);
I will apply this but it's not a bug.
The size is 0, even tho the pointer is stored there can be no access.
^ permalink raw reply
* Re: [PATCH net v4] virtio-net: fix len check in receive_big()
From: patchwork-bot+netdevbpf @ 2026-06-19 0:50 UTC (permalink / raw)
To: Xiang Mei
Cc: mst, jasowang, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, virtualization, linux-kernel,
minhquangbui99, bestswngs
In-Reply-To: <20260616042837.2249468-1-xmei5@asu.edu>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 15 Jun 2026 21:28:37 -0700 you wrote:
> receive_big() bounds the device-announced length by
> (big_packets_num_skbfrags + 1) * PAGE_SIZE. That is still too loose:
> add_recvbuf_big() sets sg[1] to start at offset
> sizeof(struct padded_vnet_hdr) into the first page, so the chain
> actually carries hdr_len + (PAGE_SIZE - sizeof(padded_vnet_hdr)) +
> big_packets_num_skbfrags * PAGE_SIZE bytes -- 20 bytes less than the
> check allows for the common hdr_len == 12 case.
>
> [...]
Here is the summary with links:
- [net,v4] virtio-net: fix len check in receive_big()
https://git.kernel.org/netdev/net/c/9e5ad06ea826
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