* [PATCH 6.6.y] ipv6: add NULL checks for idev in SRv6 paths
From: Li hongliang @ 2026-04-20 5:42 UTC (permalink / raw)
To: gregkh, stable, heminhong
Cc: patches, linux-kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, david.lebrun, netdev, andrea.mayer
From: Minhong He <heminhong@kylinos.cn>
[ Upstream commit 06413793526251870e20402c39930804f14d59c0 ]
__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.
Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
Signed-off-by: Minhong He <heminhong@kylinos.cn>
Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Li hongliang <1468888505@139.com>
---
net/ipv6/exthdrs.c | 4 ++++
net/ipv6/seg6_hmac.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 676284b6efe8..a8790163e8b6 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -378,6 +378,10 @@ static int ipv6_srh_rcv(struct sk_buff *skb)
hdr = (struct ipv6_sr_hdr *)skb_transport_header(skb);
idev = __in6_dev_get(skb->dev);
+ if (!idev) {
+ kfree_skb(skb);
+ return -1;
+ }
accept_seg6 = net->ipv6.devconf_all->seg6_enabled;
if (accept_seg6 > idev->cnf.seg6_enabled)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index 6e15a65faecc..bf97bf5ac138 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -244,6 +244,8 @@ bool seg6_hmac_validate_skb(struct sk_buff *skb)
struct inet6_dev *idev;
idev = __in6_dev_get(skb->dev);
+ if (!idev)
+ return false;
srh = (struct ipv6_sr_hdr *)skb_transport_header(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH 6.1.y] ipv6: add NULL checks for idev in SRv6 paths
From: Li hongliang @ 2026-04-20 5:43 UTC (permalink / raw)
To: gregkh, stable, heminhong
Cc: patches, linux-kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, david.lebrun, netdev, andrea.mayer
From: Minhong He <heminhong@kylinos.cn>
[ Upstream commit 06413793526251870e20402c39930804f14d59c0 ]
__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.
Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
Signed-off-by: Minhong He <heminhong@kylinos.cn>
Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Li hongliang <1468888505@139.com>
---
net/ipv6/exthdrs.c | 4 ++++
net/ipv6/seg6_hmac.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 61e0060185f4..5fb97a87d2cb 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -381,6 +381,10 @@ static int ipv6_srh_rcv(struct sk_buff *skb)
hdr = (struct ipv6_sr_hdr *)skb_transport_header(skb);
idev = __in6_dev_get(skb->dev);
+ if (!idev) {
+ kfree_skb(skb);
+ return -1;
+ }
accept_seg6 = net->ipv6.devconf_all->seg6_enabled;
if (accept_seg6 > idev->cnf.seg6_enabled)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index b90c286d77ed..e784f539194a 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -244,6 +244,8 @@ bool seg6_hmac_validate_skb(struct sk_buff *skb)
struct inet6_dev *idev;
idev = __in6_dev_get(skb->dev);
+ if (!idev)
+ return false;
srh = (struct ipv6_sr_hdr *)skb_transport_header(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH 5.15.y] ipv6: add NULL checks for idev in SRv6 paths
From: Li hongliang @ 2026-04-20 5:43 UTC (permalink / raw)
To: gregkh, stable, heminhong
Cc: patches, linux-kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, david.lebrun, netdev, andrea.mayer
From: Minhong He <heminhong@kylinos.cn>
[ Upstream commit 06413793526251870e20402c39930804f14d59c0 ]
__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.
Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
Signed-off-by: Minhong He <heminhong@kylinos.cn>
Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Li hongliang <1468888505@139.com>
---
net/ipv6/exthdrs.c | 4 ++++
net/ipv6/seg6_hmac.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 10772dab66bb..3d249c10e3e9 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -373,6 +373,10 @@ static int ipv6_srh_rcv(struct sk_buff *skb)
hdr = (struct ipv6_sr_hdr *)skb_transport_header(skb);
idev = __in6_dev_get(skb->dev);
+ if (!idev) {
+ kfree_skb(skb);
+ return -1;
+ }
accept_seg6 = net->ipv6.devconf_all->seg6_enabled;
if (accept_seg6 > idev->cnf.seg6_enabled)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index 7e3a85769932..68acff337e41 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -244,6 +244,8 @@ bool seg6_hmac_validate_skb(struct sk_buff *skb)
struct inet6_dev *idev;
idev = __in6_dev_get(skb->dev);
+ if (!idev)
+ return false;
srh = (struct ipv6_sr_hdr *)skb_transport_header(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH 5.10.y] ipv6: add NULL checks for idev in SRv6 paths
From: Li hongliang @ 2026-04-20 5:43 UTC (permalink / raw)
To: gregkh, stable, heminhong
Cc: patches, linux-kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, david.lebrun, netdev, andrea.mayer
From: Minhong He <heminhong@kylinos.cn>
[ Upstream commit 06413793526251870e20402c39930804f14d59c0 ]
__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).
Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.
Fixes: 1ababeba4a21 ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
Signed-off-by: Minhong He <heminhong@kylinos.cn>
Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Li hongliang <1468888505@139.com>
---
net/ipv6/exthdrs.c | 4 ++++
net/ipv6/seg6_hmac.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index cdad9019c77c..dfa0fb3d6c35 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -361,6 +361,10 @@ static int ipv6_srh_rcv(struct sk_buff *skb)
hdr = (struct ipv6_sr_hdr *)skb_transport_header(skb);
idev = __in6_dev_get(skb->dev);
+ if (!idev) {
+ kfree_skb(skb);
+ return -1;
+ }
accept_seg6 = net->ipv6.devconf_all->seg6_enabled;
if (accept_seg6 > idev->cnf.seg6_enabled)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index f82fcd8908e1..b52985c867c2 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -245,6 +245,8 @@ bool seg6_hmac_validate_skb(struct sk_buff *skb)
struct inet6_dev *idev;
idev = __in6_dev_get(skb->dev);
+ if (!idev)
+ return false;
srh = (struct ipv6_sr_hdr *)skb_transport_header(skb);
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Masami Hiramatsu @ 2026-04-20 5:44 UTC (permalink / raw)
To: chensong_2000
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, pmladek, joe.lawrence, rostedt, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260415070137.17860-1-chensong_2000@189.cn>
Hi Song,
On Wed, 15 Apr 2026 15:01:37 +0800
chensong_2000@189.cn wrote:
> From: Song Chen <chensong_2000@189.cn>
>
> The current notifier chain implementation uses a single-linked list
> (struct notifier_block *next), which only supports forward traversal
> in priority order. This makes it difficult to handle cleanup/teardown
> scenarios that require notifiers to be called in reverse priority order.
What about introducing a new notification callback API that allows you
to describe dependencies between callback functions?
For example, when registering a callback, you could register a string
as an ID and specify whether to call it before or after that ID,
or you could register a comparison function that is called when adding
to a list. (I prefer @name and @depends fields so that it can be easily
maintained.)
This would allow for better dependency building when adding to the list.
>
> A concrete example is the ordering dependency between ftrace and
> livepatch during module load/unload. see the detail here [1].
If this only concerns notification callback issues with the ftrace
and livepatch modules, it's far more robust to simply call the
necessary processing directly when the modules load and unload,
rather than registering notification callbacks externally.
There are fprobe, kprobe and its trace-events, all of them are using
ftrace as its fundation layer. In this case, I always needs to
consider callback order when a module is unloaded.
If ftrace is working as a part of module callbacks, it will conflict
with fprobe/kprobe module callback. Of course we can reorder it with
modifying its priority. But this is ugly, because when we introduce
a new other feature which depends on another layer, we need to
reorder the callback's priority number on the list.
Based on the above, I don't think this can be resolved simply by
changing the list of notification callbacks to a bidirectional list.
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH net] net: mctp: fix don't require received header reserved bits to be zero
From: Jeremy Kerr @ 2026-04-20 5:41 UTC (permalink / raw)
To: wit_yuan
Cc: yuanzm2, matt, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, stable
In-Reply-To: <20260417141340.5306-1-yuanzhaoming901030@126.com>
Hi,
> From the MCTP Base specification (DSP0236 v1.2.1), the first byte of
> the MCTP header contains a 4 bit reserved field, and 4 bit version.
>
> On our current receive path, we require those 4 reserved bits to be
> zero, but the 9500-8i card is non-conformant, and may set these
> reserved bits.
>
> DSP0236 states that the reserved bits must be written as zero, and
> ignored when read. While the device might not conform to the former,
> we should accept these message to conform to the latter.
>
> Relax our check on the MCTP version byte to allow non-zero bits in the
> reserved field.
>
> Fixes: 889b7da23abf ("mctp: Add initial routing framework")
> Signed-off-by: Yuan Zhaoming <yuanzm2@lenovo.com>
Looks good, thanks for the contribution!
Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
Cheers,
Jeremy
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] idpf: do not perform flow ops when netdev is detached
From: Loktionov, Aleksandr @ 2026-04-20 6:20 UTC (permalink / raw)
To: Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller,
Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
David Decotigny, Singhai, Anjali, Samudrala, Sridhar,
Brian Vazquez, Tantilov, Emil S
In-Reply-To: <20260419192555.3631327-1-boolli@google.com>
> -----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;
> + }
> +
> 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
Please add Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net V2 3/3] net/mlx5e: SD, Fix race condition in secondary device probe/remove
From: Shay Drori @ 2026-04-20 6:21 UTC (permalink / raw)
To: Paolo Abeni, Tariq Toukan, Eric Dumazet, Jakub Kicinski,
Andrew Lunn, David S. Miller
Cc: Saeed Mahameed, Mark Bloch, Leon Romanovsky, Simon Horman,
Kees Cook, Parav Pandit, Patrisious Haddad, Gal Pressman, netdev,
linux-rdma, linux-kernel, Dragos Tatulea
In-Reply-To: <b429c6d3-8f6a-41fb-a9e6-9867a8ee1ad8@redhat.com>
On 16/04/2026 14:07, Paolo Abeni wrote:
> External email: Use caution opening links or attachments
>
>
> On 4/13/26 12:53 PM, Tariq Toukan wrote:
>> From: Shay Drory <shayd@nvidia.com>
>>
>> When utilizing Socket-Direct single netdev functionality the driver
>> resolves the actual auxiliary device using mlx5_sd_get_adev(). However,
>> the current implementation returns the primary ETH auxiliary device
>> without holding the device lock, leading to a potential race condition
>> where the ETH device could be unbound or removed concurrently during
>> probe, suspend, resume, or remove operations.[1]
>>
>> Fix this by introducing mlx5_sd_put_adev() and updating
>> mlx5_sd_get_adev() so that secondaries devices would acquire the device
>> lock of the returned auxiliary device. After the lock is acquired, a
>> second devcom check is needed[2].
>> In addition, update The callers to pair the get operation with the new
>> put operation, ensuring the lock is held while the auxiliary device is
>> being operated on and released afterwards.
>>
>> The "primary" designation is determined once in sd_register(). It's set
>> before devcom is marked ready, and it never changes after that.
>> In Addition, The primary path never locks a secondary: When the primary
>> device invoke mlx5_sd_get_adev(), it sees dev == primary and returns.
>> no additional lock is taken.
>> Therefore lock ordering is always: secondary_lock -> primary_lock. The
>> reverse never happens, so ABBA deadlock is impossible.
>>
>> [1]
>> for example:
>> BUG: kernel NULL pointer dereference, address: 0000000000000370
>> PGD 0 P4D 0
>> Oops: Oops: 0000 [#1] SMP
>> CPU: 4 UID: 0 PID: 3945 Comm: bash Not tainted 6.19.0-rc3+ #1 NONE
>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
>> RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 [mlx5_core]
>> Call Trace:
>> <TASK>
>> mlx5e_remove+0x82/0x12a [mlx5_core]
>> device_release_driver_internal+0x194/0x1f0
>> bus_remove_device+0xc6/0x140
>> device_del+0x159/0x3c0
>> ? devl_param_driverinit_value_get+0x29/0x80
>> mlx5_rescan_drivers_locked+0x92/0x160 [mlx5_core]
>> mlx5_unregister_device+0x34/0x50 [mlx5_core]
>> mlx5_uninit_one+0x43/0xb0 [mlx5_core]
>> remove_one+0x4e/0xc0 [mlx5_core]
>> pci_device_remove+0x39/0xa0
>> device_release_driver_internal+0x194/0x1f0
>> unbind_store+0x99/0xa0
>> kernfs_fop_write_iter+0x12e/0x1e0
>> vfs_write+0x215/0x3d0
>> ksys_write+0x5f/0xd0
>> do_syscall_64+0x55/0xe90
>> entry_SYSCALL_64_after_hwframe+0x4b/0x53
>>
>> [2]
>> CPU0 (primary) CPU1 (secondary)
>> ==========================================================================
>> mlx5e_remove() (device_lock held)
>> mlx5e_remove() (2nd device_lock held)
>> mlx5_sd_get_adev()
>> mlx5_devcom_comp_is_ready() => true
>> device_lock(primary)
>> mlx5_sd_get_adev() ==> ret adev
>> _mlx5e_remove()
>> mlx5_sd_cleanup()
>> // mlx5e_remove finished
>> // releasing device_lock
>> //need another check here...
>> mlx5_devcom_comp_is_ready() => false
>>
>> Fixes: 381978d28317 ("net/mlx5e: Create single netdev per SD group")
>> Signed-off-by: Shay Drory <shayd@nvidia.com>
>> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
>> ---
>> .../net/ethernet/mellanox/mlx5/core/en_main.c | 18 ++++++++++++++----
>> .../net/ethernet/mellanox/mlx5/core/lib/sd.c | 17 +++++++++++++++++
>> .../net/ethernet/mellanox/mlx5/core/lib/sd.h | 2 ++
>> 3 files changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> index 0b8b44bbcb9e..11f80158e107 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>> @@ -6657,8 +6657,11 @@ static int mlx5e_resume(struct auxiliary_device *adev)
>> return err;
>>
>> actual_adev = mlx5_sd_get_adev(mdev, adev, edev->idx);
>> - if (actual_adev)
>> - return _mlx5e_resume(actual_adev);
>> + if (actual_adev) {
>> + err = _mlx5e_resume(actual_adev);
>> + mlx5_sd_put_adev(actual_adev, adev);
>> + return err;
>> + }
>> return 0;
>> }
>>
>> @@ -6698,6 +6701,8 @@ static int mlx5e_suspend(struct auxiliary_device *adev, pm_message_t state)
>> err = _mlx5e_suspend(actual_adev, false);
>>
>> mlx5_sd_cleanup(mdev);
>> + if (actual_adev)
>> + mlx5_sd_put_adev(actual_adev, adev);
>> return err;
>> }
>>
>> @@ -6795,8 +6800,11 @@ static int mlx5e_probe(struct auxiliary_device *adev,
>> return err;
>>
>> actual_adev = mlx5_sd_get_adev(mdev, adev, edev->idx);
>> - if (actual_adev)
>> - return _mlx5e_probe(actual_adev);
>> + if (actual_adev) {
>> + err = _mlx5e_probe(actual_adev);
>> + mlx5_sd_put_adev(actual_adev, adev);
>
> Sashiko says:
>
> ---
> If _mlx5e_probe(actual_adev) fails, it frees mlx5e_dev but leaves the
> auxiliary device's drvdata pointing to it.
After probe fails, the driver core marks the device as unbound.
Hence, the stale drvdata pointer is unreachable.
> Furthermore, mlx5e_probe()
> returns the error without calling mlx5_sd_cleanup(mdev), leaving devcom
> incorrectly marked as ready.
> If the primary device is later unbound, mlx5e_remove() will see that
> devcom is ready, call _mlx5e_remove(), and blindly dereference the
> dangling mlx5e_dev pointer.
> Is there a missing cleanup step here to clear drvdata or reset the sd
> state on failure?
This is an existing bug that will be address in a new patch in V3
> ---
>
> Please try to address AI comments (i.e. explaining why not relevant)
> proactively.
Ack.
Thanks
>
> Thanks,
>
> Paolo
>
^ permalink raw reply
* Re: [PATCH net v1] net/mlx5: Fix HCA caps leak on notifier init failure
From: Tariq Toukan @ 2026-04-20 6:57 UTC (permalink / raw)
To: Prathamesh Deshpande, Saeed Mahameed, Leon Romanovsky,
Carolina Jubran
Cc: Cosmin Ratiu, Tariq Toukan, Jakub Kicinski, netdev, linux-rdma,
linux-kernel
In-Reply-To: <20260415005022.34764-1-prathameshdeshpande7@gmail.com>
On 15/04/2026 3:49, Prathamesh Deshpande wrote:
> mlx5_mdev_init() allocates HCA caps via mlx5_hca_caps_alloc() before
> calling mlx5_notifiers_init(). If notifier initialization fails, the
> error path jumps to err_hca_caps and skips mlx5_hca_caps_free(), leaking
> allocated caps.
>
> Add a dedicated unwind label for notifier-init failure that frees HCA
> caps before continuing the existing cleanup sequence.
>
> Fixes: b6b03097f982 ("net/mlx5: Initialize events outside devlink lock")
> Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> index 3f73d9b1115d..fab80c79ff07 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> @@ -1907,7 +1907,7 @@ int mlx5_mdev_init(struct mlx5_core_dev *dev, int profile_idx)
>
> err = mlx5_notifiers_init(dev);
> if (err)
> - goto err_hca_caps;
> + goto err_notifiers_init;
>
> /* The conjunction of sw_vhca_id with sw_owner_id will be a global
> * unique id per function which uses mlx5_core.
> @@ -1923,6 +1923,8 @@ int mlx5_mdev_init(struct mlx5_core_dev *dev, int profile_idx)
>
> return 0;
>
> +err_notifiers_init:
> + mlx5_hca_caps_free(dev);
> err_hca_caps:
> mlx5_adev_cleanup(dev);
> err_adev_init:
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 12/12] selftests: net: Add a test for BIG TCP in UDP tunnels
From: Willem de Bruijn @ 2026-04-20 7:00 UTC (permalink / raw)
To: Alice Mikityanska, Willem de Bruijn
Cc: Alice Mikityanska, Daniel Borkmann, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Xin Long, David Ahern,
Nikolay Aleksandrov, Shuah Khan, Stanislav Fomichev, Andrew Lunn,
Simon Horman, Florian Westphal, netdev
In-Reply-To: <CAD0BsJXyHQADVymJw7L0sA72P-=E8Wz7p3CedyvCbqEHBu17JA@mail.gmail.com>
Alice Mikityanska wrote:
> On Thu, 16 Apr 2026 at 14:06, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Alice Mikityanska wrote:
> > > From: Alice Mikityanska <alice@isovalent.com>
> > >
> > > The test sets up VXLAN and GENEVE tunnels over IPv4 and IPv6 and runs
> > > IPv4 and IPv6 traffic through them with BIG TCP enabled. It checks that
> > > a non-negligible amount of big aggregated packets are seen in tcpdump.
> > >
> > > Signed-off-by: Alice Mikityanska <alice@isovalent.com>
> > > ---
> > > tools/testing/selftests/net/Makefile | 1 +
> > > .../testing/selftests/net/big_tcp_tunnels.sh | 145 ++++++++++++++++++
> > > 2 files changed, 146 insertions(+)
> > > create mode 100755 tools/testing/selftests/net/big_tcp_tunnels.sh
> > >
> > > diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> > > index cab74ebdaced..c8ea9d4bb94f 100644
> > > --- a/tools/testing/selftests/net/Makefile
> > > +++ b/tools/testing/selftests/net/Makefile
> > > @@ -13,6 +13,7 @@ TEST_PROGS := \
> > > arp_ndisc_untracked_subnets.sh \
> > > bareudp.sh \
> > > big_tcp.sh \
> > > + big_tcp_tunnels.sh \
> > > bind_bhash.sh \
> > > bpf_offload.py \
> > > bridge_vlan_dump.sh \
> > > diff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh
> > > new file mode 100755
> > > index 000000000000..b819911519ac
> > > --- /dev/null
> > > +++ b/tools/testing/selftests/net/big_tcp_tunnels.sh
> > > @@ -0,0 +1,145 @@
> > > +#!/usr/bin/env bash
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +#
> > > +# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels.
> > > +
> > > +SERVER_NS=$(mktemp -u server-XXXXXXXX)
> > > +SERVER_IP4="192.168.1.1"
> > > +SERVER_IP6="2001:db8::1:1"
> > > +SERVER_IP4_TUN="192.168.2.1"
> > > +SERVER_IP6_TUN="2001:db8::2:1"
> > > +
> > > +CLIENT_NS=$(mktemp -u client-XXXXXXXX)
> > > +CLIENT_IP4="192.168.1.2"
> > > +CLIENT_IP6="2001:db8::1:2"
> > > +CLIENT_IP4_TUN="192.168.2.2"
> > > +CLIENT_IP6_TUN="2001:db8::2:2"
> > > +
> > > +PACKETS_THRESHOLD=10000
> > > +
> > > +# Kselftest framework requirement - SKIP code is 4.
> > > +ksft_skip=4
> > > +
> > > +setup() {
> > > + ip netns add "$SERVER_NS"
> > > + ip netns add "$CLIENT_NS"
> > > + ip -netns "$SERVER_NS" link add link1 type veth peer name link0 netns "$CLIENT_NS"
> > > +
> > > + ip -netns "$CLIENT_NS" link set link0 up
> > > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4/24" dev link0
> > > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6/112" dev link0 nodad
> > > + ip -netns "$CLIENT_NS" link set link0 \
> > > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > > + gro_max_size 196608 gro_ipv4_max_size 196608
> > > + ip -netns "$SERVER_NS" link set link1 up
> > > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP4/24" dev link1
> > > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP6/112" dev link1 nodad
> > > + ip -netns "$SERVER_NS" link set link1 \
> > > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > > + gro_max_size 196608 gro_ipv4_max_size 196608
> > > +
> > > + ip netns exec "$SERVER_NS" netserver >/dev/null
> > > +}
> > > +
> > > +setup_tunnel() {
> > > + if [ "$2" = 4 ]; then
> > > + SERVER_IP="$SERVER_IP4"
> > > + CLIENT_IP="$CLIENT_IP4"
> > > + echo "Setting up ${1^^} over IPv4"
> > > + else
> > > + SERVER_IP="$SERVER_IP6"
> > > + CLIENT_IP="$CLIENT_IP6"
> > > + echo "Setting up ${1^^} over IPv6"
> > > + fi
> > > +
> > > + if [ "$1" = vxlan ]; then
> > > + ip -netns "$CLIENT_NS" link add tun0 type vxlan \
> > > + id 5001 remote "$SERVER_IP" local "$CLIENT_IP" dev link0 dstport 4789
> > > + else
> > > + ip -netns "$CLIENT_NS" link add tun0 type geneve \
> > > + id 5001 remote "$SERVER_IP"
> > > + fi
> > > + ip -netns "$CLIENT_NS" link set tun0 up
> > > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4_TUN/24" dev tun0
> > > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6_TUN/112" dev tun0 nodad
> > > + ip -netns "$CLIENT_NS" link set tun0 \
> > > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > > + gro_max_size 196608 gro_ipv4_max_size 196608
> > > + if [ "$1" = vxlan ]; then
> > > + ip -netns "$SERVER_NS" link add tun1 type vxlan \
> > > + id 5001 remote "$CLIENT_IP" local "$SERVER_IP" dev link1 dstport 4789
> > > + else
> > > + ip -netns "$SERVER_NS" link add tun1 type geneve \
> > > + id 5001 remote "$CLIENT_IP"
> > > + fi
> > > + ip -netns "$SERVER_NS" link set tun1 up
> > > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP4_TUN/24" dev tun1
> > > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP6_TUN/112" dev tun1 nodad
> > > + ip -netns "$SERVER_NS" link set tun1 \
> > > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > > + gro_max_size 196608 gro_ipv4_max_size 196608
> > > +}
> > > +
> > > +cleanup_tunnel() {
> > > + ip -netns "$CLIENT_NS" link del tun0
> > > + ip -netns "$SERVER_NS" link del tun1
> > > +}
> > > +
> > > +cleanup() {
> > > + ip netns exec "$SERVER_NS" killall netserver
> > > + ip netns del "$SERVER_NS"
> > > + ip netns del "$CLIENT_NS"
> > > +}
> > > +
> > > +do_test() {
> > > + exec 3< <(ip netns exec "$SERVER_NS" tcpdump -nn -i link1 greater 65536 2> /dev/null)
> > > + TCPDUMP_SERVER_PID="$!"
> > > + exec 4< <(wc -l <&3)
> > > + exec 5< <(ip netns exec "$CLIENT_NS" tcpdump -nn -i link0 greater 65536 2> /dev/null)
> > > + TCPDUMP_CLIENT_PID="$!"
> > > + exec 6< <(wc -l <&5)
> > > +
> > > + if [ "$1" = 4 ]; then
> > > + SERVER_IP="$SERVER_IP4_TUN"
> > > + echo "Running IPv4 traffic in the tunnel"
> > > + else
> > > + SERVER_IP="$SERVER_IP6_TUN"
> > > + echo "Running IPv6 traffic in the tunnel"
> > > + fi
> > > +
> > > + ip netns exec "$CLIENT_NS" netperf -t TCP_STREAM -l 5 -H "$SERVER_IP" -- \
> > > + -r 80000:80000 > /dev/null
> >
> > is -r valid for TCP_STREAM
>
> Yes, it controls how much data is sent in one send() syscall. If I set
> a smaller size, the kernel will still try to aggregate the packets,
> but there will be much fewer BIG TCP packets.
Not according to the care & feeding doc, where it is an RR option.
Maybe it is used in practice. Maybe also depends on whether using
omni or bsd mode. But just a note.
^ permalink raw reply
* Re: [PATCH net V2 1/3] net/mlx5: SD: Serialize init/cleanup
From: Shay Drori @ 2026-04-20 7:01 UTC (permalink / raw)
To: Paolo Abeni, Tariq Toukan, Eric Dumazet, Jakub Kicinski,
Andrew Lunn, David S. Miller
Cc: Saeed Mahameed, Mark Bloch, Leon Romanovsky, Simon Horman,
Kees Cook, Parav Pandit, Patrisious Haddad, Gal Pressman, netdev,
linux-rdma, linux-kernel, Dragos Tatulea
In-Reply-To: <77503dd8-d882-4079-9dc8-f0cab89c0a7b@redhat.com>
On 16/04/2026 14:00, Paolo Abeni wrote:
> External email: Use caution opening links or attachments
>
>
> On 4/13/26 12:53 PM, Tariq Toukan wrote:
>> @@ -491,23 +508,35 @@ void mlx5_sd_cleanup(struct mlx5_core_dev *dev)
>> {
>> struct mlx5_sd *sd = mlx5_get_sd(dev);
>> struct mlx5_core_dev *primary, *pos;
>> + struct mlx5_sd *primary_sd = NULL;
>> int i;
>>
>> if (!sd)
>> return;
>>
>> + mlx5_devcom_comp_lock(sd->devcom);
>> if (!mlx5_devcom_comp_is_ready(sd->devcom))
>> - goto out;
>> + goto out_unlock;
>>
>> primary = mlx5_sd_get_primary(dev);
>> + primary_sd = mlx5_get_sd(primary);
>> +
>> + if (primary_sd->state != MLX5_SD_STATE_UP)
>> + goto out_unlock;
>> +
>> mlx5_sd_for_each_secondary(i, primary, pos)
>> sd_cmd_unset_secondary(pos);
>> sd_cmd_unset_primary(primary);
>> debugfs_remove_recursive(sd->dfs);
>>
>> sd_info(primary, "group id %#x, uncombined\n", sd->group_id);
>> -out:
>> + primary_sd->state = MLX5_SD_STATE_DESTROYING;
>> +out_unlock:
>> + mlx5_devcom_comp_unlock(sd->devcom);
>> sd_unregister(dev);
>> + if (primary_sd)
>> + /* devcom isn't ready, reset the state */
>> + primary_sd->state = MLX5_SD_STATE_DOWN;
>
> Sashiko says:
>
> ---
> Since primary_sd is only populated if devcom is ready, this condition will
> never trigger when devcom isn't ready, contrary to the comment. Instead,
> it triggers on the normal path after devcom is ready, immediately
> overwriting
> MLX5_SD_STATE_DESTROYING with MLX5_SD_STATE_DOWN outside the lock.
> Could this allow concurrent mlx5_sd_init() calls to see the down state and
> attempt hardware re-initialization while the group is still being torn down?
> Also, can this race and cause a use-after-free regression?
> During a concurrent Socket-Direct group teardown, the primary PF and
> secondary
> PF can execute mlx5_sd_cleanup() in parallel.
> If the primary PF completes its cleanup first, it will call
> sd_cleanup(primary)
> which calls kfree() on the sd structure, freeing the primary_sd memory.
> If the secondary PF is preempted just after releasing the devcom lock,
> it will resume, evaluate its local non-NULL primary_sd pointer, and
> locklessly
> write to primary_sd->state. Does this dereference the freed memory of the
> primary PF?
After some more thinks following the above comments, I change the logic
here so that devcom_set_ready(false) is done under the
mlx5_devcom_comp_lock(), making the is_ready() check in sd_init()
reliable gate for cleanup/init race cases.
> ---
>
^ permalink raw reply
* [syzbot] [wireless?] KASAN: slab-use-after-free Write in rsi_91x_deinit
From: syzbot @ 2026-04-20 7:05 UTC (permalink / raw)
To: linux-kernel, linux-usb, linux-wireless, netdev, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 87117347a0e7 usb: dwc3: starfive: Add JHB100 USB 2.0 DRD c..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=171b04ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=2056c1e3f6d3b0bc
dashboard link: https://syzkaller.appspot.com/bug?extid=5de83f57cd8531f55596
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6168cf3e4727/disk-87117347.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/36e554f1750a/vmlinux-87117347.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7aa92e741f66/bzImage-87117347.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5de83f57cd8531f55596@syzkaller.appspotmail.com
rsi_91x: rsi_probe: Failed to init usb interface
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
BUG: KASAN: slab-use-after-free in atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]
BUG: KASAN: slab-use-after-free in __refcount_add include/linux/refcount.h:283 [inline]
BUG: KASAN: slab-use-after-free in __refcount_inc include/linux/refcount.h:366 [inline]
BUG: KASAN: slab-use-after-free in refcount_inc include/linux/refcount.h:383 [inline]
BUG: KASAN: slab-use-after-free in get_task_struct include/linux/sched/task.h:116 [inline]
BUG: KASAN: slab-use-after-free in kthread_stop+0x8f/0x680 kernel/kthread.c:754
Write of size 4 at addr ffff88813d339da8 by task kworker/0:3/10583
CPU: 0 UID: 0 PID: 10583 Comm: kworker/0:3 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x156/0x4c9 mm/kasan/report.c:482
kasan_report+0xdf/0x1e0 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:186 [inline]
kasan_check_range+0x10f/0x1e0 mm/kasan/generic.c:200
instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]
__refcount_add include/linux/refcount.h:283 [inline]
__refcount_inc include/linux/refcount.h:366 [inline]
refcount_inc include/linux/refcount.h:383 [inline]
get_task_struct include/linux/sched/task.h:116 [inline]
kthread_stop+0x8f/0x680 kernel/kthread.c:754
rsi_kill_thread drivers/net/wireless/rsi/rsi_common.h:78 [inline]
rsi_91x_deinit+0x102/0x1f0 drivers/net/wireless/rsi/rsi_91x_main.c:405
rsi_probe+0xd27/0x1aa0 drivers/net/wireless/rsi/rsi_91x_usb.c:861
usb_probe_interface+0x303/0x8f0 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
usb_set_configuration+0xd97/0x1c60 drivers/usb/core/message.c:2268
usb_generic_driver_probe+0xa1/0xe0 drivers/usb/core/generic.c:250
usb_probe_device+0xef/0x400 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:643 [inline]
really_probe+0x241/0xa60 drivers/base/dd.c:721
__driver_probe_device+0x1de/0x400 drivers/base/dd.c:863
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:893
__device_attach_driver+0x1df/0x340 drivers/base/dd.c:1021
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:500
__device_attach+0x1e4/0x4d0 drivers/base/dd.c:1093
device_initial_probe+0xaf/0xd0 drivers/base/dd.c:1148
bus_probe_device+0x64/0x160 drivers/base/bus.c:613
device_add+0x11d9/0x1950 drivers/base/core.c:3691
usb_new_device.cold+0x685/0x115c drivers/usb/core/hub.c:2695
hub_port_connect drivers/usb/core/hub.c:5567 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
port_event drivers/usb/core/hub.c:5871 [inline]
hub_event+0x314d/0x4af0 drivers/usb/core/hub.c:5953
process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
process_scheduled_works kernel/workqueue.c:3359 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x6c3/0xcb0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 2:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6e/0x70 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_node_noprof+0x26b/0x6b0 mm/slub.c:4918
alloc_task_struct_node kernel/fork.c:185 [inline]
dup_task_struct kernel/fork.c:916 [inline]
copy_process+0x48b/0x7820 kernel/fork.c:2050
kernel_clone+0xfc/0x9a0 kernel/fork.c:2653
kernel_thread+0xdb/0x120 kernel/fork.c:2714
create_kthread kernel/kthread.c:459 [inline]
kthreadd+0x498/0x7a0 kernel/kthread.c:817
ret_from_fork+0x6c3/0xcb0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 14:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x43/0x70 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kmem_cache_free+0x105/0x640 mm/slub.c:6295
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x5a2/0x10d0 kernel/rcu/tree.c:2869
handle_softirqs+0x1de/0x9d0 kernel/softirq.c:622
run_ksoftirqd kernel/softirq.c:1063 [inline]
run_ksoftirqd+0x38/0x60 kernel/softirq.c:1055
smpboot_thread_fn+0x3d3/0xaa0 kernel/smpboot.c:160
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x6c3/0xcb0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Last potentially related work creation:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_record_aux_stack+0x8c/0xa0 mm/kasan/generic.c:556
__call_rcu_common.constprop.0+0xa5/0x9b0 kernel/rcu/tree.c:3131
put_task_struct include/linux/sched/task.h:159 [inline]
put_task_struct include/linux/sched/task.h:128 [inline]
delayed_put_task_struct+0xe4/0x2e0 kernel/exit.c:231
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x5a2/0x10d0 kernel/rcu/tree.c:2869
handle_softirqs+0x1de/0x9d0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xed/0x150 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1056
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
Second to last potentially related work creation:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_record_aux_stack+0x8c/0xa0 mm/kasan/generic.c:556
__call_rcu_common.constprop.0+0xa5/0x9b0 kernel/rcu/tree.c:3131
put_task_struct_rcu_user kernel/exit.c:237 [inline]
put_task_struct_rcu_user+0x6c/0xc0 kernel/exit.c:234
context_switch kernel/sched/core.c:5301 [inline]
__schedule+0xeb9/0x4220 kernel/sched/core.c:6911
preempt_schedule_common+0x42/0xc0 kernel/sched/core.c:7095
preempt_schedule_thunk+0x16/0x30 arch/x86/entry/thunk.S:12
__raw_spin_unlock include/linux/spinlock_api_smp.h:169 [inline]
_raw_spin_unlock+0x3e/0x50 kernel/locking/spinlock.c:186
spin_unlock include/linux/spinlock.h:389 [inline]
filemap_map_pages+0x130f/0x1e50 mm/filemap.c:3936
do_fault_around mm/memory.c:5757 [inline]
do_read_fault mm/memory.c:5790 [inline]
do_fault mm/memory.c:5933 [inline]
do_pte_missing mm/memory.c:4477 [inline]
handle_pte_fault mm/memory.c:6317 [inline]
__handle_mm_fault+0x1e2e/0x2d60 mm/memory.c:6455
handle_mm_fault+0x36d/0xa20 mm/memory.c:6624
do_user_addr_fault+0x5ae/0x11d0 arch/x86/mm/fault.c:1334
handle_page_fault arch/x86/mm/fault.c:1474 [inline]
exc_page_fault+0x66/0xc0 arch/x86/mm/fault.c:1527
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
The buggy address belongs to the object at ffff88813d339d80
which belongs to the cache task_struct of size 7296
The buggy address is located 40 bytes inside of
freed 7296-byte region [ffff88813d339d80, ffff88813d33ba00)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x13d338
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff88813d33f601
flags: 0x200000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0200000000000040 ffff8881012d9500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800040004 00000000f5000000 ffff88813d33f601
head: 0200000000000040 ffff8881012d9500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800040004 00000000f5000000 ffff88813d33f601
head: 0200000000000003 ffffea0004f4ce01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5914, tgid 5914 (dhcpcd-run-hook), ts 193584350604, free_ts 193494512770
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0xf10/0x39f0 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x273/0x2860 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab mm/slub.c:3481 [inline]
new_slab+0xa6/0x6c0 mm/slub.c:3539
refill_objects+0x26b/0x400 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x1ab/0x660 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
kmem_cache_alloc_node_noprof+0x4e9/0x6b0 mm/slub.c:4918
alloc_task_struct_node kernel/fork.c:185 [inline]
dup_task_struct kernel/fork.c:916 [inline]
copy_process+0x48b/0x7820 kernel/fork.c:2050
kernel_clone+0xfc/0x9a0 kernel/fork.c:2653
__do_sys_clone+0xd9/0x120 kernel/fork.c:2794
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0x7b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 2861 tgid 2861 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0x7b1/0xfb0 mm/page_alloc.c:2978
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x47/0xe0 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x1a0/0x1f0 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x4e/0x70 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_noprof+0x2e7/0x6a0 mm/slub.c:4873
alloc_filename fs/namei.c:142 [inline]
do_getname+0x35/0x390 fs/namei.c:182
getname include/linux/fs.h:2512 [inline]
class_filename_constructor include/linux/fs.h:2539 [inline]
do_sys_openat2+0xc5/0x1e0 fs/open.c:1365
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x106/0x7b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88813d339c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88813d339d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88813d339d80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88813d339e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88813d339e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH v2 iwl-net] i40e: keep q_vectors array in sync with channel count changes
From: Simon Horman @ 2026-04-20 7:20 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: intel-wired-lan, netdev, magnus.karlsson, kuba, pabeni,
przemyslaw.kitszel, jacob.e.keller
In-Reply-To: <20260416114046.642171-1-maciej.fijalkowski@intel.com>
On Thu, Apr 16, 2026 at 01:40:46PM +0200, Maciej Fijalkowski wrote:
> For the main VSI, i40e_set_num_rings_in_vsi() always derives
> num_q_vectors from pf->num_lan_msix. At the same time, ethtool -L stores
> the user requested channel count in vsi->req_queue_pairs and the queue
> setup path uses that value for the effective number of queue pairs.
>
> This leaves queue and vector counts out of sync after shrinking channel
> count via ethtool -L. The active queue configuration is reduced, but the
> VSI still keeps the full PF-sized q_vector topology.
>
> That mismatch breaks reconfiguration flows which rely on vector/NAPI
> state matching the effective channel configuration. In particular,
> toggling /sys/class/net/<dev>/threaded after reducing the channel count
> can hang, and later channel-count changes can fail because VSI reinit
> does not rebuild q_vectors to match the new vector count.
>
> Fix this by making the main VSI num_q_vectors follow the effective
> requested channel count, capped by the available MSI-X vectors. Update
> i40e_vsi_reinit_setup() to rebuild q_vectors during VSI reinit so the
> vector topology is refreshed together with the ring arrays when channel
> count changes.
>
> Keep alloc_queue_pairs unchanged and based on pf->num_lan_qps so the VSI
> retains its full queue capacity.
>
> Selftest napi_threaded.py was originally used when Jakub reported hang
> on /sys/class/net/<dev>/threaded toggle. In order to make it pass on
> i40e, use persistent NAPI configuration for q_vector NAPIs so NAPI
> identity and threaded settings survive q_vector reallocation across
> channel-count changes. This is achieved by using netif_napi_add_config()
> when configuring q_vectors.
>
> $ export NETIF=ens259f1np1
> $ sudo -E env PATH="$PATH" ./tools/testing/selftests/drivers/net/napi_threaded.py
> TAP version 13
> 1..3
> ok 1 napi_threaded.napi_init
> ok 2 napi_threaded.change_num_queues
> ok 3 napi_threaded.enable_dev_threaded_disable_napi_threaded
> Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
>
> Reported-by: Jakub Kicinski <kuba@kernel.org>
> Closes: https://lore.kernel.org/intel-wired-lan/20260316133100.6054a11f@kernel.org/
> Fixes: d2a69fefd756 ("i40e: Fix changing previously set num_queue_pairs for PFs")
> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> v2:
> - NULL vsi->tx_rings in i40e_vsi_alloc_arrays() (Sashiko)
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 35 +++++++++++++++++----
> 1 file changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 926d001b2150..1d2a4181966f 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -11403,10 +11403,14 @@ static void i40e_service_timer(struct timer_list *t)
> static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
> {
> struct i40e_pf *pf = vsi->back;
> + u16 qps;
>
> switch (vsi->type) {
> case I40E_VSI_MAIN:
> vsi->alloc_queue_pairs = pf->num_lan_qps;
> + qps = vsi->req_queue_pairs ?
> + min_t(u16, vsi->req_queue_pairs, pf->num_lan_qps) :
nit: It looks all the variables involved here u16.
So min() can be used instead of min_t().
> + pf->num_lan_qps;
> if (!vsi->num_tx_desc)
> vsi->num_tx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
> I40E_REQ_DESCRIPTOR_MULTIPLE);
> @@ -11414,7 +11418,8 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi *vsi)
> vsi->num_rx_desc = ALIGN(I40E_DEFAULT_NUM_DESCRIPTORS,
> I40E_REQ_DESCRIPTOR_MULTIPLE);
> if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags))
> - vsi->num_q_vectors = pf->num_lan_msix;
> + vsi->num_q_vectors = max_t(int, 1,
> + min_t(int, qps, pf->num_lan_msix));
nit: On the left side, all values seem to be either constants or u16.
So I think you can use clamp() here, and simply assign the resulting
value to num_q_vectors, which is an int.
> else
> vsi->num_q_vectors = 1;
>
...
> @@ -14265,12 +14272,27 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>
> pf = vsi->back;
>
> + if (test_bit(I40E_FLAG_MSIX_ENA, pf->flags)) {
> + i40e_put_lump(pf->irq_pile, vsi->base_vector, vsi->idx);
> + vsi->base_vector = 0;
> + }
> +
> i40e_put_lump(pf->qp_pile, vsi->base_queue, vsi->idx);
> i40e_vsi_clear_rings(vsi);
>
> - i40e_vsi_free_arrays(vsi, false);
> + i40e_vsi_free_q_vectors(vsi);
> + i40e_vsi_free_arrays(vsi, true);
nit: with this patch applied the free_vectors argument (the 2nd parameter)
of i40e_vsi_free_arrays is always passed as true by callers.
So I think that, as a follow-up, it can be removed.
Similarly for i40e_vsi_alloc_arrays.
> i40e_set_num_rings_in_vsi(vsi);
> - ret = i40e_vsi_alloc_arrays(vsi, false);
> +
> + ret = i40e_vsi_alloc_arrays(vsi, true);
> + if (ret)
> + goto err_vsi;
> +
> + /* Rebuild q_vectors during VSI reinit because the effective channel
> + * count may change num_q_vectors. Keep vector topology aligned with the
> + * queue configuration after ethtool's .set_channels() callback.
> + */
> + ret = i40e_vsi_setup_vectors(vsi);
> if (ret)
> goto err_vsi;
>
...
^ permalink raw reply
* Re: [PATCH net 1/2] tcp: send a challenge ACK on SEG.ACK > SND.NXT
From: Eric Dumazet @ 2026-04-20 7:21 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
David Ahern, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260420025428.101192-2-jiayuan.chen@linux.dev>
On Sun, Apr 19, 2026 at 7:55 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> RFC 5961 Section 5.2 validates an incoming segment's ACK value
> against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states:
>
> "All incoming segments whose ACK value doesn't satisfy the above
> condition MUST be discarded and an ACK sent back."
>
> Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack
> Mitigation") opted Linux into this mitigation and implements the
> challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND),
> but the symmetric upper side (SEG.ACK > SND.NXT) still takes the
> pre-RFC-5961 path and silently returns
> SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9
> (now RFC 9293 Section 3.10.7.4) has always required:
>
> "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT)
> then send an ACK, drop the segment, and return."
>
> Complete the mitigation by sending a challenge ACK on that branch,
> reusing the existing tcp_send_challenge_ack() path which already
> enforces the per-socket RFC 5961 Section 7 rate limit via
> __tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for
> symmetry with the lower-edge case.
>
> Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> ---
> I'm not sure if 'blamed commit' is appropriate, because I think
> it's due to missing parts of the implementation, or it might be
> directly targeted to net-next.
The Fixes: tag seems appropriate, and net tree LGTM.
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks!
^ permalink raw reply
* Re: [PATCH net 2/2] selftests/net: packetdrill: cover challenge ACK on SEG.ACK > SND.NXT
From: Eric Dumazet @ 2026-04-20 7:22 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Neal Cardwell, Kuniyuki Iwashima, David S. Miller,
David Ahern, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260420025428.101192-3-jiayuan.chen@linux.dev>
On Sun, Apr 19, 2026 at 7:55 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> Exercise the RFC 5961 Section 5.2 / RFC 793 Section 3.9 requirement
> on the upper edge of the acceptable ACK range, mirroring the existing
> coverage of the SEG.ACK < SND.UNA - MAX.SND.WND case.
>
> After the peer ACKs data the receiver has never sent, the receiver
> must respond with <SEQ = SND.NXT, ACK = RCV.NXT, CTL = ACK> and drop
> the offending segment. The script validates this exact response.
>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks!
^ permalink raw reply
* RE: [PATCH 7/9] wifi: rtw89: switch to using FIELD_GET_SIGNED()
From: Ping-Ke Shih @ 2026-04-20 7:49 UTC (permalink / raw)
To: Yury Norov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86@kernel.org, H. Peter Anvin, Andy Lutomirski,
Peter Zijlstra, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-rtc@vger.kernel.org
In-Reply-To: <20260417173621.368914-8-ynorov@nvidia.com>
Yury Norov <ynorov@nvidia.com> wrote:
> --- a/drivers/net/wireless/realtek/rtw89/rtw8852b_common.c
> +++ b/drivers/net/wireless/realtek/rtw89/rtw8852b_common.c
> @@ -206,9 +206,9 @@ static void rtw8852bx_efuse_parsing_tssi(struct rtw89_dev *rtwdev,
> static bool _decode_efuse_gain(u8 data, s8 *high, s8 *low)
> {
> if (high)
> - *high = sign_extend32(FIELD_GET(GENMASK(7, 4), data), 3);
> + *high = FIELD_GET_SIGNED(GENMASK(7, 4), data);
> if (low)
> - *low = sign_extend32(FIELD_GET(GENMASK(3, 0), data), 3);
> + *low = FIELD_GET(GENMASK(3, 0), data);
FIELD_GET_SIGNED()?
>
> return data != 0xff;
> }
^ permalink raw reply
* [PATCH net v2 0/2] net: airoha: Fix NULL pointer derefrences in airoha_qdma_cleanup()
From: Lorenzo Bianconi @ 2026-04-20 8:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
Fix two possible NULL pointer derefrences in airoha_qdma_cleanup routine
if airoha_qdma_init() fails.
---
Changes in v2:
- Move page_pool allocation after desc list allocation in
airoha_qdma_init_rx_queue()
- Move netif_napi_add_tx() after irq desc queue allocation in
airoha_qdma_tx_irq_init()
- Link to v1: https://lore.kernel.org/r/20260417-airoha_qdma_init_rx_queue-fix-v1-0-db9fa5e468e5@kernel.org
---
Lorenzo Bianconi (2):
net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()
drivers/net/ethernet/airoha/airoha_eth.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
---
base-commit: 0cf004ffb61cd32d140531c3a84afe975f9fc7ea
change-id: 20260417-airoha_qdma_init_rx_queue-fix-b9bfada51671
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* [PATCH net v2 1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
From: Lorenzo Bianconi @ 2026-04-20 8:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260420-airoha_qdma_init_rx_queue-fix-v2-0-d99347e5c18d@kernel.org>
If queue entry or DMA descriptor list allocation fails in
airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a
NULL pointer dereference running netif_napi_del() for RX queue NAPIs
since netif_napi_add() has never been executed to this particular RX NAPI.
The issue is due to the early ndesc initialization in
airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc
value to check if the queue is properly initialized. Fix the issue moving
ndesc initialization at end of airoha_qdma_init_tx routine.
Move page_pool allocation after descriptor list allocation in order to
avoid memory leaks if desc allocation fails.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index e1ab15f1ee7d..fc79c456743c 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -745,14 +745,18 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
dma_addr_t dma_addr;
q->buf_size = PAGE_SIZE / 2;
- q->ndesc = ndesc;
q->qdma = qdma;
- q->entry = devm_kzalloc(eth->dev, q->ndesc * sizeof(*q->entry),
+ q->entry = devm_kzalloc(eth->dev, ndesc * sizeof(*q->entry),
GFP_KERNEL);
if (!q->entry)
return -ENOMEM;
+ q->desc = dmam_alloc_coherent(eth->dev, ndesc * sizeof(*q->desc),
+ &dma_addr, GFP_KERNEL);
+ if (!q->desc)
+ return -ENOMEM;
+
q->page_pool = page_pool_create(&pp_params);
if (IS_ERR(q->page_pool)) {
int err = PTR_ERR(q->page_pool);
@@ -761,11 +765,7 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
return err;
}
- q->desc = dmam_alloc_coherent(eth->dev, q->ndesc * sizeof(*q->desc),
- &dma_addr, GFP_KERNEL);
- if (!q->desc)
- return -ENOMEM;
-
+ q->ndesc = ndesc;
netif_napi_add(eth->napi_dev, &q->napi, airoha_qdma_rx_napi_poll);
airoha_qdma_wr(qdma, REG_RX_RING_BASE(qid), dma_addr);
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 2/2] net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()
From: Lorenzo Bianconi @ 2026-04-20 8:07 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260420-airoha_qdma_init_rx_queue-fix-v2-0-d99347e5c18d@kernel.org>
If airoha_qdma_init routine fails before airoha_qdma_tx_irq_init() runs
successfully for all TX NAPIs, airoha_qdma_cleanup() will
unconditionally runs netif_napi_del() on TX NAPIs, triggering a NULL
pointer dereference. Fix the issue relying on q_tx_irq size value to
check if the TX NAPIs is properly initialized in airoha_qdma_cleanup().
Moreover, run netif_napi_add_tx() just if irq_q queue is properly
allocated.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index fc79c456743c..fd8c4f817d85 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -996,8 +996,6 @@ static int airoha_qdma_tx_irq_init(struct airoha_tx_irq_queue *irq_q,
struct airoha_eth *eth = qdma->eth;
dma_addr_t dma_addr;
- netif_napi_add_tx(eth->napi_dev, &irq_q->napi,
- airoha_qdma_tx_napi_poll);
irq_q->q = dmam_alloc_coherent(eth->dev, size * sizeof(u32),
&dma_addr, GFP_KERNEL);
if (!irq_q->q)
@@ -1007,6 +1005,9 @@ static int airoha_qdma_tx_irq_init(struct airoha_tx_irq_queue *irq_q,
irq_q->size = size;
irq_q->qdma = qdma;
+ netif_napi_add_tx(eth->napi_dev, &irq_q->napi,
+ airoha_qdma_tx_napi_poll);
+
airoha_qdma_wr(qdma, REG_TX_IRQ_BASE(id), dma_addr);
airoha_qdma_rmw(qdma, REG_TX_IRQ_CFG(id), TX_IRQ_DEPTH_MASK,
FIELD_PREP(TX_IRQ_DEPTH_MASK, size));
@@ -1398,8 +1399,12 @@ static void airoha_qdma_cleanup(struct airoha_qdma *qdma)
}
}
- for (i = 0; i < ARRAY_SIZE(qdma->q_tx_irq); i++)
+ for (i = 0; i < ARRAY_SIZE(qdma->q_tx_irq); i++) {
+ if (!qdma->q_tx_irq[i].size)
+ continue;
+
netif_napi_del(&qdma->q_tx_irq[i].napi);
+ }
for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
if (!qdma->q_tx[i].ndesc)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
From: Kangzheng Gu @ 2026-04-20 8:09 UTC (permalink / raw)
To: Simon Horman
Cc: Paolo Abeni, davem, edumazet, kuba, kees, thorsten.blum, arnd,
sjur.brandeland, netdev, linux-kernel, stable
In-Reply-To: <20260414112951.GD469338@kernel.org>
Thanks for all of your advice, I am preparing a new version of patch now.
Simon Horman <horms@kernel.org> 于2026年4月14日周二 19:29写道：
>
> On Mon, Apr 13, 2026 at 11:30:53AM +0200, Paolo Abeni wrote:
> > On 4/12/26 3:57 PM, Simon Horman wrote:
> > > I am wondering if it would be best to follow the pattern for
> > > writing linkparam.u.utility.name elsewhere in this function.
> > > That:
> > > 1. Uses a somewhat more succinct loop control structure
> > > 2. Silently truncates input without updating cmdrsp if overrun would occur
> > >
> > > Something like this (compile tested only!):
> > >
> > > diff --git a/net/caif/cfctrl.c b/net/caif/cfctrl.c
> > > index c6cc2bfed65d..ba184c11386e 100644
> > > --- a/net/caif/cfctrl.c
> > > +++ b/net/caif/cfctrl.c
> > > @@ -15,6 +15,7 @@
> > > #include <net/caif/cfctrl.h>
> > >
> > > #define container_obj(layr) container_of(layr, struct cfctrl, serv.layer)
> > > +#define RFM_VOLUME_LEN 20
> > > #define UTILITY_NAME_LENGTH 16
> > > #define CFPKT_CTRL_PKT_LEN 20
> > >
> > > @@ -414,10 +415,11 @@ static int cfctrl_link_setup(struct cfctrl *cfctrl, struct cfpkt *pkt, u8 cmdrsp
> > > */
> > > linkparam.u.rfm.connid = cfpkt_extr_head_u32(pkt);
> > > cp = (u8 *) linkparam.u.rfm.volume;
> > > - for (tmp = cfpkt_extr_head_u8(pkt);
> > > - cfpkt_more(pkt) && tmp != '\0';
> > > - tmp = cfpkt_extr_head_u8(pkt))
> > > + caif_assert(sizeof(linkparam.u.rfm.volume) >= RFM_VOLUME_LEN);
> > > + for(i = 0; i < RFM_VOLUME_LEN - 1 && cfpkt_more(pkt); i++) {
> > > + tmp = cfpkt_extr_head_u8(pkt);
> > > *cp++ = tmp;
> > > + }
> > > *cp = '\0';
> > >
> > > if (CFCTRL_ERR_BIT & cmdrsp)
> >
> > I agree that the code suggested by Simon is clearer. Note that AFAICS it
> > lacks an additional `tmp!= '\0'` check to break the loop, but even with
> > that added it should be preferable.
>
> Sorry, I left out the `tmp!= '\0' check.
> That was unintentional and I agree it should be there.
^ permalink raw reply
* [syzbot ci] Re: net: nsh: handle nested NSH headers during GSO
From: syzbot ci @ 2026-04-20 8:12 UTC (permalink / raw)
To: bird, caoruide123, davem, edumazet, horms, jbenc, kuba, lx24,
n05ec, netdev, pabeni, tomapufckgml, yifanwucs, yuantan098
Cc: syzbot, syzkaller-bugs
In-Reply-To: <6112cce99b4e3571444a616d0fb19e91e2fcca72.1776597598.git.caoruide123@gmail.com>
syzbot ci has tested the following series
[v1] net: nsh: handle nested NSH headers during GSO
https://lore.kernel.org/all/6112cce99b4e3571444a616d0fb19e91e2fcca72.1776597598.git.caoruide123@gmail.com
* [PATCH net 1/1] net: nsh: handle nested NSH headers during GSO
and found the following issue:
WARNING in nsh_gso_segment
Full report is available here:
https://ci.syzbot.org/series/13f77bac-014d-4059-9187-fbdbcb6a6540
***
WARNING in nsh_gso_segment
tree: net
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base: 0cf004ffb61cd32d140531c3a84afe975f9fc7ea
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/193058cd-cd88-4bb0-a6e6-b43b6179fcd9/config
syz repro: https://ci.syzbot.org/findings/446db72d-a630-471c-b369-2ef1f7b3b6ed/syz_repro
------------[ cut here ]------------
offset != (typeof(skb->mac_header))offset
WARNING: ./include/linux/skbuff.h:3173 at skb_reset_mac_header include/linux/skbuff.h:3173 [inline], CPU#1: syz.1.20/5978
WARNING: ./include/linux/skbuff.h:3173 at nsh_gso_segment+0x833/0x12d0 net/nsh/nsh.c:107, CPU#1: syz.1.20/5978
Modules linked in:
CPU: 1 UID: 0 PID: 5978 Comm: syz.1.20 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:skb_reset_mac_header include/linux/skbuff.h:3173 [inline]
RIP: 0010:nsh_gso_segment+0x833/0x12d0 net/nsh/nsh.c:107
Code: 2f 08 00 00 48 8b 7c 24 60 44 89 f6 e8 46 83 e4 fd 48 85 c0 0f 84 20 08 00 00 e8 48 af 31 f6 e9 ab fb ff ff e8 3e af 31 f6 90 <0f> 0b 90 e9 43 fd ff ff e8 30 af 31 f6 90 0f 0b 90 e9 39 fe ff ff
RSP: 0018:ffffc90004847220 EFLAGS: 00010293
RAX: ffffffff8b93aeb2 RBX: ffff88817362a6d8 RCX: ffff88810f088000
RDX: 0000000000000000 RSI: 0000000000010040 RDI: 0000000000010000
RBP: ffffc90004847390 R08: ffff88810f088000 R09: 0000000000000005
R10: 0000000000000005 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000010040 R14: dffffc0000000000 R15: 0000000000000074
FS: 00007f28e9ed36c0(0000) GS:ffff8882a9245000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000010000 CR3: 0000000170f06000 CR4: 00000000000006f0
Call Trace:
<TASK>
skb_mac_gso_segment+0x31c/0x690 net/core/gso.c:53
__skb_gso_segment+0x376/0x540 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0xa21/0x14a0 net/core/dev.c:4039
validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4089
sch_direct_xmit+0xdf/0x4c0 net/sched/sch_generic.c:357
__dev_xmit_skb net/core/dev.c:4209 [inline]
__dev_queue_xmit+0x180f/0x3950 net/core/dev.c:4831
packet_snd net/packet/af_packet.c:3077 [inline]
packet_sendmsg+0x3ebc/0x50f0 net/packet/af_packet.c:3109
sock_sendmsg_nosec net/socket.c:787 [inline]
__sock_sendmsg net/socket.c:802 [inline]
__sys_sendto+0x672/0x710 net/socket.c:2265
__do_sys_sendto net/socket.c:2272 [inline]
__se_sys_sendto net/socket.c:2268 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2268
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f28e8f9c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f28e9ed3028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f28e9216090 RCX: 00007f28e8f9c819
RDX: 00000000000100a6 RSI: 0000200000000180 RDI: 0000000000000005
RBP: 00007f28e9032c91 R08: 0000200000000140 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f28e9216128 R14: 00007f28e9216090 R15: 00007ffd50249d78
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [PATCH v5] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
From: Arnd Bergmann @ 2026-04-20 8:14 UTC (permalink / raw)
To: Kangzheng Gu, Simon Horman
Cc: Paolo Abeni, David S . Miller, Eric Dumazet, Jakub Kicinski,
Kees Cook, Thorsten Blum, sjur.brandeland, Netdev, linux-kernel,
stable
In-Reply-To: <CAKvcANPEa91paujTQjpW2hZhpXEhwfOjjy6CsN=OJ32iXYXdTA@mail.gmail.com>
On Mon, Apr 20, 2026, at 10:09, Kangzheng Gu wrote:
> Thanks for all of your advice, I am preparing a new version of patch now.
If you are actively using CAIF, please chime in at
https://lore.kernel.org/all/20260416182829.1440262-1-kuba@kernel.org/
If you are not actually using CAIF, maybe wait a little bit before
spending more time on it because the patches may no longer
apply if it gets removed due to lack of users.
Arnd
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] idpf: do not perform flow ops when netdev is detached
From: Kwapulinski, Piotr @ 2026-04-20 8:22 UTC (permalink / raw)
To: Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller,
Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
David Decotigny, Singhai, Anjali, Samudrala, Sridhar,
Brian Vazquez, Tantilov, Emil S
In-Reply-To: <20260419192555.3631327-1-boolli@google.com>
>-----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
>+
> 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 net 1/1] mptcp: hold subflow request owners when cloning reqsk
From: Matthieu Baerts @ 2026-04-20 8:26 UTC (permalink / raw)
To: Yuan Tan, Kuniyuki Iwashima
Cc: Ren Wei, netdev, mptcp, davem, edumazet, kuba, pabeni, horms,
ncardwell, dsahern, martineau, geliang, daniel, kafai, yifanwucs,
tomapufckgml, bird, caoruide123, enjou1224z
In-Reply-To: <05a19f8d-360e-41d1-bc8a-0b4caab3d354@gmail.com>
Hi Yuan Tan,
On 19/04/2026 11:51, Yuan Tan wrote:
>
> On 4/16/2026 11:48 AM, Kuniyuki Iwashima wrote:
>> On Thu, Apr 16, 2026 at 10:45 AM Matthieu Baerts <matttbe@kernel.org> wrote:
>>> Hi Ren,
>>>
>>> On 15/04/2026 11:31, Ren Wei wrote:
>>>> From: Ruide Cao <caoruide123@gmail.com>
>>>>
>>>> TCP request migration clones pending request sockets with
>>>> inet_reqsk_clone(). For MPTCP MP_JOIN requests this raw-copies
>>>> subflow_req->msk, but the cloned request does not take a new reference.
>>>>
>>>> Both the original and the cloned request can later drop the same msk in
>>>> subflow_req_destructor(), and a migrated request may keep a dangling msk
>>>> pointer after the original owner has already been released.
>>>>
>>>> Add a request_sock clone callback and let MPTCP grab a reference for cloned
>>>> subflow requests that carry an msk. This keeps ownership balanced across
>>>> both successful migrations and failed clone/insert paths without changing
>>>> other protocols.
(...)
>>>> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
>>>> index e961936b6be7..140a9e96ad58 100644
>>>> --- a/net/ipv4/inet_connection_sock.c
>>>> +++ b/net/ipv4/inet_connection_sock.c
>>>> @@ -954,6 +954,9 @@ static struct request_sock *inet_reqsk_clone(struct request_sock *req,
>>>> if (sk->sk_protocol == IPPROTO_TCP && tcp_rsk(nreq)->tfo_listener)
>>>> rcu_assign_pointer(tcp_sk(nreq->sk)->fastopen_rsk, nreq);
>>> (Maybe TCP with fastopen could be this other user to call
>>> rcu_assign_pointer()? (net-next material))
>>>
>>>> + if (req->rsk_ops->init_clone)
>>>> + req->rsk_ops->init_clone(req, nreq);
>> I think a simple direct call is better.
>>
>> #ifdef CONFIG_MPTCP
>> if (tcp_rsk(req)->is_mptcp)
>> mptcp_reqsk_clone(nreq);
>> #endif
>>
> Thank you very much for your suggestion. We will use this approach in
> the next version of the patch. Would you like us to add your
> Suggested-by tag?
No need to add a Suggested-by tag: this tag is used when the whole patch
idea has been suggested by someone. That's not the case here: we only
proposed a small modification in the code, without changing the idea.
https://docs.kernel.org/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* [PATCH net v2 0/8] xsk: fix bugs around xsk skb allocation
From: Jason Xing @ 2026-04-20 8:27 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend
Cc: bpf, netdev, Jason Xing
From: Jason Xing <kernelxing@tencent.com>
There are rare issues around xsk_build_skb(). Some of them
were founded by Sashiko[1][2].
[1]: https://lore.kernel.org/all/20260415082654.21026-1-kerneljasonxing@gmail.com/
[2]: https://lore.kernel.org/all/20260418045644.28612-1-kerneljasonxing@gmail.com/
---
v2
Link: https://lore.kernel.org/all/20260418045644.28612-1-kerneljasonxing@gmail.com/#t
1. add four patches spotted by sashiko to fix buggy pre-existing
behavior
2. adjust the order of 8 patches.
Jason Xing (8):
xsk: reject sw-csum UMEM binding to IFF_TX_SKB_NO_LINEAR devices
xsk: handle NULL dereference of the skb without frags issue
xsk: fix use-after-free of xs->skb in xsk_build_skb() free_err path
xsk: prevent CQ desync when freeing half-built skbs in xsk_build_skb()
xsk: avoid skb leak in XDP_TX_METADATA case
xsk: free the skb when hitting the upper bound MAX_SKB_FRAGS
xsk: fix xsk_addrs slab leak on multi-buffer error path
xsk: fix u64 descriptor address truncation on 32-bit architectures
net/xdp/xsk.c | 88 +++++++++++++++++++++++++++++++++--------
net/xdp/xsk_buff_pool.c | 3 ++
2 files changed, 75 insertions(+), 16 deletions(-)
--
2.41.3
^ 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