* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-20 17:09 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: Tariq Toukan, Boris Pismenny, willemdebruijn.kernel@gmail.com,
andrew+netdev@lunn.ch, daniel.zahka@gmail.com,
davem@davemloft.net, leon@kernel.org, Rahul Rameshbabu,
pabeni@redhat.com, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Raed Salem, Dragos Tatulea,
kees@kernel.org, Mark Bloch, edumazet@google.com, Saeed Mahameed,
netdev@vger.kernel.org, Gal Pressman
In-Reply-To: <d7e2d46769e120a16ce12d345c51a47349733828.camel@nvidia.com>
On Mon, 20 Apr 2026 10:30:46 +0000 Cosmin Ratiu wrote:
> > When psp_dev_create() fails, this function now returns without
> > setting
> > psp->psp, leaving it as NULL. However, priv->psp remains allocated
> > and
> > non-NULL.
> >
> > Does this leave the RX datapath vulnerable to a NULL pointer
> > dereference?
> >
> > If priv->psp is non-NULL, the NIC RX initialization path can still
> > call
> > mlx5_accel_psp_fs_init_rx_tables(), which creates hardware flow
> > steering
> > rules to intercept UDP traffic.
> >
> > If a UDP packet triggers these rules, the hardware flags the CQE with
> > MLX5E_PSP_MARKER_BIT. The RX fast-path sees the marker and invokes
> > mlx5e_psp_offload_handle_rx_skb(), which dereferences the pointer
> > unconditionally:
> >
> > u16 dev_id = priv->psp->psp->id;
> >
> > Since priv->psp->psp is NULL, this will cause a kernel panic. Should
> > priv->psp be cleaned up, or the error propagated, to prevent flow
> > rules
> > from being installed when registration fails?
>
> First, this is preexisting. But more importantly, it's impossible to
> trigger:
> - with no PSP devs, there can be no PSP SAs installed.
> - with no SAs, PSP decryption cannot succeed.
> - all unsuccessfully decrypted PSP packets are dropped by steering.
> - the RX handler will not see any PSP packets with the marker set.
>
> This patch fixes the comparatively way more likely scenario of
> psp_dev_register failing and then mlx5e_psp_unregister passing the
> error pointer to psp_dev_unregister, which will do unpleasant things
> with it.
Sure but why are you leaving the priv->psp struct in place and whatever
FS init has been done? IOW if you really want PSP init to not block
probe why is mlx5e_psp_register() a void function rather than
mlx5e_psp_init() ? Ignoring errors from psp_dev_create()
makes no sense to me - what are you protecting from? kmalloc(GFP_KERNEL)
failing?
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] idpf: do not perform flow ops when netdev is detached
From: Li Li @ 2026-04-20 17:03 UTC (permalink / raw)
To: Kwapulinski, Piotr
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller,
Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
David Decotigny, Singhai, Anjali, Samudrala, Sridhar,
Brian Vazquez, Tantilov, Emil S, stable
In-Reply-To: <PH7PR11MB59834C3C7785D1E69B7E954EF32F2@PH7PR11MB5983.namprd11.prod.outlook.com>
On Mon, Apr 20, 2026 at 1:23 AM Kwapulinski, Piotr
<piotr.kwapulinski@intel.com> wrote:
>
> >-----Original Message-----
> >From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Li Li via Intel-wired-lan
> >Sent: Sunday, April 19, 2026 9:26 PM
> >To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; intel-wired-lan@lists.osuosl.org
> >Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David Decotigny <decot@google.com>; Singhai, Anjali <anjali.singhai@intel.com>; Samudrala, Sridhar <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com>
> >Subject: [Intel-wired-lan] [PATCH] idpf: do not perform flow ops when netdev is detached
> >
> >Even though commit 2e281e1155fc ("idpf: detach and close netdevs while handling a reset") prevents ethtool -N/-n operations to operate on detached netdevs, we found that out-of-tree workflows like OpenOnload can bypass ethtool core locks and call idpf_set_rxnfc directly during an idpf HW reset. When this happens, we could get kernel crashes like the following:
> >
> >[ 4045.787439] BUG: kernel NULL pointer dereference, address: 0000000000000070 [ 4045.794420] #PF: supervisor read access in kernel mode [ 4045.799580] #PF: error_code(0x0000) - not-present page [ 4045.804739] PGD 0 [ 4045.806772] Oops: Oops: 0000 [#1] SMP NOPTI ...
> >[ 4045.836425] Workqueue: onload-wqueue oof_do_deferred_work_fn [onload] [ 4045.842926] RIP: 0010:idpf_del_flow_steer+0x24/0x170 [idpf] ...
> >[ 4045.946323] Call Trace:
> >[ 4045.948796] <TASK>
> >[ 4045.950915] ? show_trace_log_lvl+0x1b0/0x2f0 [ 4045.955293] ? show_trace_log_lvl+0x1b0/0x2f0 [ 4045.959672] ? idpf_set_rxnfc+0x6f/0x80 [idpf] [ 4045.964142] ? __die_body.cold+0x8/0x12 [ 4045.968000] ? page_fault_oops+0x148/0x160 [ 4045.972117] ? exc_page_fault+0x6f/0x160 [ 4045.976060] ? asm_exc_page_fault+0x22/0x30 [ 4045.980262] ? idpf_del_flow_steer+0x24/0x170 [idpf] [ 4045.985245] idpf_set_rxnfc+0x6f/0x80 [idpf] [ 4045.989535] af_xdp_filter_remove+0x7c/0xb0 [sfc_resource] [ 4045.995069] oo_hw_filter_clear_hwports+0x6f/0xa0 [onload] [ 4046.000589] oo_hw_filter_update+0x65/0x210 [onload] [ 4046.005587] oof_hw_filter_update.constprop.0+0xe7/0x140 [onload] [ 4046.011716] oof_manager_update_all_filters+0xad/0x270 [onload] [ 4046.017671] __oof_do_deferred_work+0x15e/0x190 [onload] [ 4046.023014] oof_do_deferred_work+0x2c/0x40 [onload] [ 4046.028018] oof_do_deferred_work_fn+0x12/0x30 [onload] [ 4046.033277] process_one_work+0x174/0x330 [ 4046.037304] worker_thread+0x246/0x390 [ 4046.041074] ? __pfx_worker_thread+0x10/0x10 [ 4046.045364] kthread+0xf6/0x240 [ 4046.048530] ? __pfx_kthread+0x10/0x10 [ 4046.052297] ret_from_fork+0x2d/0x50 [ 4046.055896] ? __pfx_kthread+0x10/0x10 [ 4046.059664] ret_from_fork_asm+0x1a/0x30 [ 4046.063613] </TASK>
> >
> >To prevent this, we need to add checks in idpf_set_rxnfc and idpf_get_rxnfc to error out if the netdev is already detached.
> >
> >Tested: implemented the following patch to synthetically force idpf into a HW reset:
> >
> >diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> >index 4fc0bb14c5b1..27476d57bcf0 100644
> >--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> >+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> >@@ -10,6 +10,9 @@
> > #define idpf_tx_buf_next(buf) (*(u32 *)&(buf)->priv)
> > LIBETH_SQE_CHECK_PRIV(u32);
> >
> >+static bool SIMULATE_TX_TIMEOUT;
> >+module_param(SIMULATE_TX_TIMEOUT, bool, 0644);
> >+
> > /**
> > * idpf_chk_linearize - Check if skb exceeds max descriptors per packet
> > * @skb: send buffer
> >@@ -46,6 +49,8 @@ void idpf_tx_timeout(struct net_device *netdev, unsigned int txqueue)
> >
> > adapter->tx_timeout_count++;
> >
> >+ SIMULATE_TX_TIMEOUT = false;
> >+
> > netdev_err(netdev, "Detected Tx timeout: Count %d, Queue %d\n",
> > adapter->tx_timeout_count, txqueue);
> > if (!idpf_is_reset_in_prog(adapter)) { @@ -2225,6 +2230,8 @@ static bool idpf_tx_clean_complq(struct idpf_compl_queue *complq, int budget,
> > goto fetch_next_desc;
> > }
> > tx_q = complq->txq_grp->txqs[rel_tx_qid];
> >+ if (unlikely(SIMULATE_TX_TIMEOUT && (tx_q->idx % 2 == 1)))
> >+ goto fetch_next_desc;
> >
> > /* Determine completion type */
> > ctype = le16_get_bits(tx_desc->common.qid_comptype_gen,
> >diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >index be66f9b2e101..ba5da2a86c15 100644
> >--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> >@@ -8,6 +8,9 @@
> > #include "idpf_virtchnl.h"
> > #include "idpf_ptp.h"
> >
> >+static bool VIRTCHNL_FAILED;
> >+module_param(VIRTCHNL_FAILED, bool, 0644);
> >+
> > /**
> > * struct idpf_vc_xn_manager - Manager for tracking transactions
> > * @ring: backing and lookup for transactions @@ -3496,6 +3499,11 @@ int idpf_vc_core_init(struct idpf_adapter *adapter)
> > switch (adapter->state) {
> > case __IDPF_VER_CHECK:
> > err = idpf_send_ver_msg(adapter);
> >+
> >+ if (unlikely(VIRTCHNL_FAILED)) {
> >+ err = -EIO;
> >+ }
> Please remove redundant parenthesis
> Piotr
Hi Piotr,
The block you are commenting on is not part of the patch; it's just a
block of test code in the commit message I used to reproduce the
failures.
Thanks!
>
> >+
> > switch (err) {
> > case 0:
> > /* success, move state machine forward */
> >
> >And tested by writing 1 to /sys/module/idpf/parameters/VIRTCHNL_FAILED
> >and /sys/module/idpf/parameters/SIMULATE_TX_TIMEOUT, and running
> >idpf_get_rxnfc() right after the HW reset.
> >
> >Without the patch: encountered NULL pointer and kernel crash.
> >
> >With the patch: no crashes.
> >
> >Fixes: 2e281e1155fc ("idpf: detach and close netdevs while handling a reset")
> >Signed-off-by: Li Li <boolli@google.com>
> >---
> > drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> >diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
> >index bb99d9e7c65d..8368a7e6a754 100644
> >--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
> >+++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
> >@@ -43,6 +43,9 @@ static int idpf_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd,
> > unsigned int cnt = 0;
> > int err = 0;
> >
> >+ if (!netdev || !netif_device_present(netdev))
> >+ return -ENODEV;
> >+
> > idpf_vport_ctrl_lock(netdev);
> > vport = idpf_netdev_to_vport(netdev);
> > vport_config = np->adapter->vport_config[np->vport_idx];
> >@@ -349,6 +352,9 @@ static int idpf_set_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd) {
> > int ret = -EOPNOTSUPP;
> >
> >+ if (!netdev || !netif_device_present(netdev))
> >+ return -ENODEV;
> >+
> > idpf_vport_ctrl_lock(netdev);
> > switch (cmd->cmd) {
> > case ETHTOOL_SRXCLSRLINS:
> >--
> >2.54.0.rc1.513.gad8abe7a5a-goog
^ permalink raw reply
* Re: [PATCH v6 3/3] dts: s32g: Add GPR syscon region
From: Dan Carpenter @ 2026-04-20 16:45 UTC (permalink / raw)
To: Jared Kangas
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, imx,
devicetree, linux-kernel, linaro-s32, netdev
In-Reply-To: <aeZOcCOgMy2g9wqp@rh-jkangas-kernel>
On Mon, Apr 20, 2026 at 09:04:00AM -0700, Jared Kangas wrote:
> Fixing Dan's address based on mailmap update, sorry for the noise.
>
> On Fri, Apr 17, 2026 at 02:36:25PM -0700, Jared Kangas wrote:
> > Hi Dan,
> >
> > On Fri, Jan 30, 2026 at 04:19:52PM +0300, Dan Carpenter wrote:
> > > Add the GPR syscon region for the s32 chipset.
> > >
> > > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> > > ---
> > >
> > > [snip]
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > > index e314f3c7d61d..be03db737384 100644
> > > --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > > @@ -383,6 +383,11 @@ usdhc0-200mhz-grp4 {
> > > };
> > > };
> > >
> > > + gpr: syscon@4007c000 {
> > > + compatible = "nxp,s32g3-gpr", "syscon";
> > > + reg = <0x4007c000 0x3000>;
> > > + };
> > > +
> > > ocotp: nvmem@400a4000 {
> > > compatible = "nxp,s32g3-ocotp", "nxp,s32g2-ocotp";
> > > reg = <0x400a4000 0x400>;
> > > @@ -808,6 +813,7 @@ gmac0: ethernet@4033c000 {
> > > compatible = "nxp,s32g2-dwmac";
> > > reg = <0x4033c000 0x2000>, /* gmac IP */
> > > <0x4007c004 0x4>; /* GMAC_0_CTRL_STS */
> > > + nxp,phy-sel = <&gpr 0x4>;
> > > interrupt-parent = <&gic>;
> > > interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> > > interrupt-names = "macirq";
> >
> > I gave this a test on an S32G-VNP-RDB3 and didn't see any issues on the
> > dwmac-s32 side, but this appears to trigger a panic when reading the new
> > debugfs regmap/*/registers file for the syscon node:
> >
> > # grep 4007c000 /proc/vmallocinfo
> > 0xffff800083da8000-0xffff800083dac000 16384 ioremap_prot+0x74/0xe0 phys=0x000000004007c000 ioremap
> > # cat /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers
> > Internal error: synchronous external abort: 0000000096000210 [#1] SMP
> > [...]
> > CPU: 0 UID: 0 PID: 4344 Comm: cat Tainted: G M E X ------ --- 6.12.0+ #226 PREEMPT_RT
> > Tainted: [M]=MACHINE_CHECK, [E]=UNSIGNED_MODULE, [X]=AUX
> > [...]
> > pc : regmap_mmio_read32le+0x44/0xa0
> > lr : regmap_mmio_read32le+0x44/0xa0
> > [...]
> > x23: ffff00080c080000 x22: ffff000802ac4c00 x21: ffff800087b13c9c
> > x20: ffff800080a46494 x19: ffff800083da810c x18: 0000000000000004
> > [...]
> > x5 : ffff800080a46448 x4 : ffff800083da8000 x3 : ffff800080a46494
> > x2 : ffff800080a47230 x1 : ffff800083da810c x0 : 0000000000000020
> > Call trace:
> > regmap_mmio_read32le+0x44/0xa0 (P)
> > regmap_mmio_read+0x4c/0x80
> > [...]
> > Code: 52800400 8b214093 aa1303e1 97f4caf0 (b9400275)
> > ---[ end trace 0000000000000000 ]---
> > Kernel panic - not syncing: synchronous external abort: Fatal exception
> >
> > Running this through decodecode gives:
> >
> > All code
> > ========
> > 0: 52800400 mov w0, #0x20 // #32
> > 4: 8b214093 add x19, x4, w1, uxtw
> > 8: aa1303e1 mov x1, x19
> > c: 97f4caf0 bl 0xffffffffffd32bcc
> > 10:* b9400275 ldr w21, [x19] <-- trapping instruction
> >
> > Code starting with the faulting instruction
> > ===========================================
> > 0: b9400275 ldr w21, [x19]
> >
> > x19's offset from the base address in /proc/vmallocinfo is 0x10c, which
> > points to a bad read at physical address 0x4007c10c; I also confirmed
> > that the preceding memory reads back without issues:
Oh, ugh... I didn't realize that this wasn't merged. I don't have a
way to test this any more. The simplest fix would be to do change the
0x3000 to 0x100. The GPR63 register is at 0xFC.
reg = <0x4007c000 0x100>;
That's probably the best fix as well. The later register areas would
be their own syscons.
regards,
dan carpenter
^ permalink raw reply
* [PATCH net-next] netlink: clean up failed initial dump-start state
From: Michael Bommarito @ 2026-04-20 16:27 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev
Cc: Simon Horman, Kuniyuki Iwashima, Kees Cook, Feng Yang,
linux-kernel
When __netlink_dump_start() has already installed cb->skb, taken the
module reference and set cb_running, a failure from the first
netlink_dump(sk, true) call returns via errout_skb without unwinding the
callback lifetime. That leaves cb_running set and defers module_put()
and consume_skb(cb->skb) until userspace drains the socket or closes it.
Share the normal callback teardown in a helper and use it on successful
completion and on the initial lock_taken=true failure path. Keep the
lock_taken=false continuation path unchanged, because recvmsg()-driven
retries legitimately preserve cb_running when they run out of receive
room.
Fixes: 16b304f3404f ("netlink: Eliminate kmalloc in netlink dump operation.")
Assisted-by: Claude:claude-opus-4-6
Assisted-by: Codex:gpt-5-4
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Validation inside a UML guest on current mainline:
- An unprivileged local task (uid=65534, no CAP_NET_ADMIN) opens a
plain NETLINK_ROUTE socket, preloads sk_rmem_alloc with echoed
NLMSG_ERROR replies from an unsupported rtnetlink type, then issues
RTM_GETLINK | NLM_F_DUMP | NLM_F_ACK.
- Stock kernel: the initial __netlink_dump_start() hits the rmem gate
and returns via errout_skb with cb_running stuck at 1 until
recvmsg() or close() drives forward progress.
- Patched kernel: the same probe leaves cb_running clear immediately
on the lock_taken=true failure, and the larger-rcvbuf continuation
path (legitimate dump in progress) is unchanged.
A scaling pass on 3500 such wedged sockets in a 256M UML guest shows
about 3.8-3.9 MiB of extra unreclaimable slab (/proc/meminfo
SUnreclaim) beyond the visible queued rmem on the vulnerable kernel,
roughly 1.1 KiB/socket. Real accumulation, but the test hits
RLIMIT_NOFILE long before the guest approaches OOM, so this still
looks like a local availability cleanup rather than an exhaustion
primitive.
No Cc: stable@ on the theory that the bug self-heals on
recvmsg()/close and the accumulation is mild. Happy to add it and
route to net if you'd rather see it backported.
net/netlink/af_netlink.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4d609d5cf406..7019c17e6879 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2250,6 +2250,20 @@ static int netlink_dump_done(struct netlink_sock *nlk, struct sk_buff *skb,
return 0;
}
+static void netlink_dump_cleanup(struct netlink_sock *nlk)
+{
+ struct module *module = nlk->cb.module;
+ struct sk_buff *skb = nlk->cb.skb;
+
+ if (nlk->cb.done)
+ nlk->cb.done(&nlk->cb);
+
+ WRITE_ONCE(nlk->cb_running, false);
+ mutex_unlock(&nlk->nl_cb_mutex);
+ module_put(module);
+ consume_skb(skb);
+}
+
static int netlink_dump(struct sock *sk, bool lock_taken)
{
struct netlink_sock *nlk = nlk_sk(sk);
@@ -2258,7 +2272,6 @@ static int netlink_dump(struct sock *sk, bool lock_taken)
struct sk_buff *skb = NULL;
unsigned int rmem, rcvbuf;
size_t max_recvmsg_len;
- struct module *module;
int err = -ENOBUFS;
int alloc_min_size;
int alloc_size;
@@ -2366,19 +2379,14 @@ static int netlink_dump(struct sock *sk, bool lock_taken)
else
__netlink_sendskb(sk, skb);
- if (cb->done)
- cb->done(cb);
-
- WRITE_ONCE(nlk->cb_running, false);
- module = cb->module;
- skb = cb->skb;
- mutex_unlock(&nlk->nl_cb_mutex);
- module_put(module);
- consume_skb(skb);
+ netlink_dump_cleanup(nlk);
return 0;
errout_skb:
- mutex_unlock(&nlk->nl_cb_mutex);
+ if (lock_taken)
+ netlink_dump_cleanup(nlk);
+ else
+ mutex_unlock(&nlk->nl_cb_mutex);
kfree_skb(skb);
return err;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net 1/4] xsk: avoid skb leak in XDP_TX_METADATA case
From: Stanislav Fomichev @ 2026-04-20 16:27 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, horms, andrew+netdev, bpf, netdev, Jason Xing
In-Reply-To: <aeZI3ig6w0PhGaVU@devvm17672.vll0.facebook.com>
On 04/20, Stanislav Fomichev wrote:
> On 04/20, Stanislav Fomichev wrote:
> > On 04/18, Jason Xing wrote:
> > > From: Jason Xing <kernelxing@tencent.com>
> > >
> > > Fix it by explicitly adding kfree_skb() before returning back to its
> > > caller.
> > >
> > > How to reproduce it in virtio_net:
> > > 1. the current skb is the first one (which means no frag and xs->skb is
> > > NULL) and users enable metadata feature.
> > > 2. xsk_skb_metadata() returns a error code.
> > > 3. the caller xsk_build_skb() clears skb by using 'skb = NULL;'.
> > > 4. there is no chance to free this skb anymore.
> > >
> > > Closes: https://lore.kernel.org/all/20260415085204.3F87AC19424@smtp.kernel.org/
> > > Fixes: 30c3055f9c0d ("xsk: wrap generic metadata handling onto separate function")
> > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> >
> > Acked-by: Stanislav Fomichev <sdf@fomichev.me>
>
> Actually, I take that back.. While looking at patch 2 (which always
> confuses me with that -EOVERFLOW handling), looks like we set
> skb->destructor in xsk_skb_init_misc? So this kfree will do
> xsk_cq_submit_addr_locked? Not sure that's what we want? Should we
> move xsk_skb_init_misc to happen after xsk_skb_metadata?
Ooops, looks like you already addressed these in v2? Let me look into
that..
^ permalink raw reply
* Re: [PATCH net 1/1] net/rose: hold listener socket during call request handling
From: Simon Horman @ 2026-04-20 16:26 UTC (permalink / raw)
To: Ren Wei
Cc: linux-hams, netdev, davem, edumazet, kuba, pabeni, kees, takamitz,
kuniyu, jiayuan.chen, mingo, stanksal, jlayton, yifanwucs,
tomapufckgml, bird, yuantan098, tonanli66
In-Reply-To: <52776256bf0fc38de92fe3edf39434538b672b69.1776327338.git.tonanli66@gmail.com>
On Fri, Apr 17, 2026 at 07:01:51PM +0800, Ren Wei wrote:
> From: Nan Li <tonanli66@gmail.com>
>
> The call request receive path keeps using the listener socket after the
> lookup lock has been dropped. Keep the listener alive across the
> remaining validation and child socket setup by taking a reference in the
> lookup path and releasing it once request handling is finished.
>
> This makes listener lifetime handling explicit and avoids races with
> concurrent socket teardown.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@kernel.org
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Nan Li <tonanli66@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/rose/af_rose.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
Reviewed-by: Simon Horman <horms@kernel.org>
Sachiko has provided some feedback on this patch.
I do not believe they relate to shortcomings in this patch,
and I do not believe they should block progress of this patch.
You may want to look over them for areas to investigate as follow-up
(maybe you already did :)
...
^ permalink raw reply
* Re: Question/proposal for DPLL NCO (DCO) mode
From: Ivan Vecera @ 2026-04-20 16:24 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev@vger.kernel.org, Arkadiusz Kubalewski, Vadim Fedorenko,
Jakub Kicinski
In-Reply-To: <3rgm35qzwvzdrubvtdrccl3sb5cx2ufiy7b5wnjun223bosi45@2bnbfrlqnsbk>
On 4/20/26 3:43 PM, Jiri Pirko wrote:
> Mon, Apr 20, 2026 at 01:42:29PM +0200, ivecera@redhat.com wrote:
>> Hi all,
>>
>> I am currently working on adding PTP clock support (PHC) to the ZL3073x
>> driver, and I would like to discuss an architectural addition to the
>> DPLL subsystem enum dpll_mode before sending the formal patch series.
>>
>> To support IEEE 1588 PTP, the hardware DPLL must be decoupled from
>> tracking physical reference pins. Instead, its output frequency needs to
>> be continuously steered by a software PTP stack (e.g., linuxptp) using
>> the .adjfine() callback. In the industry, this specific hardware state
>> is widely known as NCO (Numerically Controlled Oscillator) or DCO
>> (Digitally Controlled Oscillator) mode.
>>
>> Currently, the DPLL subsystem defines two modes in enum dpll_mode:
>>
>> MANUAL: The user explicitly selects a physical input pin to track.
>>
>> AUTOMATIC: The hardware automatically selects the best physical input pin
>> based on priorities.
>>
>> Neither of these accurately represents the NCO/DCO state, where physical
>> pins are ignored, and the loop is fully software-steered.
>
> The manual/automatic mode is defining strategy/behaviour about how the
> input pins are selected.
>
> <header_quote>
> * enum dpll_mode - working modes a dpll can support, differentiates if and how
> * dpll selects one of its inputs to syntonize with it
> </header_quote>
>
> You don't want to change the strategy. You just
> don't want that/don't care. Why it make sense to add a mode then?
It depends on the perspective. NCO is a selection strategy where the
DPLL does not lock onto an input reference (select nothing); instead,
its frequency is software-driven.
Btw. we’ve included DPLL_MODE_DETACHED in the documentation, which could
describe this use case.
But...
> I was thinking exposing this over STATUS. We have:
> UNLOCKED (free running)
> LOCKED
> LOCKED_HO_ACQ
> HOLDOVER
>
> So something maybe like SW_STEERED? But:
>
> The problem is you need to do selection. Perhaps we can have a
> "magic pin" to select for this :S ? We have pin of type
> DPLL_PIN_TYPE_INT_OSCILLATOR already. Perhaps we can have
> DPLL_PIN_TYPE_INT_NCO/NDO? It's a source.
>
> Makes sense?
Yes, this makes sense from a selection standpoint, and I have to say I
like the idea. It also has an additional benefit: if we have an NCO pin
type, that pin's frequency can be used to configure the delta frequency
offset of the DPLL device itself.
I’ll proceed this way. Thanks for the advice!
Ivan
^ permalink raw reply
* [PATCH net 2/2] selftests: mptcp: add a check for sndbuf of S/C
From: Matthieu Baerts (NGI0) @ 2026-04-20 16:19 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Gang Yan,
Shuah Khan, linux-kselftest
In-Reply-To: <20260420-net-mptcp-sync-sndbuf-accept-v1-0-e3523e3aeb44@kernel.org>
From: Gang Yan <yangang@kylinos.cn>
Add a new chk_sndbuf() helper to diag.sh that extracts the sndbuf
(the 'tb' field from 'ss -m' skmem output) for both server and
client MPTCP sockets, and verifies they are equal.
Without the previous patch, it will fail:
'''
07 ....chk sndbuf server/client [FAIL] sndbuf S=20480 != C=2630656
'''
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
To: Shuah Khan <shuah@kernel.org>
Cc: linux-kselftest@vger.kernel.org
---
tools/testing/selftests/net/mptcp/diag.sh | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/tools/testing/selftests/net/mptcp/diag.sh b/tools/testing/selftests/net/mptcp/diag.sh
index d847ff1737c3..27cbda68144e 100755
--- a/tools/testing/selftests/net/mptcp/diag.sh
+++ b/tools/testing/selftests/net/mptcp/diag.sh
@@ -322,6 +322,33 @@ wait_connected()
done
}
+chk_sndbuf()
+{
+ local server_sndbuf client_sndbuf msg
+ local port=${1}
+
+ msg="....chk sndbuf server/client"
+ server_sndbuf=$(ss -N "${ns}" -inmHM "sport" "${port}" | \
+ sed -n 's/.*tb\([0-9]\+\).*/\1/p')
+ client_sndbuf=$(ss -N "${ns}" -inmHM "dport" "${port}" | \
+ sed -n 's/.*tb\([0-9]\+\).*/\1/p')
+
+ mptcp_lib_print_title "${msg}"
+ if [ -z "${server_sndbuf}" ] || [ -z "${client_sndbuf}" ]; then
+ mptcp_lib_pr_fail "sndbuf S=${server_sndbuf} C=${client_sndbuf}"
+ mptcp_lib_result_fail "${msg}"
+ ret=${KSFT_FAIL}
+ elif [ "${server_sndbuf}" != "${client_sndbuf}" ]; then
+ mptcp_lib_pr_fail "sndbuf S=${server_sndbuf} != C=${client_sndbuf}"
+ mptcp_lib_result_fail "${msg}"
+ ret=${KSFT_FAIL}
+ else
+ mptcp_lib_pr_ok
+ mptcp_lib_result_pass "${msg}"
+ fi
+}
+
+
trap cleanup EXIT
mptcp_lib_ns_init ns
@@ -341,6 +368,7 @@ echo "b" | \
127.0.0.1 >/dev/null &
wait_connected $ns 10000
chk_msk_nr 2 "after MPC handshake"
+chk_sndbuf 10000
chk_last_time_info 10000
chk_msk_remote_key_nr 2 "....chk remote_key"
chk_msk_fallback_nr 0 "....chk no fallback"
--
2.53.0
^ permalink raw reply related
* [PATCH net 1/2] mptcp: sync the msk->sndbuf at accept() time
From: Matthieu Baerts (NGI0) @ 2026-04-20 16:19 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Gang Yan,
stable
In-Reply-To: <20260420-net-mptcp-sync-sndbuf-accept-v1-0-e3523e3aeb44@kernel.org>
From: Gang Yan <yangang@kylinos.cn>
On passive MPTCP connections, the msk sndbuf is not updated correctly.
The root cause is an order issue in the accept path:
- tcp_check_req() -> subflow_syn_recv_sock() -> mptcp_sk_clone_init()
calls __mptcp_propagate_sndbuf() to copy the ssk sndbuf into msk
- Later, tcp_child_process() -> tcp_init_transfer() ->
tcp_sndbuf_expand() grows the ssk sndbuf.
So __mptcp_propagate_sndbuf() runs before the ssk sndbuf has been
expanded and the msk ends up with a much smaller sndbuf than the
subflow:
MPTCP: msk->sndbuf:20480, msk->first->sndbuf:2626560
Fix this by moving the __mptcp_propagate_sndbuf() call from
mptcp_sk_clone_init() -- the ssk sndbuf is not yet finalized there -- to
__mptcp_propagate_sndbuf() at accept() time, when the ssk sndbuf has
been fully expanded by tcp_sndbuf_expand().
Fixes: 8005184fd1ca ("mptcp: refactor sndbuf auto-tuning")
Cc: stable@vger.kernel.org
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/602
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index fbffd3a43fe8..718e910ff23f 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3594,7 +3594,6 @@ struct sock *mptcp_sk_clone_init(const struct sock *sk,
* uses the correct data
*/
mptcp_copy_inaddrs(nsk, ssk);
- __mptcp_propagate_sndbuf(nsk, ssk);
mptcp_rcv_space_init(msk, ssk);
msk->rcvq_space.time = mptcp_stamp();
@@ -4252,6 +4251,7 @@ static int mptcp_stream_accept(struct socket *sock, struct socket *newsock,
mptcp_graft_subflows(newsk);
mptcp_rps_record_subflows(msk);
+ __mptcp_propagate_sndbuf(newsk, mptcp_subflow_tcp_sock(subflow));
/* Do late cleanup for the first subflow as necessary. Also
* deal with bad peers not doing a complete shutdown.
--
2.53.0
^ permalink raw reply related
* [PATCH net 0/2] mptcp: sync the msk->sndbuf at accept() time
From: Matthieu Baerts (NGI0) @ 2026-04-20 16:19 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0), Gang Yan,
stable, Shuah Khan, linux-kselftest
On passive MPTCP connections, the MPTCP socket send buffer doesn't have
the expected size at accept() time.
Patch 1 fixes the regression introduced in v6.7, while the following one
validates the fix in the selftests.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Gang Yan (2):
mptcp: sync the msk->sndbuf at accept() time
selftests: mptcp: add a check for sndbuf of S/C
net/mptcp/protocol.c | 2 +-
tools/testing/selftests/net/mptcp/diag.sh | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletion(-)
---
base-commit: 0cf004ffb61cd32d140531c3a84afe975f9fc7ea
change-id: 20260420-net-mptcp-sync-sndbuf-accept-5079a6f9c407
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* AW: pre-boot plugged SFP autoneg advertisement
From: markus.stockhausen @ 2026-04-20 16:16 UTC (permalink / raw)
To: 'Andrew Lunn'
Cc: linux, hkallweit1, netdev, 'Jonas Jelonek', jan, nbd,
'Daniel Golle'
In-Reply-To: <90958cc3-e291-44ff-8fc3-102c0f62a269@lunn.ch>
> Von: markus.stockhausen@gmx.de <markus.stockhausen@gmx.de>
> Gesendet: Sonntag, 19. April 2026 10:49
> An: 'Andrew Lunn' <andrew@lunn.ch>
> Betreff: AW: pre-boot plugged SFP autoneg advertisement
>
> Took that hint/question and digged deeper. Added further debug
> to each and every linkmode_copy. I think I found the culprit in
> a userspace ethtool call. For now I assume OpenWrt netifd.
Hi Andrew,
once again thanks for your help. After further investigation I hopefully can
add
more details. I think I got the whole picture now. So some additional
background
information about the environment.
- Realtek RTL930x devices with SFP+ module slots
- These are driven directly by a SerDes (controlled by downstream PCS
driver)
- The DTS reads
port11: port@11 {
reg = <11>;
label = "lan12" ;
pcs-handle = <&serdes8>;
phy-mode = "1000base-x";
sfp = <&sfp1>;
managed = "in-band-status";
};
Sequence of events during boot is as follows:
- SFP module is already inserted (in my case 1G)
- phylink_sfp_config_phy() runs long before any network config starts
- OpenWrt netifd daemon starts and wants to configure the network interfaces
- It reads current settings via ethtool ioctl and gets autoneg=off
- It writes basic config values via ethtool ioctl including autneg=off
- Later on it starts the interface and phylink_start() is issued
With my limited knowledge I would patch phylink_ethtool_ksettings_get().
/* The MAC is reporting the link results from its own PCS
* layer via in-band status. Report these as the current
* link settings.
*/
phylink_get_ksettings(&link_state, kset);
break;
+ case MLO_AN_PHY:
+ /* SFP module present at boot but phylink not yet started.
+ * Return autonegotiation as set by
phylink_sfp_config_phy().
+ */
+ if (pl->sfp_bus && !pl->phydev)
+ kset->base.autoneg =
+
linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
+
pl->link_config.advertising)
+ ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+ break;
}
return 0;
}
This comes from the observation that
- pl->link_config.advertising is filled by phylink_sfp_set_config()
- state MLO_AN_PHY is reported before phylink_start()
- state MLO_AN_INBAND is reported after phylink_start()
Is this reasonable or am I totally off?
Markus
^ permalink raw reply
* [PATCH bpf] bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths
From: Weiming Shi @ 2026-04-20 16:14 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Martin KaFai Lau, Alexei Starovoitov, Amery Hung,
Leon Hwang, Kees Cook, Fushuai Wang, Menglong Dong, netdev, bpf,
Xiang Mei, Weiming Shi
bpf_selem_unlink_nofail() sets SDATA(selem)->smap to NULL before
removing the selem from the storage hlist. A concurrent RCU reader in
bpf_sk_storage_clone() can observe the selem still on the list with
smap already NULL, causing a NULL pointer dereference.
general protection fault, probably for non-canonical address 0xdffffc000000000a:
KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
RIP: 0010:bpf_sk_storage_clone+0x1cd/0xaa0 net/core/bpf_sk_storage.c:174
Call Trace:
<IRQ>
sk_clone+0xfed/0x1980 net/core/sock.c:2591
inet_csk_clone_lock+0x30/0x760 net/ipv4/inet_connection_sock.c:1222
tcp_create_openreq_child+0x35/0x2680 net/ipv4/tcp_minisocks.c:571
tcp_v4_syn_recv_sock+0x123/0xf90 net/ipv4/tcp_ipv4.c:1729
tcp_check_req+0x8e1/0x2580 include/net/tcp.h:855
tcp_v4_rcv+0x1845/0x3b80 net/ipv4/tcp_ipv4.c:2347
While at it, also add NULL checks in bpf_sk_storage_diag_put_all() and
diag_get() which have the same unprotected dereference pattern and could
theoretically hit the same race during an inet_diag dump.
Fixes: 5d800f87d0a5 ("bpf: Support lockless unlink when freeing map or local storage")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/core/bpf_sk_storage.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index f8338acebf077..3b487280f50fa 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -172,7 +172,7 @@ int bpf_sk_storage_clone(const struct sock *sk, struct sock *newsk)
struct bpf_map *map;
smap = rcu_dereference(SDATA(selem)->smap);
- if (!(smap->map.map_flags & BPF_F_CLONE))
+ if (!smap || !(smap->map.map_flags & BPF_F_CLONE))
continue;
/* Note that for lockless listeners adding new element
@@ -547,6 +547,8 @@ static int diag_get(struct bpf_local_storage_data *sdata, struct sk_buff *skb)
return -EMSGSIZE;
smap = rcu_dereference(sdata->smap);
+ if (!smap)
+ goto errout;
if (nla_put_u32(skb, SK_DIAG_BPF_STORAGE_MAP_ID, smap->map.id))
goto errout;
@@ -599,6 +601,8 @@ static int bpf_sk_storage_diag_put_all(struct sock *sk, struct sk_buff *skb,
saved_len = skb->len;
hlist_for_each_entry_rcu(selem, &sk_storage->list, snode) {
smap = rcu_dereference(SDATA(selem)->smap);
+ if (!smap)
+ continue;
diag_size += nla_value_size(smap->map.value_size);
if (nla_stgs && diag_get(SDATA(selem), skb))
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 3/3] dts: s32g: Add GPR syscon region
From: Jared Kangas @ 2026-04-20 16:04 UTC (permalink / raw)
To: Dan Carpenter
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, imx,
devicetree, linux-kernel, linaro-s32, netdev
In-Reply-To: <aeKn2dvOOO43zdev@jkangas-thinkpadp1gen3.rmtuswa.csb>
Fixing Dan's address based on mailmap update, sorry for the noise.
On Fri, Apr 17, 2026 at 02:36:25PM -0700, Jared Kangas wrote:
> Hi Dan,
>
> On Fri, Jan 30, 2026 at 04:19:52PM +0300, Dan Carpenter wrote:
> > Add the GPR syscon region for the s32 chipset.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> > ---
> >
> > [snip]
> >
> > diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > index e314f3c7d61d..be03db737384 100644
> > --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> > @@ -383,6 +383,11 @@ usdhc0-200mhz-grp4 {
> > };
> > };
> >
> > + gpr: syscon@4007c000 {
> > + compatible = "nxp,s32g3-gpr", "syscon";
> > + reg = <0x4007c000 0x3000>;
> > + };
> > +
> > ocotp: nvmem@400a4000 {
> > compatible = "nxp,s32g3-ocotp", "nxp,s32g2-ocotp";
> > reg = <0x400a4000 0x400>;
> > @@ -808,6 +813,7 @@ gmac0: ethernet@4033c000 {
> > compatible = "nxp,s32g2-dwmac";
> > reg = <0x4033c000 0x2000>, /* gmac IP */
> > <0x4007c004 0x4>; /* GMAC_0_CTRL_STS */
> > + nxp,phy-sel = <&gpr 0x4>;
> > interrupt-parent = <&gic>;
> > interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> > interrupt-names = "macirq";
>
> I gave this a test on an S32G-VNP-RDB3 and didn't see any issues on the
> dwmac-s32 side, but this appears to trigger a panic when reading the new
> debugfs regmap/*/registers file for the syscon node:
>
> # grep 4007c000 /proc/vmallocinfo
> 0xffff800083da8000-0xffff800083dac000 16384 ioremap_prot+0x74/0xe0 phys=0x000000004007c000 ioremap
> # cat /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers
> Internal error: synchronous external abort: 0000000096000210 [#1] SMP
> [...]
> CPU: 0 UID: 0 PID: 4344 Comm: cat Tainted: G M E X ------ --- 6.12.0+ #226 PREEMPT_RT
> Tainted: [M]=MACHINE_CHECK, [E]=UNSIGNED_MODULE, [X]=AUX
> [...]
> pc : regmap_mmio_read32le+0x44/0xa0
> lr : regmap_mmio_read32le+0x44/0xa0
> [...]
> x23: ffff00080c080000 x22: ffff000802ac4c00 x21: ffff800087b13c9c
> x20: ffff800080a46494 x19: ffff800083da810c x18: 0000000000000004
> [...]
> x5 : ffff800080a46448 x4 : ffff800083da8000 x3 : ffff800080a46494
> x2 : ffff800080a47230 x1 : ffff800083da810c x0 : 0000000000000020
> Call trace:
> regmap_mmio_read32le+0x44/0xa0 (P)
> regmap_mmio_read+0x4c/0x80
> [...]
> Code: 52800400 8b214093 aa1303e1 97f4caf0 (b9400275)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: synchronous external abort: Fatal exception
>
> Running this through decodecode gives:
>
> All code
> ========
> 0: 52800400 mov w0, #0x20 // #32
> 4: 8b214093 add x19, x4, w1, uxtw
> 8: aa1303e1 mov x1, x19
> c: 97f4caf0 bl 0xffffffffffd32bcc
> 10:* b9400275 ldr w21, [x19] <-- trapping instruction
>
> Code starting with the faulting instruction
> ===========================================
> 0: b9400275 ldr w21, [x19]
>
> x19's offset from the base address in /proc/vmallocinfo is 0x10c, which
> points to a bad read at physical address 0x4007c10c; I also confirmed
> that the preceding memory reads back without issues:
>
> # head -c 990 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> 0104: 00000000
> # head -c 1005 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> 0108: 00000000
> # head -c 1020 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
> <panic>
>
> Best,
> Jared
>
^ permalink raw reply
* Re: [PATCH iwl-net 4/4] ice: report EIPE checksum errors to the OS on E830
From: Simon Horman @ 2026-04-20 15:57 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jan Glaza
In-Reply-To: <20260417062954.1241900-5-aleksandr.loktionov@intel.com>
On Fri, Apr 17, 2026 at 08:29:54AM +0200, Aleksandr Loktionov wrote:
> From: Jan Glaza <jan.glaza@intel.com>
>
> For E830 adapters the hardware-reported EIPE (Ethernet Inline IPsec
> Engine) error is a reliable indication that a received packet failed
> decryption and has a bad checksum. Route EIPE errors through the
> generic checksum error path on E830 so the error is visible via
> standard ethtool statistics (rx_csum_bad).
>
> On previous devices (E810, E82X) the EIPE flag can be spuriously set
> on encapsulated packets with inner L2 padding, so those adapters only
> increment the driver-private hw_rx_eipe_error counter without routing
> through the checksum error path.
>
> Fixes: 0ca6755f3cc2 ("ice: Add a new counter for Rx EIPE errors")
> Signed-off-by: Jan Glaza <jan.glaza@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Sashiko has provided review of this patch. However, I don't believe any of
the issues flagged there should block progress of this patch.
You may wish to look over that review for possible follow-up activity.
^ permalink raw reply
* Re: [PATCH iwl-net 3/4] ice: support RDMA on 4+-port E830 devices
From: Simon Horman @ 2026-04-20 15:56 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: 'Simon Horman', intel-wired-lan, anthony.l.nguyen, netdev,
jan.glaza
In-Reply-To: <20260417062954.1241900-4-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ice: support RDMA on 4+-port E830 devices
This patch narrows the RDMA capability check to keep RDMA enabled for E830
devices configured with more than 4 ports, as they do not share the
limitations of E810 and E82X devices.
> diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> --- a/drivers/net/ethernet/intel/ice/ice_common.c
> +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> @@ -2509,7 +2509,7 @@ ice_recalc_port_limited_caps(struct ice_hw *hw, struct ice_hw_common_caps *caps)
> caps->maxtc = 4;
> ice_debug(hw, ICE_DBG_INIT, "reducing maxtc to %d (based on #ports)\n",
> caps->maxtc);
> - if (caps->rdma) {
> + if (caps->rdma && hw->mac_type != ICE_MAC_E830) {
> ice_debug(hw, ICE_DBG_INIT, "forcing RDMA off\n");
> caps->rdma = 0;
> }
Does this leave the diagnostic message further down out of sync with the
new condition?
If the device is an E830 with more than 4 ports, RDMA remains enabled, but
because the dev_info() call just below this block is evaluated for all
devices with more than 4 ports:
ice_recalc_port_limited_caps() {
if (hw->dev_caps.num_funcs > 4) {
...
if (caps->rdma && hw->mac_type != ICE_MAC_E830) {
ice_debug(hw, ICE_DBG_INIT, "forcing RDMA off\n");
caps->rdma = 0;
}
/* print message only when processing device capabilities
* during initialization.
*/
if (caps == &hw->dev_caps.common_cap)
dev_info(ice_hw_to_dev(hw), "RDMA functionality is not available with the current device configuration.\n");
}
}
Could this cause confusion by logging a warning about RDMA being disabled
when it is actually active?
^ permalink raw reply
* Re: [PATCH iwl-net 2/4] ice: fix autoneg disable when link partner doesn't support AN
From: Simon Horman @ 2026-04-20 15:54 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Konrad Knitter
In-Reply-To: <20260417062954.1241900-3-aleksandr.loktionov@intel.com>
On Fri, Apr 17, 2026 at 08:29:52AM +0200, Aleksandr Loktionov wrote:
> From: Konrad Knitter <konrad.knitter@intel.com>
>
> Disabling autonegotiation was silently ignored when autoneg had not yet
> completed (ICE_AQ_AN_COMPLETED was not set), leaving the configuration
> unchanged with no error. This could prevent link from forming if the
> link partner requires non-autoneg mode.
>
> Extend the condition to also allow disabling autoneg when the link
> partner reports no AN ability (ICE_AQ_LP_AN_ABILITY clear). Gate the
> ICE_AQ_LP_AN_ABILITY check on the link being up so that stale or
> zeroed an_info when link is down does not produce a false positive.
> Introduce the helper ice_autoneg_disable_allowed() to make the check
> explicit.
>
> Fixes: f1a4a66d2310 ("ice: fix set pause param autoneg check")
AI generated code review [1] flags that this does not seem to be
the right Fixes tag and that the following seems more appropriate:
Fixes: 48cb27f2fd18 ("ice: Implement handlers for ethtool PHY/link operations")
[1] https://netdev-ai.bots.linux.dev/ai-local.html
> Signed-off-by: Konrad Knitter <konrad.knitter@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
The above not withstanding, this looks looks to me:
Reviewed-by: Simon Horman <horms@kernel.org>
I somehow feel obliged to acknowledge that Sashiko has provided
review of this patch. However, I don't believe any of the
issues flagged there should block progress of this patch.
You may wish to look over that review for possible follow-up activity.
...
^ permalink raw reply
* Re: [PATCH net 2/4] xsk: free the skb when hitting the upper bound MAX_SKB_FRAGS
From: Stanislav Fomichev @ 2026-04-20 15:44 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, horms, andrew+netdev, bpf, netdev, Jason Xing
In-Reply-To: <20260418045644.28612-3-kerneljasonxing@gmail.com>
On 04/18, Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> Fix it by explicitly adding kfree_skb() before returning back to its
> caller.
>
> How to reproduce it in virtio_net:
> 1. the current skb is the first one (which means xs->skb is NULL) and
> hit the limit MAX_SKB_FRAGS.
> 2. xsk_build_skb_zerocopy() returns -EOVERFLOW.
> 3. the caller xsk_build_skb() clears skb by using 'skb = NULL;'. This
> is why bug can be triggered.
> 4. there is no chance to free this skb anymore.
>
> Note that if in this case the xs->skb is not NULL, xsk_build_skb() will
> call xsk_drop_skb(xs->skb) to do the right thing.
>
> Fixes: cf24f5a5feea ("xsk: add support for AF_XDP multi-buffer on Tx path")
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/xsk.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 8fcde34aec7b..5d3dbb118730 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -778,8 +778,11 @@ static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock *xs,
> addr = buffer - pool->addrs;
>
> for (copied = 0, i = skb_shinfo(skb)->nr_frags; copied < len; i++) {
> - if (unlikely(i >= MAX_SKB_FRAGS))
> + if (unlikely(i >= MAX_SKB_FRAGS)) {
> + if (!xs->skb)
> + kfree_skb(skb);
> return ERR_PTR(-EOVERFLOW);
> + }
>
> page = pool->umem->pgs[addr >> PAGE_SHIFT];
> get_page(page);
> --
> 2.41.3
>
As mentioned for patch 1, need to do something with that
xsk_skb_init_misc... Otherwise we hit destructor with xsk_cq_submit_addr_locked
here as well
^ permalink raw reply
* Re: [PATCH net 1/4] xsk: avoid skb leak in XDP_TX_METADATA case
From: Stanislav Fomichev @ 2026-04-20 15:42 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, horms, andrew+netdev, bpf, netdev, Jason Xing
In-Reply-To: <aeZEjZSsVIdpcbFF@devvm17672.vll0.facebook.com>
On 04/20, Stanislav Fomichev wrote:
> On 04/18, Jason Xing wrote:
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > Fix it by explicitly adding kfree_skb() before returning back to its
> > caller.
> >
> > How to reproduce it in virtio_net:
> > 1. the current skb is the first one (which means no frag and xs->skb is
> > NULL) and users enable metadata feature.
> > 2. xsk_skb_metadata() returns a error code.
> > 3. the caller xsk_build_skb() clears skb by using 'skb = NULL;'.
> > 4. there is no chance to free this skb anymore.
> >
> > Closes: https://lore.kernel.org/all/20260415085204.3F87AC19424@smtp.kernel.org/
> > Fixes: 30c3055f9c0d ("xsk: wrap generic metadata handling onto separate function")
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
>
> Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Actually, I take that back.. While looking at patch 2 (which always
confuses me with that -EOVERFLOW handling), looks like we set
skb->destructor in xsk_skb_init_misc? So this kfree will do
xsk_cq_submit_addr_locked? Not sure that's what we want? Should we
move xsk_skb_init_misc to happen after xsk_skb_metadata?
^ permalink raw reply
* Re: [PATCH iwl-net 1/4] ice: fix asymmetric pause negotiation reporting in ethtool
From: Simon Horman @ 2026-04-20 15:40 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Tomasz Lichwala
In-Reply-To: <20260417062954.1241900-2-aleksandr.loktionov@intel.com>
On Fri, Apr 17, 2026 at 08:29:51AM +0200, Aleksandr Loktionov wrote:
> From: Tomasz Lichwala <tomasz.lichwala@intel.com>
>
> Add Asym_Pause to the supported link modes so that asymmetric pause
> negotiation is properly reported via ethtool. Without Asym_Pause in
> the supported modes, 'ethtool -a' incorrectly shows 'RX/TX negotiated: off'
> for asymmetric pause configurations, even when pause is properly
> negotiated and functional at the hardware level.
>
> Fixes: 5a056cd7ead2 ("ice: add lp_advertising flow control support")
> Signed-off-by: Tomasz Lichwala <tomasz.lichwala@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net 0/2] tcp: symmetric challenge ACK for SEG.ACK > SND.NXT
From: Jiayuan Chen @ 2026-04-20 15:38 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, David Ahern, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260420082454.1b85cd94@kernel.org>
On 4/20/26 11:24 PM, Jakub Kicinski wrote:
> AI says:
>
> Your patch "tcp: send a challenge ACK on SEG.ACK > SND.NXT" breaks an
> existing packetdrill selftest:
>
> selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt
>
> Test output:
> tcp_ts_recent_invalid_ack.pkt:25: error handling packet:
> live packet field tcp_ack_seq: expected: 1001 (0x3e9) vs actual: 1 (0x1)
> script packet: 0.200125 . 1:1(0) ack 1001 <nop,nop,TS val 200 ecr 201>
> actual packet: 0.200119 . 1:1(0) ack 1 win 65535 <nop,nop,TS val 200 ecr 200>
> not ok 1 ipv4
> not ok 2 ipv6
> not ok 3 ipv4-mapped-ipv6
>
> Root cause:
>
> The test `tcp_ts_recent_invalid_ack.pkt` sends a FIN+ACK with ACK=9999
> (which exceeds SND.NXT=1) to verify that the kernel does not update ts_recent
> from an invalid packet. Before your patch, this packet was silently dropped.
> After your patch, the kernel now emits a challenge ACK (SEQ=1, ACK=1) in
> response to the ACK=9999 segment.
>
> The test script does not expect this challenge ACK, so when it subsequently
> tries to match the expected "ack 1001" response to the following data segment,
> it instead sees the challenge ACK "ack 1", causing a mismatch on all three
> address families (ipv4, ipv6, ipv4-mapped-ipv6).
>
> Fix: update `tcp_ts_recent_invalid_ack.pkt` to consume the new challenge ACK
> before checking the response to the subsequent data segment. For example,
> add after the bad FIN+ACK line:
>
> +0 > . 1:1(0) ack 1
>
> so that the challenge ACK is explicitly expected and the rest of the script
> proceeds as before.
Thanks Jakub, you're right.
Will fold the tcp_ts_recent_invalid_ack.pkt update into the kernel fix in v2
to keep bisect clean and makes the backport self-contained.
^ permalink raw reply
* Re: [PATCH iwl-next v2 3/3] igc: add support for forcing link speed without autonegotiation
From: Simon Horman @ 2026-04-20 15:35 UTC (permalink / raw)
To: Abdul Rahim, Faizal
Cc: khai.wen.tan, anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev,
davem, edumazet, kuba, pabeni, intel-wired-lan, netdev,
linux-kernel, faizal.abdul.rahim, hong.aun.looi, khai.wen.tan
In-Reply-To: <3481ae84-5c36-4591-94c1-78b70fff4d7b@linux.intel.com>
On Mon, Apr 20, 2026 at 11:20:07AM +0800, Abdul Rahim, Faizal wrote:
>
>
> On 19/4/2026 12:48 am, Simon Horman wrote:
> > From: 'Simon Horman' <horms@kernel.org>
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > Full review at: https://sashiko.dev
> > ---
> > igc: add support for forcing link speed without autonegotiation
> >
> > This commit adds support to allow users to force 10/100 Mb/s link speed
> > and duplex via ethtool when autonegotiation is disabled.
> >
> > > diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c
> > > index cfcbf2fdad6ea..5bd37d1be1688 100644
> > > --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
> > > +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
> >
> > [ ... ]
> >
> > > @@ -2000,6 +2013,41 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,
> > > return 0;
> > > }
> > > +/**
> > > + * igc_handle_autoneg_disabled - Configure forced speed/duplex settings
> > > + * @adapter: private driver structure
> > > + * @speed: requested speed (must be SPEED_10 or SPEED_100)
> > > + * @duplex: requested duplex
> > > + *
> > > + * Records forced speed/duplex when autoneg is disabled.
> > > + * Caller must validate speed before calling this function.
> > > + */
> > > +static void igc_handle_autoneg_disabled(struct igc_adapter *adapter, u32 speed,
> > > + u8 duplex)
> > > +{
> > > + struct igc_mac_info *mac = &adapter->hw.mac;
> > > +
> > > + switch (speed) {
> > > + case SPEED_10:
> > > + mac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?
> > > + IGC_FORCED_10F : IGC_FORCED_10H;
> > > + break;
> > > + case SPEED_100:
> > > + mac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?
> > > + IGC_FORCED_100F : IGC_FORCED_100H;
> > > + break;
> > > + default:
> > > + WARN_ONCE(1, "Unsupported speed %u\n", speed);
> > > + return;
> > > + }
> > > +
> > > + mac->autoneg_enabled = false;
> > > +
> > > + /* Half-duplex cannot support flow control per IEEE 802.3 */
> > > + if (duplex == DUPLEX_HALF)
> > > + adapter->hw.fc.requested_mode = igc_fc_none;
> > > +}
> >
> > If userspace issues an ethtool command without specifying duplex, the duplex
> > value can be DUPLEX_UNKNOWN. In this case, forced_speed_duplex correctly
> > defaults to half-duplex since duplex == DUPLEX_FULL evaluates to false.
> >
> > However, since DUPLEX_UNKNOWN is not equal to DUPLEX_HALF, the check above
> > fails, and the requested flow control mode remains unchanged. Could this leave
> > flow control enabled on a forced half-duplex link, violating IEEE 802.3?
> > Should this check be based on the resolved mac->forced_speed_duplex state
> > instead?
> >
>
> You're right, thanks for pointing that out.
>
> That said, it feels simpler to address it with [1]:
> if (duplex != DUPLEX_FULL)
> adapter->hw.fc.requested_mode = igc_fc_none;
>
> Rather than [2]:
> if (mac->forced_speed_duplex == IGC_FORCED_10H ||
> mac->forced_speed_duplex == IGC_FORCED_100H)
> adapter->hw.fc.requested_mode = igc_fc_none;
>
> Are you okay with [1] ?
Yes, [1] sounds sensible to me.
>
> > [ ... ]
> >
> > > @@ -2071,14 +2120,20 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,
> > > }
> > > }
> > > + if (cmd->base.autoneg == AUTONEG_DISABLE &&
> > > + cmd->base.speed != SPEED_10 && cmd->base.speed != SPEED_100) {
> > > + netdev_info(dev, "Unsupported speed for forced link\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > while (test_and_set_bit(__IGC_RESETTING, &adapter->state))
> > > usleep_range(1000, 2000);
> >
> > This isn't a bug introduced by this patch, but does this ad-hoc
> > synchronization using bit flags circumvent proper locking guarantees? The
> > networking subsystem guidelines forbid using bit flags as ad-hoc locks.
> >
> > Using a bit flag in a polling loop bypasses lockdep analysis, fairness, and
> > strict memory ordering. Could this be replaced with a real synchronization
> > mechanism like a mutex?
>
> It looks like a worthwhile cleanup. However, it likely doesn’t belong in
> this series, since the synchronization pattern predates these patches and is
> used throughout the igc driver (set_ringparam, set_pauseparam, set_channels,
> etc.). We could address it in different patch series and align the other
> code paths at the same time ?
Yes, agreed.
^ permalink raw reply
* Re: [net-next v2 2/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
From: Krzysztof Kozlowski @ 2026-04-20 15:33 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260417024523.107786-3-minda.chen@starfivetech.com>
On Fri, Apr 17, 2026 at 10:45:20AM +0800, Minda Chen wrote:
> Add StarFive JHB100 dwmac support and compatible.
> The JHB100 dwmac shares the same driver code as the JH7110 dwmac,
Please describe the hardware or programming interface, not driver code.
> which contains 2 SGMII interfaces, 1 RGMII/RMII interface and
> 1 RMII interface.
> JHB100 dwmac has only one reset signal and one main interrupt
> line.
Drop all below, not relevant.
>
> Please refer to below:
>
> JHB100: reset-names = "stmmaceth";
>
> Example usage of JHB100 in the device tree:
>
> gmac0: ethernet@11b80000 {
> compatible = "starfive,jhb100-dwmac",
> "snps,dwmac-5.20";
> interrupts = <225>;
> interrupt-names = "macirq";
> ...
> };
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> .../bindings/net/starfive,jh7110-dwmac.yaml | 23 +++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 38bc34dc4f09..85cd3252e8b1 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -115,6 +115,7 @@ properties:
> - sophgo,sg2044-dwmac
> - starfive,jh7100-dwmac
> - starfive,jh7110-dwmac
> + - starfive,jhb100-dwmac
> - tesla,fsd-ethqos
> - thead,th1520-gmac
>
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index 0d1962980f57..edc246a71ce3 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -18,6 +18,7 @@ select:
> enum:
> - starfive,jh7100-dwmac
> - starfive,jh7110-dwmac
> + - starfive,jhb100-dwmac
> required:
> - compatible
>
> @@ -30,6 +31,9 @@ properties:
> - items:
> - const: starfive,jh7110-dwmac
> - const: snps,dwmac-5.20
> + - items:
> + - const: starfive,jhb100-dwmac
So that's an enum in previous "items" list.... but your commit msg said
your devices are compatible, so confusing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Path forward for NFC in the kernel
From: Mark Greer @ 2026-04-20 15:31 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jakub Kicinski, Michael Thalmeier,
Raymond Hackley, Michael Walle, Bongsu Jeon, David Heidelberg
Cc: netdev
In-Reply-To: <9c4a4acf-b4f1-4e84-93bf-cdf080cb9970@kernel.org>
[Trying this again hopefully without HTML.]
On 4/17/26 12:18 AM, Krzysztof Kozlowski wrote:
> On 16/04/2026 19:10, Jakub Kicinski wrote:
>> Hi folks! We are struggling to keep up with the number of security
>> reports and AI generated patches in the kernel. NFC is infamous for
>> being a huge CVE magnet. We need someone to step up as a maintainer,
>> create an NFC tree and handle all the incoming submissions. Send us
>> (or Linus if you prefer) periodic PRs, like WiFi, Bluetooth etc. do.
>> If that does not happen I'm afraid we'll have to move the NFC code
>> out of the tree, put it up on GH or some such, and let it accumulate
>> CVEs there.. I'm planning to send a PR to Linus to shed the
>> unmaintained code early next week. We need to have a maintainer
>> established by then.
> +Cc David Heidelberg recently trying to use Linux NFC stack, Just
> "collecting" patches is not a big deal, I could do this, but actually
> reviewing the patches with necessary due diligence is the effort I
> could not provide in a reasonable time frame. And picking up patches
> without proper review feels risky... NFC has a long history of issues,
> first mostly pointed out by syzbot but now apparently by AI tools. The
> code base is quite old, with no major improvements or testings
> happening but not in a way "oh, it's stable and working like 'cp'
> command" but rather "no one knows how many bugs are on top of each
> other and if it actually still works". Syzbot and AI reported bugs
> encourage random drive-by fixes by people not testing the code, thus
> particular bug report might be fixed, but for example NFC stops
> working and no one knows that. Does anyone knows if the NFC
> stack/drivers actually works fine? Did anyone test actual devices? If
> not, then moving to Github would be even more reasonable. Another
> point is that AFAIU, most of real world devices, like Android-based
> phones, don't use the Linux NFC stack but their custom HAL/user-space
> based libraries and drivers. Some other non-Android projects use
> libnfc userspace, which seems to be maintained only as bugfix
> (https://github.com/nfc-tools/libnfc/commits/master/). Best regards,
> Krzysztof
That is my understanding too.
I would love to take this on but I've been swamped for years with my
"day job" and I'm pretty burned out.
Taking on something like this isn't possible for me. I also didn't
realize it was creating so many CVEs so,
yeah, sounds like it should be removed then. Thanks for all of the work
you did on this, Krzysztof.
Mark
--
^ permalink raw reply
* Re: [PATCH net 0/2] tcp: symmetric challenge ACK for SEG.ACK > SND.NXT
From: Jakub Kicinski @ 2026-04-20 15:24 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, David Ahern, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260420025428.101192-1-jiayuan.chen@linux.dev>
On Mon, 20 Apr 2026 10:54:07 +0800 Jiayuan Chen wrote:
> Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack
> Mitigation") quotes RFC 5961 Section 5.2 in full, which requires
> that any incoming segment whose ACK value falls outside
> [SND.UNA - MAX.SND.WND, SND.NXT] MUST be discarded and an ACK sent
> back. Linux currently sends that challenge ACK only on the lower
> edge (SEG.ACK < SND.UNA - MAX.SND.WND); on the symmetric upper edge
> (SEG.ACK > SND.NXT) the segment is silently dropped with
> SKB_DROP_REASON_TCP_ACK_UNSENT_DATA.
>
> Patch 1 completes the mitigation by emitting a rate-limited challenge
> ACK on that branch, reusing tcp_send_challenge_ack() and honouring
> FLAG_NO_CHALLENGE_ACK for consistency with the lower-edge case.
>
> Patch 2 adds a packetdrill selftest under
> tools/testing/selftests/net/packetdrill/ that verifies the new
> behaviour.
AI says:
Your patch "tcp: send a challenge ACK on SEG.ACK > SND.NXT" breaks an
existing packetdrill selftest:
selftests/net/packetdrill/tcp_ts_recent_invalid_ack.pkt
Test output:
tcp_ts_recent_invalid_ack.pkt:25: error handling packet:
live packet field tcp_ack_seq: expected: 1001 (0x3e9) vs actual: 1 (0x1)
script packet: 0.200125 . 1:1(0) ack 1001 <nop,nop,TS val 200 ecr 201>
actual packet: 0.200119 . 1:1(0) ack 1 win 65535 <nop,nop,TS val 200 ecr 200>
not ok 1 ipv4
not ok 2 ipv6
not ok 3 ipv4-mapped-ipv6
Root cause:
The test `tcp_ts_recent_invalid_ack.pkt` sends a FIN+ACK with ACK=9999
(which exceeds SND.NXT=1) to verify that the kernel does not update ts_recent
from an invalid packet. Before your patch, this packet was silently dropped.
After your patch, the kernel now emits a challenge ACK (SEQ=1, ACK=1) in
response to the ACK=9999 segment.
The test script does not expect this challenge ACK, so when it subsequently
tries to match the expected "ack 1001" response to the following data segment,
it instead sees the challenge ACK "ack 1", causing a mismatch on all three
address families (ipv4, ipv6, ipv4-mapped-ipv6).
Fix: update `tcp_ts_recent_invalid_ack.pkt` to consume the new challenge ACK
before checking the response to the subsequent data segment. For example,
add after the bad FIN+ACK line:
+0 > . 1:1(0) ack 1
so that the challenge ACK is explicitly expected and the rest of the script
proceeds as before.
^ permalink raw reply
* Re: [PATCH net v2] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
From: Jakub Kicinski @ 2026-04-20 15:23 UTC (permalink / raw)
To: Yi Chen
Cc: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Long Xin,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Shuah Khan, coreteam, netfilter-devel, linux-kselftest,
linux-kernel, netdev
In-Reply-To: <20260418195843.303946-1-yiche.cy@gmail.com>
On Sun, 19 Apr 2026 03:58:43 +0800 Yi Chen wrote:
> The existing test covered a scenario where a delayed INIT_ACK chunk
> updates the vtag in conntrack after the association has already been
> established.
AI says:
The conntrack_sctp_collision.sh selftest is now failing in the NIPA CI on
both the normal and debug kernel builds:
not ok 1 1 selftests: net/netfilter: conntrack_sctp_collision.sh # exit=1
# Test for SCTP INIT_ACK Collision in nf_conntrack:
# Invalid netns name ""
# Invalid netns name ""
The root cause is a shell variable scoping bug introduced by this patch.
The new test structure wraps `topo_setup` in a subshell:
(topo_setup && conf_delay $SERVER_NS link0 2) || exit $?
if ! do_test; then
...
fi
`topo_setup` calls `setup_ns CLIENT_NS SERVER_NS ROUTER_NS`, which sets
those variables inside the subshell. Those assignments do not propagate
back to the parent shell, so when `do_test` is called afterwards, both
`$SERVER_NS` and `$CLIENT_NS` expand to empty strings. The `ip net exec ""`
calls then fail with "Invalid netns name """.
The second test case (SCTP INIT Collision) would have the same problem.
The fix is to avoid the subshell or ensure the namespace variables are
visible to `do_test`. The simplest approach is to remove the subshell
wrapping and call `topo_setup`, `conf_delay`, and `do_test` in the same
shell scope:
topo_setup && conf_delay "$SERVER_NS" link0 2 || exit $?
if ! do_test; then
exit $ksft_fail
fi
topo_setup && conf_delay "$CLIENT_NS" link3 1 || exit $?
if ! do_test; then
exit $ksft_fail
fi
Please also note that `conf_delay` references `$ROUTER_NS` directly
(not via a parameter), so it too requires that those variables be set
in the same shell scope.
^ 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