* [PATCH net v5 1/2] net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak,
Larysa Zaremba
In-Reply-To: <cover.1782581445.git.petr.wozniak@gmail.com>
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create().
Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release")
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
---
drivers/net/phy/sfp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 03bfd8640db9..c4d274ab651e 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -963,6 +963,7 @@ static int sfp_i2c_mdiobus_create(struct sfp *sfp)
static void sfp_i2c_mdiobus_destroy(struct sfp *sfp)
{
mdiobus_unregister(sfp->i2c_mii);
+ mdiobus_free(sfp->i2c_mii);
sfp->i2c_mii = NULL;
}
--
2.51.0
^ permalink raw reply related
* [PATCH net v5 2/2] Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"
From: Petr Wozniak @ 2026-06-27 17:32 UTC (permalink / raw)
To: linux, andrew, hkallweit1
Cc: kuba, davem, edumazet, pabeni, netdev, linux-kernel, linux-phy,
maxime.chevallier, bjorn, olek2, kabel, Petr Wozniak
In-Reply-To: <cover.1782581445.git.petr.wozniak@gmail.com>
This reverts commit 8fe125892f40 ("net: phy: sfp: probe for RollBall
I2C-to-MDIO bridge in mdio-i2c").
That commit added a RollBall bridge probe at MDIO bus creation time, in
i2c_mii_init_rollball(), to avoid a multi-minute PHY probe retry loop on
modules without a bridge (e.g. RTL8261BE). The probe runs in SFP_S_INIT,
before genuine RollBall modules have finished their firmware/bridge
initialization, so the bridge does not yet answer CMD_READ/CMD_DONE. The
probe times out, mdio_protocol is set to MDIO_I2C_NONE, and PHY detection
is then skipped for genuine RollBall modules that worked before the commit.
This was confirmed on hardware by Maxime Chevallier and Aleksander
Bajkowski: their RollBall modules no longer detect a PHY, and work again
on v7.0 (before the bridge probing was introduced). The Sashiko static
review flagged the same path.
Deferring the probe to PHY discovery time does not fix it either: at that
point a slow module may still be initializing, so the probe still returns
-ENODEV. A proper fix needs per-module init timing (a longer module_t_wait
or a per-module quirk, per SFF-8472 the host must also wait at least 300 ms
after insertion), which requires genuine RollBall hardware to develop and
validate. Revert to restore the previous, working behaviour in the meantime.
The RTL8261BE retry-loop latency that the reverted commit addressed is
handled in our downstream tree, so reverting upstream is safe on our side.
Fixes: 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c")
Reported-by: Aleksander Bajkowski <olek2@wp.pl>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/
Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com>
---
drivers/net/mdio/mdio-i2c.c | 59 +++++--------------------------------
drivers/net/phy/sfp.c | 14 ++-------
2 files changed, 10 insertions(+), 63 deletions(-)
diff --git a/drivers/net/mdio/mdio-i2c.c b/drivers/net/mdio/mdio-i2c.c
index b88f63234b4e..ed20352a589a 100644
--- a/drivers/net/mdio/mdio-i2c.c
+++ b/drivers/net/mdio/mdio-i2c.c
@@ -419,50 +419,6 @@ static int i2c_mii_write_rollball(struct mii_bus *bus, int phy_id, int devad,
return 0;
}
-static int i2c_mii_probe_rollball(struct i2c_adapter *i2c)
-{
- u8 data_buf[] = { ROLLBALL_DATA_ADDR, 0x01, 0x00, 0x00 };
- u8 cmd_buf[] = { ROLLBALL_CMD_ADDR, ROLLBALL_CMD_READ };
- u8 cmd_addr = ROLLBALL_CMD_ADDR;
- struct i2c_msg msgs[2];
- u8 result;
- int ret;
- int i;
-
- msgs[0].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[0].flags = 0;
- msgs[0].len = sizeof(data_buf);
- msgs[0].buf = data_buf;
- msgs[1].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[1].flags = 0;
- msgs[1].len = sizeof(cmd_buf);
- msgs[1].buf = cmd_buf;
-
- ret = i2c_transfer_rollball(i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return -ENODEV;
-
- msgs[0].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[0].flags = 0;
- msgs[0].len = 1;
- msgs[0].buf = &cmd_addr;
- msgs[1].addr = ROLLBALL_PHY_I2C_ADDR;
- msgs[1].flags = I2C_M_RD;
- msgs[1].len = 1;
- msgs[1].buf = &result;
-
- for (i = 0; i < 10; i++) {
- msleep(20);
- ret = i2c_transfer_rollball(i2c, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- return -ENODEV;
- if (result == ROLLBALL_CMD_DONE)
- return 0;
- }
-
- return -ENODEV;
-}
-
static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
{
struct i2c_msg msg;
@@ -482,11 +438,11 @@ static int i2c_mii_init_rollball(struct i2c_adapter *i2c)
ret = i2c_transfer(i2c, &msg, 1);
if (ret < 0)
- return -ENODEV;
- if (ret != 1)
+ return ret;
+ else if (ret != 1)
return -EIO;
-
- return i2c_mii_probe_rollball(i2c);
+ else
+ return 0;
}
static bool mdio_i2c_check_functionality(struct i2c_adapter *i2c,
@@ -531,10 +487,9 @@ struct mii_bus *mdio_i2c_alloc(struct device *parent, struct i2c_adapter *i2c,
case MDIO_I2C_ROLLBALL:
ret = i2c_mii_init_rollball(i2c);
if (ret < 0) {
- if (ret != -ENODEV)
- dev_err(parent,
- "Cannot initialize RollBall MDIO I2C protocol: %d\n",
- ret);
+ dev_err(parent,
+ "Cannot initialize RollBall MDIO I2C protocol: %d\n",
+ ret);
mdiobus_free(mii);
return ERR_PTR(ret);
}
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index c4d274ab651e..f520206734da 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -597,7 +597,6 @@ static const struct sfp_quirk sfp_quirks[] = {
// OEM SFP-GE-T is a 1000Base-T module with broken TX_FAULT indicator
SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
- SFP_QUIRK_F("OEM", "SFP-10G-T-I", sfp_fixup_rollball),
SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
SFP_QUIRK_S("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
SFP_QUIRK_S("OEM", "SFP-2.5G-BX10-D", sfp_quirk_2500basex),
@@ -2174,17 +2173,10 @@ static void sfp_sm_fault(struct sfp *sfp, unsigned int next_state, bool warn)
static int sfp_sm_add_mdio_bus(struct sfp *sfp)
{
- int ret;
-
- if (sfp->mdio_protocol == MDIO_I2C_NONE)
- return 0;
+ if (sfp->mdio_protocol != MDIO_I2C_NONE)
+ return sfp_i2c_mdiobus_create(sfp);
- ret = sfp_i2c_mdiobus_create(sfp);
- if (ret == -ENODEV) {
- sfp->mdio_protocol = MDIO_I2C_NONE;
- return 0;
- }
- return ret;
+ return 0;
}
/* Probe a SFP for a PHY device if the module supports copper - the PHY
--
2.51.0
^ permalink raw reply related
* Re: [PATCH bpf v2 0/4] bpf, sockmap: Fix sockmap leaking UDP socks
From: sun jian @ 2026-06-27 17:34 UTC (permalink / raw)
To: Michal Luczaj
Cc: Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
John Fastabend, Jakub Sitnicki, Jiayuan Chen, David S. Miller,
Jakub Kicinski, Simon Horman, Alexei Starovoitov, Cong Wang,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Emil Tsalapatis, Shuah Khan, netdev,
bpf, linux-kernel, linux-kselftest
In-Reply-To: <20260626-sockmap-lookup-udp-leak-v2-0-7e7e201c951a@rbox.co>
On Sat, Jun 27, 2026 at 4:37 AM Michal Luczaj <mhal@rbox.co> wrote:
>
> Fix for UDP sockets getting leaked during sockmap lookup/release.
> Accompanied by selftests updates.
>
> Signed-off-by: Michal Luczaj <mhal@rbox.co>
> ---
> Changes in v2:
> - selftest: drop the original, adapt old tests
> - fix: change approach to rejecting unbound UDP [Kuniyuki]
> - Link to v1: https://patch.msgid.link/20260623-sockmap-lookup-udp-leak-v1-0-05804f9308e4@rbox.co
>
> ---
> Michal Luczaj (4):
> bpf, sockmap: Reject unhashed UDP sockets on sockmap update
> selftests/bpf: Ensure UDP sockets are bound
> selftests/bpf: Adapt sockmap update error handling
> selftests/bpf: Fail unbound UDP on sockmap update
>
> net/core/sock_map.c | 2 ++
> tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 6 +++---
> tools/testing/selftests/bpf/prog_tests/sockmap_listen.c | 17 +++++++++--------
> tools/testing/selftests/bpf/test_maps.c | 6 +++---
> 4 files changed, 17 insertions(+), 14 deletions(-)
> ---
> base-commit: 26490a375cb9be9bac96b5171610fd85ca6c2305
> change-id: 20260617-sockmap-lookup-udp-leak-bc4e5c5481d7
>
> Best regards,
> --
> Michal Luczaj <mhal@rbox.co>
>
>
Hi Michal,
I tested this series on bpf.git base commit:
26490a375cb9be9bac96b5171610fd85ca6c2305
The test environment was virtme-ng x86_64.
Before, with only patches 2/4-4/4 applied:
sockmap_basic: PASS
sockmap_listen: FAIL as expected
- UDP test_insert_opened failed on sockmap/sockhash,
both IPv4 and IPv6
test_maps: FAIL as expected
- failed at the new unbound SOCK_DGRAM update check
After applying the full series:
sockmap_basic: PASS
sockmap_listen: PASS
test_maps: no longer failed at the unbound
SOCK_DGRAM update check
test_maps still later reported:
Failed sockmap unexpected timeout
However, I can reproduce the same timeout in three consecutive
runs on the unmodified base commit, so this looks pre-existing or
environmental in my virtme-ng setup rather than a regression from
this series.
I am not adding a Tested-by tag for now because test_maps does not
fully pass in my setup. The targeted before/after behavior behaved as
expected.
Thanks,
Sun Jian
^ permalink raw reply
* Re: [PATCH net v2] nfc: nci: fix uninit-value in nci_core_init_rsp_packet()
From: David Heidelberg @ 2026-06-27 18:15 UTC (permalink / raw)
To: Samuel Page
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260624224455.999374-1-sam@bynar.io>
On Wed, 24 Jun 2026 23:44:55 +0100, Samuel Page wrote:
> nfc: nci: fix uninit-value in nci_core_init_rsp_packet()
Applied, thanks!
[1/1] nfc: nci: fix uninit-value in nci_core_init_rsp_packet()
commit: 27d431711a3a6e23e7f961ec2934de20e2ed7cac
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH net] nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
From: David Heidelberg @ 2026-06-27 18:34 UTC (permalink / raw)
To: Samuel Page
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260622145243.3167276-1-sam@bynar.io>
On Mon, 22 Jun 2026 16:52:43 +0200, Samuel Page wrote:
> nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
Applied, thanks!
[1/1] nfc: nci: fix out-of-bounds write in nci_target_auto_activated()
commit: e87faad807329d1348595dbcea3444acd7bb0ca6
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH net v2] nfc: nci: fix uninit-value in the RF discover/activated NTF handlers
From: David Heidelberg @ 2026-06-27 18:41 UTC (permalink / raw)
To: Samuel Page
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, oe-linux-nfc, netdev, linux-kernel, stable
In-Reply-To: <20260626090301.2139500-1-sam@bynar.io>
On 26/06/2026 11:03, Samuel Page wrote:
> nci_rf_discover_ntf_packet() and nci_rf_intf_activated_ntf_packet() each
> parse a notification into an on-stack struct (nci_rf_discover_ntf /
> nci_rf_intf_activated_ntf) that is not initialised. The RF
> technology-specific parameters are only extracted when
> rf_tech_specific_params_len is non-zero, so a notification that reports a
> zero length leaves the rf_tech_specific_params union uninitialised - and
> both handlers then pass it to nci_add_new_protocol(), which reads it:
>
> - discover: nci_add_new_target() -> nci_add_new_protocol();
> - activated: nci_target_auto_activated() -> nci_add_new_protocol().
>
> nci_add_new_protocol() uses nfca_poll->nfcid1_len as both a branch
> condition and a memcpy() length and copies nfcid1/sens_res/sel_res into
> ndev->targets, which is later exposed to user space via NFC_CMD_GET_TARGET.
>
> BUG: KMSAN: uninit-value in nci_add_new_protocol+0x624/0x6c0
> nci_add_new_protocol+0x624/0x6c0
> nci_ntf_packet+0x25b2/0x3c30
> nci_rx_work+0x318/0x5d0
> process_scheduled_works+0x84b/0x17a0
> worker_thread+0xc10/0x11b0
> kthread+0x376/0x500
> Local variable ntf.i created at:
> nci_ntf_packet+0xbc2/0x3c30
>
> Zero-initialise both on-stack notifications so the union reads back as
> zero when no technology-specific parameters are present.
>
> Fixes: 019c4fbaa790 ("NFC: Add NCI multiple targets support")
> Fixes: e8c0dacd9836 ("NFC: Update names and structs to NCI spec 1.0 d18")
> Link: https://lore.kernel.org/netdev/20260623172109.1105965-2-horms@kernel.org/
> Cc: stable@vger.kernel.org
> Assisted-by: Bynario AI
Hello Samuel,
the fix look good, may I ask you to follow the Assisted-by syntax as requested
in [1]?
Thank you
David
[1] https://docs.kernel.org/process/coding-assistants.html
> Signed-off-by: Samuel Page <sam@bynar.io>
> ---
> v2: Drop the inaccurate activation_params / NFC_ATTR_TARGET_ATS scenario
> from the commit message. No code change; the ntf = {} fix is unchanged.
>
> net/nfc/nci/ntf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
[...]
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Jiri Slaby @ 2026-06-27 19:04 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
federico.vaga, carlos.bilbao, avadhut.naik, alexs, si.yanteng,
dzm91, 2023002089, tsbogend, dsahern, jani.nikula, mchehab+huawei,
gregkh, tytso, herbert, ebiggers, johannes.berg, geert, pablo,
tglx, mashiro.chen, mingo, dqfext, jreuter, sdf, pkshih,
enelsonmoore, mkl, toke, kees, crossd, jlayton, wangliang74,
aha310510, takamitz, kuniyu, linux-doc, linux-mips
In-Reply-To: <20260421021824.1293976-1-kuba@kernel.org>
On 21. 04. 26, 4:18, Jakub Kicinski wrote:
> Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol implementation
> and all associated hamradio device drivers from the kernel tree.
> This set of protocols has long been a huge bug/syzbot magnet,
> and since nobody stepped up to help us deal with the influx
> of the AI-generated bug reports we need to move it out of tree
> to protect our sanity.
>
> The code is moved to an out-of-tree repo:
> https://github.com/linux-netdev/mod-orphan
> if it's cleaned up and reworked there we can accept it back.
>
> Minimal stub headers are kept for include/net/ax25.h (AX25_P_IP,
> AX25_ADDR_LEN, ax25_address) and include/net/rose.h (ROSE_ADDR_LEN)
> so that the conditional integration code in arp.c and tun.c continues
> to compile and work when the out-of-tree modules are loaded.
...
> delete mode 100644 include/uapi/linux/scc.h
Unfortunately, this broke builds of LLVM -- compiler-rt in particular
(and GCC builds allegedly too). They dropped the include and its use
[1], but IMO we should keep the uapi header with those two structs
(scc_modem + scc_stat) for some time.
[1]
https://github.com/llvm/llvm-project/commit/3dc4fd6dd41100f051a63642f449b16324389c96
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH net] usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()
From: Xiang Mei @ 2026-06-27 20:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev
Cc: linux-usb, linux-kernel, Weiming Shi, Xiang Mei
genelink_rx_fixup() splits an aggregated RX frame into its individual
packets, using a per-packet length taken from device-supplied data. That
length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared
against how many bytes were actually received.
A malicious GeneLink (GL620A) device can therefore send a short URB whose
header claims packet_count > 1 and a first packet of up to 1514 bytes.
skb_put_data(gl_skb, packet->packet_data, size);
then copies past the end of the receive buffer and hands the adjacent slab
contents up the network stack, an out-of-bounds read that leaks kernel heap.
No privilege is required: the path runs in the usbnet RX softirq as soon as
the interface is up.
BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112)
Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14
Call Trace:
...
__asan_memcpy (mm/kasan/shadow.c:105)
genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112)
usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589)
process_one_work (kernel/workqueue.c:3322)
bh_worker (kernel/workqueue.c:3405)
tasklet_action (kernel/softirq.c:965)
handle_softirqs (kernel/softirq.c:622)
run_ksoftirqd (kernel/softirq.c:1076)
...
skb_pull() already verifies that the requested length fits the buffer and
returns NULL otherwise. Move it ahead of the copy and check its result, so
a packet that overruns the received data is rejected before it is read.
Well-formed frames, whose packets are fully present, are unaffected.
Fixes: 47ee3051c856 ("[PATCH] USB: usbnet (5/9) module for genesys gl620a cables")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
---
drivers/net/usb/gl620a.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index 0bfa37c14059..09afd137b64e 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -104,6 +104,9 @@ static int genelink_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
return 0;
}
+ if (!skb_pull(skb, size + 4))
+ return 0;
+
// allocate the skb for the individual packet
gl_skb = alloc_skb(size, GFP_ATOMIC);
if (gl_skb) {
@@ -116,9 +119,6 @@ static int genelink_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
// advance to the next packet
packet = (struct gl_packet *)&packet->packet_data[size];
count--;
-
- // shift the data pointer to the next gl_packet
- skb_pull(skb, size + 4);
}
// skip the packet length field 4 bytes
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v2 1/1] net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
From: Jamal Hadi Salim @ 2026-06-27 21:03 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, davem, edumazet, kuba, pabeni, jiri, victor, security,
zdi-disclosures, stable, kernel test robot
In-Reply-To: <20260627163602.GG1310988@horms.kernel.org>
On Sat, Jun 27, 2026 at 12:36 PM Simon Horman <horms@kernel.org> wrote:
>
> On Fri, Jun 26, 2026 at 12:11:47PM -0400, Jamal Hadi Salim wrote:
> > Hi Simon,
> >
> > On Fri, Jun 26, 2026 at 10:15 AM Simon Horman <horms@kernel.org> wrote:
> > >
> > > On Fri, Jun 26, 2026 at 06:16:43AM -0400, Jamal Hadi Salim wrote:
> > > > "
> > > >
> > > > On Wed, Jun 24, 2026 at 6:40 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > > > >
> > > > > The teql master->slaves singly linked list is not protected against
> > > > > multiple writes. It can be mod'ed concurently from teql_master_xmit(),
> > > > > teql_dequeue(), teql_init() and teql_destroy() without holding any list
> > > > > lock or RCU protection.
> > > > >
> > > > > zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
> > > > > after an RCU grace period, but teql_master_xmit() running on another
> > > > > CPU can still hold a stale pointer into the list, resulting in a
> > > > > slab-use-after-free:
> > > > >
> > > > > BUG: KASAN: slab-use-after-free in teql_destroy+0x3ca/0x440 linux/net/sched/sch_teql.c:142
> > > > > Read of size 8 at addr ffff88802923aa80 by task ip/10024
> > > > >
> > > > > The zdi-disclosures@trendmicro.com repro created concurrent AF_PACKET
> > > > > senders on a teql device against a thread that repeatedly adds/deletes the
> > > > > slave qdisc, together with a SLUB spray that reclaims the freed slot; the
> > > > > resulting UAF is controllable enough to be turned into a read/write
> > > > > primitive against the freed qdisc object.
> > > > >
> > > > > The fix?
> > > > > Add a per-master slaves_lock spinlock that serializes all mutations of
> > > > > master->slaves and the NEXT_SLAVE() links in teql_destroy() and
> > > > > teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
> > > > > around those updates.
> > > > > Annotate master->slaves and the per-slave ->next pointer with __rcu and
> > > > > use the appropriate RCU accessors everywhere they are touched:
> > > > > rcu_assign_pointer() on the writer side (under slaves_lock),
> > > > > rcu_dereference_protected() for the writer-side loads (also under
> > > > > slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
> > > > > rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
> > > > > which run under RTNL.
> > > > > Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
> > > > > traversal in teql_master_xmit(), so that readers either observe a fully
> > > > > linked list or are deferred until the in-flight mutation completes. The two
> > > > > early-return paths in teql_master_xmit() are updated to release the RCU-bh
> > > > > read-side critical section before returning, since leaving it held would
> > > > > disable BH on that CPU for good.
> > > > >
> > > >
> > > > sashiko-gemini's complaints:
> > > > https://sashiko.dev/#/patchset/20260624224016.24018-1-jhs%40mojatatu.com
> > > > seem bogus to me (someone correct me if i am wrong). I am only going
> > > > to address the first claim of "TOCTOU / "resurrection" race in
> > > > teql_master_xmit()"
> > > > teql_master_xmit() holds rcu_read_lock_bh() across the entire
> > > > traversal. teql_destroy() freeing can only proceed once the qdisc's
> > > > RCU grace period has elapsed - so where is this TOCTOU? Let's say this
> > > > were true: both calls hold the slaves_lock.
> > > > The other issues are of similar nature.
> > >
> > > Hi Jamal,
> > >
> > > I think the central question here is about the protection offered by RCU
> > > in these code paths. And while I agree it protects the use of elements
> > > of the list, I think the problem flagged relates to the management of
> > > the list itself.
> > >
> > > The example AI gave me when I asked is like this:
> > >
> > > Assume a TEQL master has one slave, `q`.
> > > The list is circular: `q->next == q`.
> > >
> > > 1. CPU A (Transmitting): Enters `teql_master_xmit()`.
> > > It reads `master->sla ves` and gets a local pointer to `q`.
> > >
> > > 2. CPU B (Destroying): Calls `teql_destroy(q)`.
> > > It takes the lock, unlinks `q`, and sets `master->slaves = NULL`.
> > > The list is now logically empty.
> > >
> > > 3. CPU A: Finishes its work and prepares to rotate the list head
> > > to the next slave.
> > > It takes the lock.
> > >
> > > 4. CPU A (The "Use" / The Resurrection):
> > > It executes: `rcu_assign_pointer(master->slaves, NEXT_SLAVE(q));`
> > > Because `q` was circular, `NEXT_SLAVE(q)` is still `q`.
> > >
> > > 5. CPU A: Releases the lock.
> > > **The global `master->slaves` is now `q` again.**
> > >
> > > 6. The System: The RCU grace period expires. CPU B finishes
> > > `teql_destroy()` and the memory for `q` is freed.
> > >
> > > The global `master->slaves` pointer is now a **dangling pointer**
> > > pointing to freed memory.
> > >
> >
> >
> > Yeah, thats the same earlier claim of TOCTOU (what sashiko-gemini
> > claimed was "resurrecting the freed q")
> > My view is rcu read lock blocks the subsequent call_rcu free - and
> > destroy() and xmit() already serialize on slaves_lock.
>
> The read of master->slaves is outside of the slaves_lock critical
> section(s) in teql_master_xmit(). This is possibly the nub of this issue.
>
Yes, i think this could cause an issue on a second run of xmit() ;->
Let me ponder on it. I will probably have something tommorow..
cheers,
jamal
> > I could be totaly wrong, but it's almost like sashiko-gemini thinks
> > that the list-mutation lock _alone_ governs the object lifetime.
> > The rcu read-side critical section prevents the UAF, not just the
> > slaves_lock alone
> > Only reason i added slaves_lock was to prevent corrupting the list
> > state (whereas the RCU read lock prevents premature free).
> >
> > In step #4 above this thing somehow leaves out any mention of the rcu
> > read lock entirely and places the free in step 6 as if it was
> > independent of CPU A's critical section.
>
> I see what you are saying regarding the free not occurring at step 4
> because CPU A is in an RCU read-side critical section.
>
> But once CPU A has assigned master->slaves as q (again) it exits
> the RCU read-side critical section. Then the free of q can occur.
> And master->slaves will point to memory that has been been freed.
>
> So the access to q is safe when teql_master_xmit is invoked, due to RCU
> protecting object lifetime. But it is unsafe when teql_master_xmit is
> invoked again because by then master->slaves is a dangling pointer.
>
> >
> > I am not sure how to improve it.
> >
> > > > OTOH, sashiko-claude
> > > > (https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260624224016.24018-1-jhs%40mojatatu.com)
> > > > does make some valid claims which are low value, so not sure a resend
> > > > is worth it.
> > > > For example in claim 1 it says "Should the changelog mention this
> > > > teql_dequeue() site too?" Sure I can - but just because I provided
> > > > extra information in the commit log, which I could have omitted, now I
> > > > have to add more info? ;->
> > >
> > > FWIIW, I think there is a value in tightening up the commit message.
> > > E.g. so it's accurate when we look at again in two years time.
> > > But I also lean towards it not being necessary to post an update
> > > only to address this.
> > >
> > >
> > > > The second claim is "rcu_dereference_bh()
> > > > should be rcu_dereference_protected() on writer side". Sparse didnt
> > > > complain and i dont see this as breakage rather a consistency measure.
> > >
> > > I think it would be good to address in the long run. But as per my comment
> > > immediately above, I also lean towards it not being necessary to post an
> > > update only to address this.
> >
> > I can resend with these two taken care of - but i am skeptical of what
> > sashiko-gemini is claiming (and i admit as a human the AI may see
> > something i am totally missing).
> >
> > cheers,
> > jamal
> > >
> > > > Unless I am missing something ..
> > > >
> > > > cheers,
> > > > jamal
^ permalink raw reply
* Re: [PATCH net-next v14 0/9] tls: Add TLS 1.3 hardware offload support
From: Nils Juenemann @ 2026-06-27 21:06 UTC (permalink / raw)
To: rjethwani
Cc: borisp, davem, edumazet, john.fastabend, kuba, leon, mbloch,
netdev, pabeni, saeedm, sd, tariqt
In-Reply-To: <20260515212715.3151307-1-rjethwani@purestorage.com>
Hi Rishikesh, all,
thanks for picking up the sendfile/EOF fix in tls_device_splice_eof().
Separate issue we hit while testing, looks pre-existing in mlx5e
rather than v14: a NULL deref on the RX offload path. Trigger is
ethtool -L <dev> combined 32 (down from 64) under HW-kTLS load,
then a TLS_RX offload setup:
BUG: unable to handle page fault for address: 00000000000031c0
RIP: mlx5e_ktls_add_rx+0x268 [mlx5_core]
Call Trace:
mlx5e_ktls_add
tls_device_dev_add_rx
tls_set_device_offload_rx
tls_setsockopt
sk_rx_queue_get(sk) returns a stale rxq (62 here) after the
reduction; mlx5e_ktls_sk_get_rxq() only guards rxq == -1, so
mlx5e_ktls_add_rx() dereferences priv->channels.c[62], which
appears to be NULL. The resync paths index
priv->channels.c[priv_rx->rxq] the same way. This path is not
TLS 1.3 specific.
I do not have a proposed fix yet. Happy to share the full
decoded oops / additional kdump details or test patches.
Thanks again,
Nils Juenemann
^ permalink raw reply
* Re: [PATCH] netfilter: x_tables: replace strlcat() with snprintf()
From: David Laight @ 2026-06-27 21:16 UTC (permalink / raw)
To: Ian Bridges
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
netfilter-devel, coreteam, netdev, linux-kernel, linux-hardening
In-Reply-To: <aj78X4Cjqcpbb8Co@dev>
On Fri, 26 Jun 2026 17:25:35 -0500
Ian Bridges <icb@fastmail.org> wrote:
> In preparation for removing the deprecated strlcat() API[1], replace the
> strscpy()/strlcat() pairs in xt_proto_init() and xt_proto_fini() with
> snprintf(), which builds each /proc file name in a single call.
>
> Each name is "<prefix><suffix>", where <prefix> is the address-family
> string xt_prefix[af] and <suffix> is one of the FORMAT_TABLES,
> FORMAT_MATCHES or FORMAT_TARGETS literals. snprintf() with a "%s%s"
> format produces the same NUL-terminated, length-bounded string as the
> strscpy()/strlcat() chain it replaces, so the proc entry names are
> unchanged.
>
> Link: https://github.com/KSPP/linux/issues/370 [1]
> Signed-off-by: Ian Bridges <icb@fastmail.org>
> ---
> net/netfilter/x_tables.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index 4e6708c23922..56f4546be336 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -2033,8 +2033,7 @@ int xt_proto_init(struct net *net, u_int8_t af)
> root_uid = make_kuid(net->user_ns, 0);
> root_gid = make_kgid(net->user_ns, 0);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TABLES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TABLES);
If you are going to use snprintf either paste the strings together:
snprintf(buf, sizeof(buf), "%s" FORMAT_TABLES, xt_prefix[af]);
or prepend the "%s" onto the #define of FORMAT_TABLES itself:
snprintf(buf, sizeof(buf), FORMAT_TABLES, xt_prefix[af]);
FORMAT_TABLES should also be FORMAT_NAMES.
-- David
> proc = proc_create_net_data(buf, 0440, net->proc_net, &xt_table_seq_ops,
> sizeof(struct seq_net_private),
> (void *)(unsigned long)af);
> @@ -2043,8 +2042,7 @@ int xt_proto_init(struct net *net, u_int8_t af)
> if (uid_valid(root_uid) && gid_valid(root_gid))
> proc_set_user(proc, root_uid, root_gid);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_MATCHES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_MATCHES);
> proc = proc_create_seq_private(buf, 0440, net->proc_net,
> &xt_match_seq_ops, sizeof(struct nf_mttg_trav),
> (void *)(unsigned long)af);
> @@ -2053,8 +2051,7 @@ int xt_proto_init(struct net *net, u_int8_t af)
> if (uid_valid(root_uid) && gid_valid(root_gid))
> proc_set_user(proc, root_uid, root_gid);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TARGETS, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TARGETS);
> proc = proc_create_seq_private(buf, 0440, net->proc_net,
> &xt_target_seq_ops, sizeof(struct nf_mttg_trav),
> (void *)(unsigned long)af);
> @@ -2068,13 +2065,11 @@ int xt_proto_init(struct net *net, u_int8_t af)
>
> #ifdef CONFIG_PROC_FS
> out_remove_matches:
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_MATCHES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_MATCHES);
> remove_proc_entry(buf, net->proc_net);
>
> out_remove_tables:
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TABLES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TABLES);
> remove_proc_entry(buf, net->proc_net);
> out:
> return -1;
> @@ -2087,16 +2082,13 @@ void xt_proto_fini(struct net *net, u_int8_t af)
> #ifdef CONFIG_PROC_FS
> char buf[XT_FUNCTION_MAXNAMELEN];
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TABLES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TABLES);
> remove_proc_entry(buf, net->proc_net);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_TARGETS, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_TARGETS);
> remove_proc_entry(buf, net->proc_net);
>
> - strscpy(buf, xt_prefix[af], sizeof(buf));
> - strlcat(buf, FORMAT_MATCHES, sizeof(buf));
> + snprintf(buf, sizeof(buf), "%s%s", xt_prefix[af], FORMAT_MATCHES);
> remove_proc_entry(buf, net->proc_net);
> #endif /*CONFIG_PROC_FS*/
> }
^ permalink raw reply
* Re: [RFC PATCH net-next] netpoll: hold RCU while walking napi_list
From: Jakub Kicinski @ 2026-06-27 21:21 UTC (permalink / raw)
To: Runyu Xiao
Cc: davem, edumazet, pabeni, horms, leitao, sashal, bigeasy, netdev,
linux-kernel, jianhao.xu
In-Reply-To: <20260627101228.1191586-1-runyu.xiao@seu.edu.cn>
On Sat, 27 Jun 2026 18:12:28 +0800 Runyu Xiao wrote:
> CONFIG_PROVE_RCU_LIST reports the poll_napi() traversal when the helper
> is exercised directly from netpoll_poll_dev(). The current source has
> important lifetime defenses around NAPI deletion and netpoll device
> close, so this is not presented as a proven use-after-free. The issue is
> that the RCU-list reader contract is implicit at the helper boundary.
Please provide the stack trace from the report, rather than just saying
that you can trigger it.
--
pw-bot: rfc
^ permalink raw reply
* Re: [PATCH] netdevsim: remove debugfs files before freeing net_device
From: Jakub Kicinski @ 2026-06-27 21:21 UTC (permalink / raw)
To: syzbot
Cc: syzkaller-bugs, Andrew Lunn, David S. Miller, Eric Dumazet,
netdev, Paolo Abeni, linux-kernel, syzbot
In-Reply-To: <f15205c4-30e1-454f-97e6-92067a74f98f@mail.kernel.org>
On Sat, 27 Jun 2026 11:20:11 +0000 (UTC) syzbot wrote:
> A KASAN slab-use-after-free was detected in debugfs_u32_get() when reading
> a debugfs file associated with a netdevsim port.
Please read the replies to previous submissions:
https://lore.kernel.org/all/20260626184856.4b7f5228@kernel.org/
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2] r8169: migrate Rx path to page_pool
From: Jakub Kicinski @ 2026-06-27 21:24 UTC (permalink / raw)
To: atharva-potdar
Cc: Heiner Kallweit, nic_swsd, Andrew Lunn, David S . Miller,
Eric Dumazet, Paolo Abeni, Francois Romieu, netdev
In-Reply-To: <20260627035241.59689-1-atharvapotdar07@gmail.com>
On Sat, 27 Jun 2026 09:22:41 +0530 atharva-potdar wrote:
> Signed-off-by: atharva-potdar <atharvapotdar07@gmail.com>
net-next is closed see the process documentation
Please also spell our name in a more usual way.
^ permalink raw reply
* [PATCH net] net: usb: net1080: validate packet_len before pad-byte access in rx_fixup
From: Xiang Mei @ 2026-06-27 21:28 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, linux-usb
Cc: linux-kernel, Weiming Shi, Xiang Mei
net1080_rx_fixup() only bounds the device-supplied packet_len against
NC_MAX_PACKET. When packet_len is even it reads skb->data[packet_len] to
check the pad byte, before the skb->len != packet_len check further down.
A malicious NetChip 1080 device can send a short frame advertising a
large even packet_len (e.g. 0x4000), so the pad-byte read lands past the
end of the skb:
BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup
Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14
...
net1080_rx_fixup (drivers/net/usb/net1080.c:384)
usbnet_bh (drivers/net/usb/usbnet.c:1589)
process_one_work (kernel/workqueue.c:3322)
bh_worker (kernel/workqueue.c:3708)
tasklet_action (kernel/softirq.c:965)
handle_softirqs (kernel/softirq.c:622)
...
Reject the frame if packet_len leaves no room for the pad byte. Valid
even-length frames carry one pad byte (skb->len == packet_len + 1), so
legitimate traffic is unaffected.
Fixes: 904813cd8a0b ("[PATCH] USB: usbnet (4/9) module for net1080 cables")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
---
drivers/net/usb/net1080.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 5d4a1fd2b524..364c19bd822f 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -381,6 +381,13 @@ static int net1080_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
skb_trim(skb, skb->len - sizeof *trailer);
if ((packet_len & 0x01) == 0) {
+ if (packet_len >= skb->len) {
+ dev->net->stats.rx_frame_errors++;
+ netdev_dbg(dev->net, "bad packet len %d (expected %d)\n",
+ skb->len, packet_len);
+ nc_ensure_sync(dev);
+ return 0;
+ }
if (skb->data [packet_len] != PAD_BYTE) {
dev->net->stats.rx_frame_errors++;
netdev_dbg(dev->net, "bad pad\n");
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Jakub Kicinski @ 2026-06-27 21:30 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, Heiner Kallweit, Jonathan Corbet, Shuah Khan,
Oleksij Rempel, Vladimir Oltean, Florian Fainelli,
thomas.petazzoni, netdev, linux-kernel, linux-doc
In-Reply-To: <12b66ea3-42df-4ecb-8eb7-44471407b83f@bootlin.com>
On Sat, 27 Jun 2026 07:34:31 +0200 Maxime Chevallier wrote:
> > This is very far from what existing python tests do in netdev.
>
> We can probably drop the class, as it is with this discussion, it's merely a way
> to regroup doc common to similar tests. The rest really is the usual set of
> ksft funcs you can feed to the run function, with a set of ksft_ethtool_*
> annotators for generic checks.
The common way of checking prereqs in the tests is to call a function
called require_xyz() which then raises a skip. At a quick glance - the
rss_api and xdp_metadata are good tests to get a sense of the usual format.
^ permalink raw reply
page: | 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