* Re: [PATCH net] net/sched: act_ct: fix skb leak on fragment check failure
From: Jamal Hadi Salim @ 2026-04-16 15:31 UTC (permalink / raw)
To: Dudu Lu; +Cc: netdev, jiri, horms
In-Reply-To: <20260416130138.38050-1-phx0fer@gmail.com>
On Thu, Apr 16, 2026 at 9:01 AM Dudu Lu <phx0fer@gmail.com> wrote:
>
> When tcf_ct_handle_fragments() returns an error other than -EINPROGRESS
> (e.g. -EINVAL from malformed fragments), tcf_ct_act() jumps to out_frag
> which unconditionally returns TC_ACT_CONSUMED. This tells the caller the
> skb was consumed, but it was not freed, leaking one skb per malformed
> fragment.
>
> TC_ACT_CONSUMED is only correct for -EINPROGRESS, where defragmentation
> is genuinely in progress and the skb has been queued. For all other
> errors the skb is still owned by the caller and must be freed via
> TC_ACT_SHOT.
>
> Fixes: 3f14b377d01d ("net/sched: act_ct: fix skb leak and crash on ooo frags")
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>
Do you have a reproducer? Always helps adding at least a tdc test.
Also: How did you find this issue? was it AI? If yes, please add the
tag "Assisted-by:<AI name here>"
cheers,
jamal
> ---
> net/sched/act_ct.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
> index 7d5e50c921a0..870655f682bd 100644
> --- a/net/sched/act_ct.c
> +++ b/net/sched/act_ct.c
> @@ -1107,8 +1107,10 @@ TC_INDIRECT_SCOPE int tcf_ct_act(struct sk_buff *skb, const struct tc_action *a,
> return retval;
>
> out_frag:
> - if (err != -EINPROGRESS)
> + if (err != -EINPROGRESS) {
> tcf_action_inc_drop_qstats(&c->common);
> + return TC_ACT_SHOT;
> + }
> return TC_ACT_CONSUMED;
>
> drop:
> --
> 2.39.3 (Apple Git-145)
>
^ permalink raw reply
* Re: [PATCH net v3 2/5] i40e: skip unnecessary VF reset when setting trust
From: Simon Horman @ 2026-04-16 15:31 UTC (permalink / raw)
To: jtornosm
Cc: 'Simon Horman', netdev, intel-wired-lan, jesse.brandeburg,
anthony.l.nguyen, davem, edumazet, kuba, pabeni,
przemyslaw.kitszel
In-Reply-To: <20260414110006.124286-3-jtornosm@redhat.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
---
i40e: skip unnecessary VF reset when setting trust
This commit skips the VF reset when setting VF trust, unless trust is
being removed from a VF with ADQ cloud filters. The goal is to avoid
a 10-second delay caused by the reset during trust changes.
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> index a26c3d47ec156..fea267af7afe6 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> @@ -4987,16 +4987,21 @@ int i40e_ndo_set_vf_trust(struct net_device *netdev, int vf_id, bool setting)
> set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state);
> pf->vsi[vf->lan_vsi_idx]->flags |= I40E_VSI_FLAG_FILTER_CHANGED;
>
> - i40e_vc_reset_vf(vf, true);
By skipping the VF reset here, does the VF's privilege capability flag
become permanently desynchronized from its trust state?
The underlying capability flag I40E_VIRTCHNL_VF_CAP_PRIVILEGE is used by
Virtchnl handlers like i40e_check_vf_permission() to authorize privileged
actions. This flag is exclusively updated in i40e_alloc_vf_res(), which is
only invoked during a VF reset.
Without the reset, it appears that granting trust fails to give the VF
actual privileged capabilities, and revoking trust leaves the privilege
bit set indefinitely, allowing an untrusted VF to perform unauthorized
privileged operations.
Additionally, could revoking trust fail to scrub the VF's actively
configured privileged hardware state, such as promiscuous mode and excess
MAC/VLAN filters?
Trusted VFs can explicitly enable promiscuous mode and configure MAC/VLAN
filters beyond strict limits. In the original code, i40e_vc_reset_vf()
dismantled these states by calling i40e_cleanup_reset_vf(), which
explicitly invokes i40e_config_vf_promiscuous_mode(..., false, false) and
destroys the VSI.
By skipping the reset, an untrusted VF retains its previously configured
promiscuous mode, allowing it to continue intercepting unauthorized traffic.
> dev_info(&pf->pdev->dev, "VF %u is now %strusted\n",
> vf_id, setting ? "" : "un");
>
> + /* Only reset VF if we're removing trust and it has ADQ cloud filters.
> + * Cloud filters can only be added when trusted, so they must be
> + * removed when trust is revoked. Other trust changes don't require
> + * reset - MAC/VLAN filter sync happens through normal operation.
> + */
> if (vf->adq_enabled) {
> if (!vf->trusted) {
> dev_info(&pf->pdev->dev,
> "VF %u no longer Trusted, deleting all cloud filters\n",
> vf_id);
> i40e_del_all_cloud_filters(vf);
> + i40e_vc_reset_vf(vf, true);
Is it possible that reordering i40e_del_all_cloud_filters() before
i40e_vc_reset_vf() creates a race condition on vf->cloud_filter_list?
i40e_del_all_cloud_filters() performs lockless modifications on
vf->cloud_filter_list while running from the netlink context.
In the original code, i40e_vc_reset_vf() ran first, which immediately
cleared I40E_VF_STATE_ACTIVE. This prevented concurrent Virtchnl requests
like VIRTCHNL_OP_ADD_CLOUD_FILTER from modifying the list, because their
handlers in i40e_vc_process_vf_msg() abort if I40E_VF_STATE_ACTIVE is
not set.
By calling i40e_del_all_cloud_filters() first, the VF is left in the
active state. The PF service task could concurrently process an
ADD_CLOUD_FILTER message, executing hlist_add_head() simultaneously with
hlist_for_each_entry_safe(), which might cause list corruption.
> }
> }
>
^ permalink raw reply
* Re: [PATCH] net: sched: teql: fix use-after-free in teql_master_xmit
From: Jamal Hadi Salim @ 2026-04-16 15:43 UTC (permalink / raw)
To: Kito Xu (veritas501)
Cc: Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <20260413094448.2263828-1-hxzene@gmail.com>
On Mon, Apr 13, 2026 at 5:44 AM Kito Xu (veritas501) <hxzene@gmail.com> wrote:
>
> teql_destroy() traverses the circular slave list to unlink a slave
> qdisc. It reads master->slaves as both the starting point and the
> do-while termination sentinel. However, the data-path writers
> teql_dequeue() and teql_master_xmit() concurrently modify
> master->slaves without holding RTNL, running in softirq or process
> context respectively. If master->slaves is overwritten to an
> already-visited node mid-traversal, the loop exits early without
> finding the target slave. The slave is never unlinked, but its memory
> is freed by call_rcu() -- leaving a dangling pointer in the circular
> list. The next teql_master_xmit() traversal dereferences freed memory.
>
Do you have a reproducer?
And it would be nice to get a tdc test from you.
Also, please use assisted-by: or even suggested-by if this patch was
suggested by AI.
cheers,
jamal
> race condition:
>
> CPU 0 (teql_destroy, RTNL held) CPU 1 (teql_dequeue, softirq)
> ----------------------------------- -----------------------------
> prev = master->slaves; // = A
> q = NEXT_SLAVE(A); // = B
> B == A? No.
> prev = B;
> /* slave C's queue drains */
> skb == NULL ->
> dat->m->slaves = C; /* write! */
>
> q = NEXT_SLAVE(B); // = C
> C == A? No.
> prev = C;
> /* check: (prev=C) != master->slaves(C)?
> FALSE -> loop exits! */
> /* A never unlinked, freed by call_rcu */
>
> CPU 0 (teql_master_xmit, later)
> -----------------------------------
> q = NEXT_SLAVE(C); // = A (freed!)
> slave = qdisc_dev(A); // UAF!
>
> Fix this by saving master->slaves into a local `head` variable at the
> start of teql_destroy() and using it as a stable sentinel for the
> entire traversal. Also annotate all data-path accesses to
> master->slaves with READ_ONCE/WRITE_ONCE to prevent store-tearing and
> compiler-introduced re-reads.
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in teql_master_xmit+0xeae/0x14a0
> Read of size 8 at addr ffff888018074040 by task poc/162
>
> CPU: 2 UID: 0 PID: 162 Comm: poc Not tainted 7.0.0-rc7-next-20260410 #10 PREEMPTLAZY
> Call Trace:
> <TASK>
> dump_stack_lvl+0x64/0x80
> print_report+0xd0/0x5e0
> kasan_report+0xce/0x100
> teql_master_xmit+0xeae/0x14a0
> dev_hard_start_xmit+0xcd/0x5b0
> sch_direct_xmit+0x12e/0xac0
> __qdisc_run+0x3b1/0x1a70
> __dev_queue_xmit+0x2257/0x3100
> ip_finish_output2+0x615/0x19c0
> ip_output+0x158/0x2b0
> ip_send_skb+0x11b/0x160
> udp_send_skb+0x64b/0xd80
> udp_sendmsg+0x138c/0x1ec0
> __sys_sendto+0x331/0x3a0
> __x64_sys_sendto+0xe0/0x1c0
> do_syscall_64+0x64/0x680
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> The buggy address belongs to the object at ffff888018074000
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 64 bytes inside of
> freed 512-byte region [ffff888018074000, ffff888018074200)
> ==================================================================
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com>
> ---
> net/sched/sch_teql.c | 24 ++++++++++++++----------
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
> index ec4039a201a2..2e86397a5219 100644
> --- a/net/sched/sch_teql.c
> +++ b/net/sched/sch_teql.c
> @@ -101,7 +101,7 @@ teql_dequeue(struct Qdisc *sch)
> if (skb == NULL) {
> struct net_device *m = qdisc_dev(q);
> if (m) {
> - dat->m->slaves = sch;
> + WRITE_ONCE(dat->m->slaves, sch);
> netif_wake_queue(m);
> }
> } else {
> @@ -136,19 +136,23 @@ teql_destroy(struct Qdisc *sch)
> if (!master)
> return;
>
> - prev = master->slaves;
> + prev = READ_ONCE(master->slaves);
> if (prev) {
> + struct Qdisc *head = prev;
> +
> do {
> q = NEXT_SLAVE(prev);
> if (q == sch) {
> NEXT_SLAVE(prev) = NEXT_SLAVE(q);
> - if (q == master->slaves) {
> - master->slaves = NEXT_SLAVE(q);
> - if (q == master->slaves) {
> + if (q == head) {
> + WRITE_ONCE(master->slaves,
> + NEXT_SLAVE(q));
> + if (q == NEXT_SLAVE(q)) {
> struct netdev_queue *txq;
>
> txq = netdev_get_tx_queue(master->dev, 0);
> - master->slaves = NULL;
> + WRITE_ONCE(master->slaves,
> + NULL);
>
> dev_reset_queue(master->dev,
> txq, NULL);
> @@ -158,7 +162,7 @@ teql_destroy(struct Qdisc *sch)
> break;
> }
>
> - } while ((prev = q) != master->slaves);
> + } while ((prev = q) != head);
> }
> }
>
> @@ -285,7 +289,7 @@ static netdev_tx_t teql_master_xmit(struct sk_buff *skb, struct net_device *dev)
> int subq = skb_get_queue_mapping(skb);
> struct sk_buff *skb_res = NULL;
>
> - start = master->slaves;
> + start = READ_ONCE(master->slaves);
>
> restart:
> nores = 0;
> @@ -317,7 +321,7 @@ static netdev_tx_t teql_master_xmit(struct sk_buff *skb, struct net_device *dev)
> netdev_start_xmit(skb, slave, slave_txq, false) ==
> NETDEV_TX_OK) {
> __netif_tx_unlock(slave_txq);
> - master->slaves = NEXT_SLAVE(q);
> + WRITE_ONCE(master->slaves, NEXT_SLAVE(q));
> netif_wake_queue(dev);
> master->tx_packets++;
> master->tx_bytes += length;
> @@ -329,7 +333,7 @@ static netdev_tx_t teql_master_xmit(struct sk_buff *skb, struct net_device *dev)
> busy = 1;
> break;
> case 1:
> - master->slaves = NEXT_SLAVE(q);
> + WRITE_ONCE(master->slaves, NEXT_SLAVE(q));
> return NETDEV_TX_OK;
> default:
> nores = 1;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v11 net-next 3/5] psp: add a new netdev event for dev unregister
From: Wei Wang @ 2026-04-16 15:50 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, Jakub Kicinski, Daniel Zahka, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman,
Wei Wang
In-Reply-To: <cb5bf340-e5fa-4866-b5c6-565709ba633c@redhat.com>
On Mon, Apr 13, 2026 at 3:48 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 4/9/26 1:14 AM, Wei Wang wrote:
> > +static int psp_netdev_event(struct notifier_block *nb, unsigned long event,
> > + void *ptr)
> > +{
> > + struct net_device *dev = netdev_notifier_info_to_dev(ptr);
> > + struct psp_dev *psd;
> > +
> > + if (event != NETDEV_UNREGISTER)
> > + return NOTIFY_DONE;
> > +
> > + rcu_read_lock();
> > + psd = rcu_dereference(dev->psp_dev);
> > + if (psd && psp_dev_tryget(psd)) {
> > + rcu_read_unlock();
> > + mutex_lock(&psd->lock);
> > + psp_dev_disassoc_one(psd, dev);
> > + mutex_unlock(&psd->lock);
> > + psp_dev_put(psd);
>
> Sashiko notes that the above is racy:
>
> ---
> Can this code race with psp_nl_dev_assoc_doit() and permanently leak a
> net_device reference?
> If CPU1 is executing psp_nl_dev_assoc_doit() and CPU2 is unregistering the
> device, the following interleaving could happen:
> CPU1 (psp_nl_dev_assoc_doit)
> assoc_dev = dev_get_by_index(...) // acquires a reference
> CPU2 (unregister_netdevice)
> psp_netdev_event()
> psd = rcu_dereference(dev->psp_dev); // sees NULL, returns
> NOTIFY_DONE
> CPU1 (psp_nl_dev_assoc_doit)
> cmpxchg(&assoc_dev->psp_dev, NULL, psd); // succeeds!
> list_add(...) // adds to psd->assoc_dev_list
> If this occurs, the notifier misses the unregistration event since it runs
> before the device is fully associated. The unregistering thread will then
> enter netdev_wait_allrefs() and wait indefinitely because the reference
> held in assoc_dev_list is never released.
> ---
>
Hmm... Good catch. I think I could do the following to fix this:
On psp_nl_dev_assoc_doit():
- grab psd->lock
- Do cmpxchg(&assoc_dev->psp_dev, NULL, psd)
- Do if (READ_ONCE(assoc_dev->reg_state) != NETREG_REGISTERED) {
err = -ENODEV;
goto cleanup;
}
On unregister_netdevice side, the sequence of calls are as follows in
unregister_netdevice_many_notify():
- WRITE_ONCE(reg_state, NETREG_UNREGISTERING);
- synchronize_net()
- call_netdevice_notifiers(NETDEV_UNREGISTER, dev) =>
psp_netdev_event() => Read psd => grab psd->lock and do clean up if
psd != NULL
With this logic, at least 1 side would do the cleanup. And the clean
up path is guarded by psd->lock so it is also sequenced and should not
have double free issue.
Let me know what you think.
> /P
>
^ permalink raw reply
* Re: [PATCH net v3] net/sched: taprio: fix NULL pointer dereference in class dump
From: Jamal Hadi Salim @ 2026-04-16 15:50 UTC (permalink / raw)
To: Weiming Shi
Cc: Vinicius Costa Gomes, Jiri Pirko, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, Xiang Mei
In-Reply-To: <20260414104311.74115-2-bestswngs@gmail.com>
On Tue, Apr 14, 2026 at 6:43 AM Weiming Shi <bestswngs@gmail.com> wrote:
>
> When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
> is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
> Subsequent RTM_GETTCLASS dump operations walk all classes via
> taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
> returning the NULL pointer, then dereferences it to read child->handle,
> causing a kernel NULL pointer dereference.
>
> The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
> with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
> namespaces enabled, an unprivileged local user can trigger a kernel
> panic by creating a taprio qdisc inside a new network namespace,
> grafting an explicit child qdisc, deleting it, and requesting a class
> dump. The RTM_GETTCLASS dump itself requires no capability.
>
While i would say this looks good to me, I hate to sound like a broken
record but:
Do you have a reproducer?
And it would be nice to get a tdc test from you.
Also, please use assisted-by: or even suggested-by if this patch was
suggested by AI.
cheers,
jamal
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2475)
> Call Trace:
> <TASK>
> tc_fill_tclass (net/sched/sch_api.c:1966)
> qdisc_class_dump (net/sched/sch_api.c:2329)
> taprio_walk (net/sched/sch_taprio.c:2510)
> tc_dump_tclass_qdisc (net/sched/sch_api.c:2353)
> tc_dump_tclass_root (net/sched/sch_api.c:2370)
> tc_dump_tclass (net/sched/sch_api.c:2431)
> rtnl_dumpit (net/core/rtnetlink.c:6827)
> netlink_dump (net/netlink/af_netlink.c:2325)
> rtnetlink_rcv_msg (net/core/rtnetlink.c:6927)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> </TASK>
>
> Fix this by substituting &noop_qdisc when new is NULL in
> taprio_graft(), following the same pattern used by multiq_graft() and
> prio_graft(). This ensures q->qdiscs[] slots are never NULL, making
> control-plane dump paths safe without requiring individual NULL checks.
>
> Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq)
> previously had explicit NULL guards that would drop/skip the packet
> cleanly, update those checks to test for &noop_qdisc instead. Without
> this, packets would reach taprio_enqueue_one() which increments the root
> qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc
> drops the packet but those counters are never rolled back, permanently
> inflating the root qdisc's statistics.
>
> Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> v3: fix broken patch
> v2: Also update NULL guards in taprio_enqueue() and
> taprio_dequeue_from_txq() to avoid qlen/backlog inflation (Paolo).
> ---
> net/sched/sch_taprio.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> index f721c03514f60..07723b156c5b3 100644
> --- a/net/sched/sch_taprio.c
> +++ b/net/sched/sch_taprio.c
> @@ -634,7 +634,7 @@ static int taprio_enqueue(struct sk_buff *skb, struct Qdisc *sch,
> queue = skb_get_queue_mapping(skb);
>
> child = q->qdiscs[queue];
> - if (unlikely(!child))
> + if (unlikely(child == &noop_qdisc))
> return qdisc_drop(skb, sch, to_free);
>
> if (taprio_skb_exceeds_queue_max_sdu(sch, skb)) {
> @@ -717,7 +717,7 @@ static struct sk_buff *taprio_dequeue_from_txq(struct Qdisc *sch, int txq,
> int len;
> u8 tc;
>
> - if (unlikely(!child))
> + if (unlikely(child == &noop_qdisc))
> return NULL;
>
> if (TXTIME_ASSIST_IS_ENABLED(q->flags))
> @@ -2183,6 +2183,9 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> if (!dev_queue)
> return -EINVAL;
>
> + if (!new)
> + new = &noop_qdisc;
> +
> if (dev->flags & IFF_UP)
> dev_deactivate(dev);
>
> @@ -2196,14 +2199,14 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> *old = q->qdiscs[cl - 1];
> if (FULL_OFFLOAD_IS_ENABLED(q->flags)) {
> WARN_ON_ONCE(dev_graft_qdisc(dev_queue, new) != *old);
> - if (new)
> + if (new != &noop_qdisc)
> qdisc_refcount_inc(new);
> if (*old)
> qdisc_put(*old);
> }
>
> q->qdiscs[cl - 1] = new;
> - if (new)
> + if (new != &noop_qdisc)
> new->flags |= TCQ_F_ONETXQUEUE | TCQ_F_NOPARENT;
>
> if (dev->flags & IFF_UP)
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release()
From: Jakub Kicinski @ 2026-04-16 16:08 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Alexander Stein, Andrew Lunn, Heiner Kallweit, Alexandre Torgue,
Andrew Lunn, David S. Miller, Eric Dumazet, linux-arm-kernel,
linux-stm32, Maxime Coquelin, netdev, Paolo Abeni
In-Reply-To: <aeDojTdDTELfpT0X@shell.armlinux.org.uk>
On Thu, 16 Apr 2026 14:47:57 +0100 Russell King (Oracle) wrote:
> The next problem will be netdev's policy over reviews vs patches
> balance which I'm already in deficit, and I have *NO* *TIME*
> what so ever to review patches - let alone propose patches to
> fix people's problems.
>
> So I'm going to say this plainly: if netdev wants to enforce that
> rule, then I won't be fixing people's problems.
Do you have a better proposal?
I'm under the same pressure of million stupid projects from my employer
as you are. Do y'all think that upstream maintainers have time given by
their employers to do the reviews? SMH.
^ permalink raw reply
* Re: [PATCH v3 0/4] Rust netlink support + use in Rust Binder
From: Jakub Kicinski @ 2026-04-16 16:11 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Greg Kroah-Hartman, Arve Hjønnevåg,
Todd Kjos, Christian Brauner, Carlos Llamas, linux-kernel,
rust-for-linux, netdev
In-Reply-To: <20260415-binder-netlink-v3-0-84be9ba63ee2@google.com>
On Wed, 15 Apr 2026 09:37:50 +0000 Alice Ryhl wrote:
> The C Binder driver exposes messages over netlink when transactions
> fail, so that a userpace daemon can respond to processes with many
> failing transactions.
net-next is closed for the duration of the merge window, so that
people can take a mental break and increasingly catch up on all
the accumulated CI/AI backed work. Please come back in 2 weeks.
^ permalink raw reply
* Re: [PATCH net v6 1/2] flow_dissector: do not dissect PPPoE PFC frames
From: Jakub Kicinski @ 2026-04-16 16:17 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, netdev, linux-kernel
In-Reply-To: <e1fd74dd-4fd5-4a67-b4c5-5911395b9dbe@linux.dev>
On Wed, 15 Apr 2026 21:42:09 +0800 Qingfang Deng wrote:
> The patch state is "Changes Requested" in patchwork but I haven't
> received any feedback. Was it set by mistake?
Fixed, thanks for the report.
^ permalink raw reply
* Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR
From: Sebastian Andrzej Siewior @ 2026-04-16 16:18 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netdev, (JC), Jayachandran, David S. Miller, Andrew Lunn,
Chintan Vankar, Danish Anwar, Daolin Qiu, Eric Dumazet,
Felix Maurer, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Simon Horman, Raghavendra, Vignesh, Bajjuri, Praneeth,
TK, Pratheesh Gangadhar, Muralidharan, Neelima
In-Reply-To: <willemdebruijn.kernel.1f3d8356e4a5a@gmail.com>
On 2026-04-06 10:47:56 [-0400], Willem de Bruijn wrote:
Hi Willem,
> So the requirement is for a communication path between userspace and
> the driver over packet sockets.
>
> Existing options that work for both rx and tx are
>
> - in-band: a packet header or footer
> - mark, metadata
> - maybe: vlan tags
>
> These require changes in the HSR driver to use them, but no changes in
> the protocol independent core logic, which includes packet sockets.
>
> As I mentioned before we cannot sprinkle protocol specific code
> throughout protocol independent core code. That quickly leads to an
> unmaintainable mess. PTP over HSR is a particular small niche case,
> nowhere near first in line to get an exception to this guideline.
I understand your concern. I tried to make as self contained as
possible and little runtime overhead as possible.
> One perhaps interesting Rx only option I had missed before is
> SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
> device ifindex today?
The upper logic expects to poll() on the fd. If I need to filter the
device based on this then breaks the expectations.
I need also to receive packets without a timestamp so I don't think this
works.
> If so, we now only have to consider the Tx path to the HSR driver
> (the Tx path directly to the other drivers do not need this metadata).
>
> I'm not convinced that it is hard to come up with a way to send
> a packet to the HSR driver with an optional header or footer or
> vlan data (or skb->protocol perhaps?) that cannot be
> differentiated from other traffic arriving at that ndo_start_xmit.
I've been looking to skb->protocol. Maybe if the packet has ether type
set to PTP then the HSR layer could consider everything before it (the
two MAC address fields) as internal header and the actual packet starts
after that. Reasoning would be that you shouldn't send a PTP packet over
HSR without dealing with the restrictions. So this could work.
Then the question remains how to do the filtering on RX side. For the
so_mark I did open additional two sockets…
> If all this fails, we can look into a protocol independent approach
> to passing other metadata in packet sockets. to/from skb_ext or cb[],
> say.
I will try the above but it looks very hackish.
cb[] is limited to one layer. I do have a skb_ext variant working but
this requires cmsg to set it. Do you think about generic skb_ext which
is set from af_packet? But I don't think it brings much value if I can't
filter on the RX side before returning the packet to userland.
> But at this point I see enough options that do not require changes
> to packet sockets.
>
> To get back to the simplest approach: skb->mark. Is there any
> concrete risk that on this path that would conflict with other
> uses of that field? If packet sockets inject directly into this
> driver (possibly even with PACKET_QDISC_BYPASS)?
So I have a skb->mark variant working. I do read on the ethX interface
and write on the hsr0 interface (so I need two extra fd per interface).
The only concern here is that the mark value is hardcoded and could
collide with an existing firewall setup or so.
This field needs also be evaluated by the ethernet driver in case of
hw-offloading for HSR.
So far, this is the only working solution I have which does not touch
af_packet.
Let me try the header with the PTP hedaer type and the additional
sockets for RX.
It will not win a beauty contest but maybe I judge too harsh…
Sebastian
^ permalink raw reply
* Re: [PATCH net v2] net: reduce RFS/ARFS flow updates by checking LLC affinity
From: Jakub Kicinski @ 2026-04-16 16:26 UTC (permalink / raw)
To: Chuang Wang
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Stanislav Fomichev, Kuniyuki Iwashima, Samiullah Khawaja,
Hangbin Liu, Krishna Kumar, Neal Cardwell, Willem de Bruijn,
netdev, linux-kernel
In-Reply-To: <20260414035931.45692-1-nashuiliang@gmail.com>
On Tue, 14 Apr 2026 11:59:20 +0800 Chuang Wang wrote:
> Subject: [PATCH net v2] net: reduce RFS/ARFS flow updates by checking LLC affinity
"net" is for fixes, I think you want to target the "net-next" tree.
Unfortunately that tree is closed for the duration of the merge window,
please come back in 2 weeks:
https://netdev.bots.linux.dev/net-next.html
^ permalink raw reply
* RE: [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
From: Chia-Yu Chang (Nokia) @ 2026-04-16 16:36 UTC (permalink / raw)
To: Victor Nogueira, linux-hardening@vger.kernel.org, kees@kernel.org,
gustavoars@kernel.org, jhs@mojatatu.com, jiri@resnulli.us,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, horms@kernel.org, ij@kernel.org,
ncardwell@google.com, Koen De Schepper (Nokia),
g.white@cablelabs.com, ingemar.s.johansson@ericsson.com,
mirja.kuehlewind@ericsson.com, cheshire@apple.com, rs.ietf@gmx.at,
Jason_Livingood@comcast.com, vidhi_goel@apple.com
In-Reply-To: <8070149c-87c8-4d9c-ae12-6b9a956fb763@mojatatu.com>
> -----Original Message-----
> From: Victor Nogueira <victor@mojatatu.com>
> Sent: Thursday, April 16, 2026 4:27 PM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@nokia-bell-labs.com>; linux-hardening@vger.kernel.org; kees@kernel.org; gustavoars@kernel.org; jhs@mojatatu.com; jiri@resnulli.us; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; horms@kernel.org; ij@kernel.org; ncardwell@google.com; Koen De Schepper (Nokia) <koen.de_schepper@nokia-bell-labs.com>; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; vidhi_goel@apple.com
> Subject: Re: [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> On 13/04/2026 13:37, chia-yu.chang@nokia-bell-labs.com wrote:
> > From: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
> >
> > Fix dualpi2_change() to correctly enforce updated limit and memlimit
> > values after a configuration change of the dualpi2 qdisc.
> >
> > Before this patch, dualpi2_change() always attempted to dequeue
> > packets via the root qdisc (C-queue) when reducing backlog or memory
> > usage, and unconditionally assumed that a valid skb will be returned.
> > When traffic classification results in packets being queued in the
> > L-queue while the C-queue is empty, this leads to a NULL skb
> > dereference during limit or memlimit enforcement.
> >
> > This is fixed by first dequeuing from the C-queue path if it is non-empty.
> > Once the C-queue is empty, packets are dequeued directly from the
> > L-queue.s Return values from qdisc_dequeue_internal() are checked for
> > both queues. When dequeuing from the L-queue, the parent qdisc qlen
> > and backlog counters are updated explicitly to keep overall qdisc statistics consistent.
> > [...]
> > ---
> > net/sched/sch_dualpi2.c | 24 +++++++++++++++++++-----
> > 1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c index
> > 6d7e6389758d..56d4422970b6 100644
> > --- a/net/sched/sch_dualpi2.c
> > +++ b/net/sched/sch_dualpi2.c
> > @@ -872,11 +872,25 @@ static int dualpi2_change(struct Qdisc *sch, struct nlattr *opt,
> > old_backlog = sch->qstats.backlog;
> > while (qdisc_qlen(sch) > sch->limit ||
> > q->memory_used > q->memory_limit) {
> > - struct sk_buff *skb = qdisc_dequeue_internal(sch, true);
> > -
> > - q->memory_used -= skb->truesize;
> > - qdisc_qstats_backlog_dec(sch, skb);
> > - rtnl_qdisc_drop(skb, sch);
> > + int c_len = qdisc_qlen(sch) - qdisc_qlen(q->l_queue);
> > + struct sk_buff *skb = NULL;
> > +
> > + if (c_len) {
> > + skb = qdisc_dequeue_internal(sch, true);
> > + if (!skb)
> > + break;
> > + q->memory_used -= skb->truesize;
> > + rtnl_qdisc_drop(skb, sch);
> > + } else if (qdisc_qlen(q->l_queue)) {
> > + skb = qdisc_dequeue_internal(q->l_queue, true);
> > + if (!skb)
> > + break;
> > + q->memory_used -= skb->truesize;
> > + rtnl_qdisc_drop(skb, q->l_queue);
> > + /* Keep the overall qdisc stats consistent */
> > + --sch->q.qlen;
> > + qdisc_qstats_backlog_dec(sch, skb);
>
> Sashiko is hallucinating saying this will cause a UAF, it won't.
> However it is good to maintain a consistent order here.
> For example, see how sch_choke is doing [1].
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_choke.c?id=1f5ffc672165ff851063a5fd044b727ab2517ae3#n394
>
> cheers,
> Victor
Hi Victor,
Thanks for the pointer to sch_choke, it follows the order: (1) qdisc_qstats_backlog_dec(), (2) reduce qlen, and (3) rtnl_qdisc_drop().
But I've also checked sch_codel, its order is: (1) reduce qlen, (2) qdisc_qstats_backlog_dec(), and (3) rtnl_qdisc_drop().
So, the key is to place rtnl_qdisc_drop() after the reduction of qstats_backlog as well as qlen.
Then, I will follow the same order for dualpi2 in next version:
1. qdisc_dequeue_internal(q->l_queue), including (a) --q->l_queue->q.qlen, and (2) qdisc_qstats_backlog_dec(q->l_queue)
2. --sch->q.qlen
3. qdisc_qstats_backlog_dec(sch)
4. rtnl_qdisc_drop(skb, q->l_queue), which will do "qdisc_qstats_drop(q->l_queue)"
5. qdisc_qstats_drop(sch)
Thanks,
Chia-Yu
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Jakub Kicinski @ 2026-04-16 16:58 UTC (permalink / raw)
To: linux-hams
Cc: Chris Maness, hugh, Greg KH, Kuniyuki Iwashima, davem, edumazet,
horms, linux-kernel, netdev, pabeni, stable, workflows, yizhe,
f6bvp, Jean-Paul Roubelat, Joerg Reuter, Andreas Koensgen,
Thomas Sailer
In-Reply-To: <CANnsUMFVg9nZnJ_He38O9Ui1YUM_Je7MGO-y_J+oW=TG3jV1bA@mail.gmail.com>
On Sun, 12 Apr 2026 05:56:50 -0700 Chris Maness wrote:
> Thanks for your work, Hugh.
Hi good folks of hamradio.
There was a blip of activity after this thread started but now core
networking maintainers are back to reviewing all the fixes themselves
again.
We would like y'all to set up a git tree so that you can handle all the
incoming AI patches, and send them out as a pull request. This is how
wifi, bluetooth etc. operate. You already have a mailing list so that's
good.
We do not have the capacity to review all the AI generated fixes, and
ignoring security fixes does not feel like an option. I'm planning to
send a PR early next week, shedding some low usage / high CVE count code
I hope you can have the tree in place by then.
^ permalink raw reply
* [PATCH v2 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
From: chia-yu.chang @ 2026-04-16 17:09 UTC (permalink / raw)
To: victor, hxzene, linux-hardening, kees, gustavoars, jhs, jiri,
davem, edumazet, kuba, pabeni, linux-kernel, netdev, horms, ij,
ncardwell, koen.de_schepper, g.white, ingemar.s.johansson,
mirja.kuehlewind, cheshire, rs.ietf, Jason_Livingood, vidhi_goel
Cc: Chia-Yu Chang
From: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Fix dualpi2_change() to correctly enforce updated limit and memlimit values
after a configuration change of the dualpi2 qdisc.
Before this patch, dualpi2_change() always attempted to dequeue packets via
the root qdisc (C-queue) when reducing backlog or memory usage, and
unconditionally assumed that a valid skb will be returned. When traffic
classification results in packets being queued in the L-queue while the
C-queue is empty, this leads to a NULL skb dereference during limit or
memlimit enforcement.
This is fixed by first dequeuing from the C-queue path if it is non-empty.
Once the C-queue is empty, packets are dequeued directly from the L-queue.
Return values from qdisc_dequeue_internal() are checked for both queues. When
dequeuing from the L-queue, the parent qdisc qlen and backlog counters are
updated explicitly to keep overall qdisc statistics consistent.
Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc")
Reported-by: "Kito Xu (veritas501)" <hxzene@gmail.com>
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
---
net/sched/sch_dualpi2.c | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c
index fe6f5e889625..5fcec5e6e97d 100644
--- a/net/sched/sch_dualpi2.c
+++ b/net/sched/sch_dualpi2.c
@@ -868,11 +868,31 @@ static int dualpi2_change(struct Qdisc *sch, struct nlattr *opt,
old_backlog = sch->qstats.backlog;
while (qdisc_qlen(sch) > sch->limit ||
q->memory_used > q->memory_limit) {
- struct sk_buff *skb = qdisc_dequeue_internal(sch, true);
-
- q->memory_used -= skb->truesize;
- qdisc_qstats_backlog_dec(sch, skb);
- rtnl_qdisc_drop(skb, sch);
+ int c_len = qdisc_qlen(sch) - qdisc_qlen(q->l_queue);
+ struct sk_buff *skb = NULL;
+
+ if (c_len) {
+ skb = qdisc_dequeue_internal(sch, true);
+ if (!skb)
+ break;
+ q->memory_used -= skb->truesize;
+ rtnl_qdisc_drop(skb, sch);
+ } else if (qdisc_qlen(q->l_queue)) {
+ skb = qdisc_dequeue_internal(q->l_queue, true);
+ if (!skb)
+ break;
+ /* Keep the overall qdisc stats consistent */
+ --sch->q.qlen;
+ qdisc_qstats_backlog_dec(sch, skb);
+
+ q->memory_used -= skb->truesize;
+ rtnl_qdisc_drop(skb, q->l_queue);
+
+ /* After incrementing the drop counter for the L-queue
+ via rtnl_qdisc_drop(), update the parent qdisc
+ drop counter via qdisc_qstats_drop(sch) */
+ qdisc_qstats_drop(sch);
+ }
}
qdisc_tree_reduce_backlog(sch, old_qlen - qdisc_qlen(sch),
old_backlog - sch->qstats.backlog);
--
2.34.1
^ permalink raw reply related
* Path forward for NFC in the kernel
From: Jakub Kicinski @ 2026-04-16 17:10 UTC (permalink / raw)
To: Michael Thalmeier, Raymond Hackley, Michael Walle, Bongsu Jeon,
Krzysztof Kozlowski, Mark Greer
Cc: netdev
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.
^ permalink raw reply
* Re: [PATCH net] ixgbevf: fix use-after-free in VEPA multicast source pruning
From: Simon Horman @ 2026-04-16 17:13 UTC (permalink / raw)
To: Michael Bommarito
Cc: intel-wired-lan, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, stable, linux-kernel
In-Reply-To: <CAJJ9bXwQyd-cZ0h_FCNj29GZYpXyCBu444VhLGLZkf1bWYqoKQ@mail.gmail.com>
On Wed, Apr 15, 2026 at 12:30:45PM -0400, Michael Bommarito wrote:
> On Wed, Apr 15, 2026 at 12:17 PM Simon Horman <horms@kernel.org> wrote:
> > Sashiko flags a number of issues in the same function that
> > do not seem related to your patch.
> >
> > I'd suggest looking over them if you are interested in
> > follow-up work in this area.
>
> Sure, I'd be happy to keep going here if you're open to more hardening
> patches.
Speaking for myself: I'm happy to review patches that correct bugs.
I'm also happy to review patches that otherwise improve the code.
But I think the Intel people might be able to provide better guidance here.
Please be aware of the Netdev guidance on cleanups:
>
> Two Qs for you:
>
> 1. Do you want smaller patches for each or bigger method-level patches?
The general rule of thumb is one patch per problem.
Personally, I prefer small patches.
>
> 2. Anything on my list below that you would *not* want me touching?
> I'll combine with anything I can find from your Sashiko items
...
> 3. line 2769
> rule: semgrep signed-int-as-size-param-kmalloc
> match: q_vector = kzalloc(size, GFP_KERNEL) (signed size)
> status: untriaged
>
> 4. line 3452
> rule: semgrep signed-int-as-size-param-kmalloc
> match: tx_ring->tx_buffer_info = vmalloc(size) (signed size)
> status: untriaged
>
> 5. line 3530
> rule: semgrep signed-int-as-size-param-kmalloc
> match: rx_ring->rx_buffer_info = vmalloc(size) (signed size)
> status: untriaged
I didn't look closely, but: I am a little skeptical that these signed size
problems are worth fixing; while the other items on your list look worth
fixing to me.
...
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 1/4] ice: fix timestamp interrupt configuration for E825C
From: Mekala, SunithaX D @ 2026-04-16 17:23 UTC (permalink / raw)
To: Keller, Jacob E, Nguyen, Anthony L, Intel Wired LAN,
netdev@vger.kernel.org
Cc: Loktionov, Aleksandr, Keller, Jacob E, Miskell, Timothy
In-Reply-To: <20260408-jk-even-more-e825c-fixes-v1-1-b959da91a81f@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Jacob Keller
> Sent: Wednesday, April 8, 2026 11:47 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; netdev@vger.kernel.org
> Cc: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Miskell, Timothy <timothy.miskell@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 1/4] ice: fix timestamp interrupt configuration for E825C
>
> From: Grzegorz Nitka <grzegorz.nitka@intel.com>
>
> The E825C ice_phy_cfg_intr_eth56g() function is responsible for programming
> the PHY interrupt for a given port. This function writes to the
> PHY_REG_TS_INT_CONFIG register of the port. The register is responsible for
> configuring whether the port interrupt logic is enabled, as well as
> programming the threshold of waiting timestamps that will trigger an
> interrupt from this port.
>
> This threshold value must not be programmed to zero while the interrupt is
> enabled. Doing so puts the port in a misconfigured state where the PHY
> timestamp interrupt for the quad of connected ports will become stuck.
>
> This occurs, because a threshold of zero results in the timestamp interrupt
> status for the port becoming stuck high. The four ports in the connected
> quad have their timestamp status indicators muxed together. A new interrupt
> cannot be generated until the timestamp status indicators return low for
> all four ports.
>
> Normally, the timestamp status for a port will clear once there are fewer
> timestamps in that ports timestamp memory bank than the threshold. A
> threshold of zero makes this impossible, so the timestamp status for the
> port does not clear.
>
> The ice driver never intentionally programs the threshold to zero, indeed
> the driver always programs it to a value of 1, intending to get an
> interrupt immediately as soon as even a single packet is waiting for a
> timestamp.
>
> However, there is a subtle flaw in the programming logic in the
> ice_phy_cfg_intr_eth56g() function. Due to the way that the hardware
> handles enabling the PHY interrupt. If the threshold value is modified at
> the same time as the interrupt is enabled, the HW PHY state machine might
> enable the interrupt before the new threshold value is actually updated.
> This leaves a potential race condition caused by the hardware logic where
> a PHY timestamp interrupt might be triggered before the non-zero threshold
> is written, resulting in the PHY timestamp logic becoming stuck.
>
> Once the PHY timestamp status is stuck high, it will remain stuck even
> after attempting to reprogram the PHY block by changing its threshold or
> disabling the interrupt. Even a typical PF or CORE reset will not reset the
> particular block of the PHY that becomes stuck. Even a warm power cycle is
> not guaranteed to cause the PHY block to reset, and a cold power cycle is
> required.
>
> Prevent this by always writing the PHY_REG_TS_INT_CONFIG in two stages.
> First write the threshold value with the interrupt disabled, and only write
> the enable bit after the threshold has been programmed. When disabling the
> interrupt, leave the threshold unchanged. Additionally, re-read the
> register after writing it to guarantee that the write to the PHY has been
> flushed upon exit of the function.
>
> While we're modifying this function implementation, explicitly reject
> programming a threshold of 0 when enabling the interrupt. No caller does
> this today, but the consequences of doing so are significant. An explicit
> rejection in the code makes this clear.
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 36 +++++++++++++++++++++++++----
> 1 file changed, 32 insertions(+), 4 deletions(-)
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 2/4] ice: perform PHY soft reset for E825C ports at initialization
From: Mekala, SunithaX D @ 2026-04-16 17:23 UTC (permalink / raw)
To: Keller, Jacob E, Nguyen, Anthony L, Intel Wired LAN,
netdev@vger.kernel.org
Cc: Loktionov, Aleksandr, Keller, Jacob E, Miskell, Timothy
In-Reply-To: <20260408-jk-even-more-e825c-fixes-v1-2-b959da91a81f@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Jacob Keller
> Sent: Wednesday, April 8, 2026 11:47 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; netdev@vger.kernel.org
> Cc: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Miskell, Timothy <timothy.miskell@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 2/4] ice: perform PHY soft reset for E825C ports at initialization
>
> From: Grzegorz Nitka <grzegorz.nitka@intel.com>
>
> In some cases the PHY timestamp block of the E825C can become stuck. This
> is known to occur if the software writes 0 to the Tx timestamp threshold,
> and with older versions of the ice driver the threshold configuration is
> buggy and can race in such that hardware briefly operates with a zero
> threshold enabled. There are no other known ways to trigger this behavior,
> but once it occurs, the hardware is not recovered by normal reset, a driver
> reload, or even a warm power cycle of the system. A cold power cycle is
> sufficient to recover hardware, but this is extremely invasive and can
> result in significant downtime on customer deployments.
>
> The PHY for each port has a timestamping block which has its own reset
> functionality accessible by programming the PHY_REG_GLOBAL register.
> Writing to the PHY_REG_GLOBAL_SOFT_RESET_BIT triggers the hardware to
> perform a complete reset of the timestamping block of the PHY. This
> includes clearing the timestamp status for the port, clearing all
> outstanding timestamps in the memory bank, and resetting the PHY timer.
>
> The new ice_ptp_phy_soft_reset_eth56g() function toggles the
> PHY_REG_GLOBAL soft reset bit with the required delays, ensuring the
> PHY is properly reinitialized without requiring a full device reset.
> The sequence clears the reset bit, asserts it, then clears it again,
> with short waits between transitions to allow hardware stabilization.
>
> Call this function in the new ice_ptp_init_phc_e825c(), implementing the
> E825C device specific variant of the ice_ptp_init_phc(). Note that if
> ice_ptp_init_phc() fails, PTP functionality may be disabled, but the driver
> will still load to allow basic functionality to continue.
>
> This causes the clock owning PF driver to perform a PHY soft reset for
> every port during initialization. This ensures the driver begins life in a
> known functional state regardless of how it was previously programmed.
>
> This ensures that we properly reconfigure the hardware after a device reset
> or when loading the driver, even if it was previously misconfigured with an
> out-of-date or modified driver.
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
> Signed-off-by: Timothy Miskell <timothy.miskell@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 4 ++
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 90 ++++++++++++++++++++++++++++-
> 2 files changed, 93 insertions(+), 1 deletion(-)
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 3/4] ice: fix ready bitmap check for non-E822 devices
From: Mekala, SunithaX D @ 2026-04-16 17:23 UTC (permalink / raw)
To: Keller, Jacob E, Nguyen, Anthony L, Intel Wired LAN,
netdev@vger.kernel.org
Cc: Loktionov, Aleksandr, Keller, Jacob E, Miskell, Timothy
In-Reply-To: <20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Jacob Keller
> Sent: Wednesday, April 8, 2026 11:47 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; netdev@vger.kernel.org
> Cc: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Miskell, Timothy <timothy.miskell@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 3/4] ice: fix ready bitmap check for non-E822 devices
>
> The E800 hardware (apart from E810) has a ready bitmap for the PHY
> indicating which timestamp slots currently have an outstanding timestamp
> waiting to be read by software.
>
> This bitmap is checked in multiple places using the
> ice_get_phy_tx_tstamp_ready():
>
> * ice_ptp_process_tx_tstamp() calls it to determine which timestamps to
> attempt reading from the PHY
> * ice_ptp_tx_tstamps_pending() calls it in a loop at the end of the
> miscellaneous IRQ to check if new timestamps came in while the interrupt
> handler was executing.
> * ice_ptp_maybe_trigger_tx_interrupt() calls it in the auxiliary work task
> to trigger a software interrupt in the event that the hardware logic
> gets stuck.
>
> For E82X devices, multiple PHYs share the same block, and the parameter
> passed to the ready bitmap is a block number associated with the given
> port. For E825-C devices, the PHYs have their own independent blocks and do
> not share, so the parameter passed needs to be the port number. For E810
> devices, the ice_get_phy_tx_tstamp_ready() always returns all 1s regardless
> of what port, since this hardware does not have a ready bitmap. Finally,
> for E830 devices, each PF has its own ready bitmap accessible via register,
> and the block parameter is unused.
>
> The first call correctly uses the Tx timestamp tracker block parameter to
> check the appropriate timestamp block. This works because the tracker is
> setup correctly for each timestamp device type.
>
> The second two callers behave incorrectly for all device types other than
> the older E822 devices. They both iterate in a loop using
> ICE_GET_QUAD_NUM() which is a macro only used by E822 devices. This logic
> is incorrect for devices other than the E822 devices.
>
> For E810 the calls would always return true, causing E810 devices to always
> attempt to trigger a software interrupt even when they have no reason to.
> For E830, this results in duplicate work as the ready bitmap is checked
> once per number of quads. Finally, for E825-C, this results in the pending
> checks failing to detect timestamps on ports other than the first two.
>
> Fix this by introducing a new hardware API function to ice_ptp_hw.c,
> ice_check_phy_tx_tstamp_ready(). This function will check if any timestamps
> are available and returns a positive value if any timestamps are pending.
> For E810, the function always returns false, so that the re-trigger checks
> never happen. For E830, check the ready bitmap just once. For E82x
> hardware, check each quad. Finally, for E825-C, check every port.
>
> The interface function returns an integer to enable reporting of error code
> if the driver is unable read the ready bitmap. This enables callers to
> handle this case properly. The previous implementation assumed that
> timestamps are available if they failed to read the bitmap. This is
> problematic as it could lead to continuous software IRQ triggering if the
> PHY timestamp registers somehow become inaccessible.
>
> This change is especially important for E825-C devices, as the missing
> checks could leave a window open where a new timestamp could arrive while
> the existing timestamps aren't completed. As a result, the hardware
> threshold logic would not trigger a new interrupt. Without the check, the
> timestamp is left unhandled, and new timestamps will not cause an interrupt
> again until the timestamp is handled. Since both the interrupt check and
> the backup check in the auxiliary task do not function properly, the device
> may have Tx timestamps permanently stuck failing on a given port.
>
> The faulty checks originate from commit d938a8cca88a ("ice: Auxbus devices
> & driver for E822 TS") and commit 712e876371f8 ("ice: periodically kick Tx
> timestamp interrupt"), however at the time of the original coding, both
> functions only operated on E822 hardware. This is no longer the case, and
> hasn't been since the introduction of the ETH56G PHY model in commit
> 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 +
> drivers/net/ethernet/intel/ice/ice_ptp.c | 40 ++++------
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 117 ++++++++++++++++++++++++++++
> 3 files changed, 132 insertions(+), 26 deletions(-)
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 4/4] ice: fix ice_ptp_read_tx_hwtstamp_status_eth56g
From: Mekala, SunithaX D @ 2026-04-16 17:24 UTC (permalink / raw)
To: Keller, Jacob E, Nguyen, Anthony L, Intel Wired LAN,
netdev@vger.kernel.org
Cc: Loktionov, Aleksandr, Keller, Jacob E, Miskell, Timothy
In-Reply-To: <20260408-jk-even-more-e825c-fixes-v1-4-b959da91a81f@intel.com>
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Jacob Keller
> Sent: Wednesday, April 8, 2026 11:47 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; netdev@vger.kernel.org
> Cc: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Miskell, Timothy <timothy.miskell@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 4/4] ice: fix ice_ptp_read_tx_hwtstamp_status_eth56g
>
> The ice_ptp_read_tx_hwtstamp_status_eth56g function calls
> ice_read_phy_eth56g with a PHY index. However the function actually expects
> a port index. This causes the function to read the wrong PHY_PTP_INT_STATUS
> registers, and effectively makes the status wrong for the second set of
> ports from 4 to 7.
>
> The ice_read_phy_eth56g function uses the provided port index to determine
> which PHY device to read. We could refactor the entire chain to take a PHY
> index, but this would impact many code sites. Instead, multiply the PHY
> index by the number of ports, so that we read from the first port of each
> PHY.
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH net v3] net/sched: taprio: fix NULL pointer dereference in class dump
From: Weiming Shi @ 2026-04-16 17:24 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Vinicius Costa Gomes, Jiri Pirko, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, Xiang Mei
In-Reply-To: <CAM0EoMnhH+7NA6A-mg3rvQJLwN0Wvhd6tYeOYa_YMMdYkMPZHQ@mail.gmail.com>
On 26-04-16 11:50, Jamal Hadi Salim wrote:
> On Tue, Apr 14, 2026 at 6:43 AM Weiming Shi <bestswngs@gmail.com> wrote:
> >
> > When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
> > is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
> > Subsequent RTM_GETTCLASS dump operations walk all classes via
> > taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
> > returning the NULL pointer, then dereferences it to read child->handle,
> > causing a kernel NULL pointer dereference.
> >
> > The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
> > with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
> > namespaces enabled, an unprivileged local user can trigger a kernel
> > panic by creating a taprio qdisc inside a new network namespace,
> > grafting an explicit child qdisc, deleting it, and requesting a class
> > dump. The RTM_GETTCLASS dump itself requires no capability.
> >
>
> While i would say this looks good to me, I hate to sound like a broken
> record but:
>
> Do you have a reproducer?
> And it would be nice to get a tdc test from you.
>
> Also, please use assisted-by: or even suggested-by if this patch was
> suggested by AI.
>
> cheers,
> jamal
Hi Jamal,
Thanks for the review. Reproducer below -- tested on a KASAN kernel
under vng:
```
unshare -Urn
ip link add veth0 numtxqueues 8 numrxqueues 8 type veth \
peer name veth1 numtxqueues 8 numrxqueues 8
ip link set veth0 up
tc qdisc replace dev veth0 root handle 100: taprio \
num_tc 8 map 0 1 2 3 4 5 6 7 \
queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
base-time 0 sched-entry S ff 20000000 clockid CLOCK_TAI
tc qdisc add dev veth0 parent 100:1 handle 200: pfifo
tc qdisc del dev veth0 parent 100:1 handle 200:
tc class show dev veth0
```
A C PoC is also available if needed.
I'll test and send a v4 with the tdc test case and an Assisted-by tag.
Thanks,
Weiming Shi
>
>
> > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
> > KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> > RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2475)
> > Call Trace:
> > <TASK>
> > tc_fill_tclass (net/sched/sch_api.c:1966)
> > qdisc_class_dump (net/sched/sch_api.c:2329)
> > taprio_walk (net/sched/sch_taprio.c:2510)
> > tc_dump_tclass_qdisc (net/sched/sch_api.c:2353)
> > tc_dump_tclass_root (net/sched/sch_api.c:2370)
> > tc_dump_tclass (net/sched/sch_api.c:2431)
> > rtnl_dumpit (net/core/rtnetlink.c:6827)
> > netlink_dump (net/netlink/af_netlink.c:2325)
> > rtnetlink_rcv_msg (net/core/rtnetlink.c:6927)
> > netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> > </TASK>
> >
> > Fix this by substituting &noop_qdisc when new is NULL in
> > taprio_graft(), following the same pattern used by multiq_graft() and
> > prio_graft(). This ensures q->qdiscs[] slots are never NULL, making
> > control-plane dump paths safe without requiring individual NULL checks.
> >
> > Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq)
> > previously had explicit NULL guards that would drop/skip the packet
> > cleanly, update those checks to test for &noop_qdisc instead. Without
> > this, packets would reach taprio_enqueue_one() which increments the root
> > qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc
> > drops the packet but those counters are never rolled back, permanently
> > inflating the root qdisc's statistics.
> >
> > Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]")
> > Reported-by: Xiang Mei <xmei5@asu.edu>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> > ---
> > v3: fix broken patch
> > v2: Also update NULL guards in taprio_enqueue() and
> > taprio_dequeue_from_txq() to avoid qlen/backlog inflation (Paolo).
> > ---
> > net/sched/sch_taprio.c | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> > index f721c03514f60..07723b156c5b3 100644
> > --- a/net/sched/sch_taprio.c
> > +++ b/net/sched/sch_taprio.c
> > @@ -634,7 +634,7 @@ static int taprio_enqueue(struct sk_buff *skb, struct Qdisc *sch,
> > queue = skb_get_queue_mapping(skb);
> >
> > child = q->qdiscs[queue];
> > - if (unlikely(!child))
> > + if (unlikely(child == &noop_qdisc))
> > return qdisc_drop(skb, sch, to_free);
> >
> > if (taprio_skb_exceeds_queue_max_sdu(sch, skb)) {
> > @@ -717,7 +717,7 @@ static struct sk_buff *taprio_dequeue_from_txq(struct Qdisc *sch, int txq,
> > int len;
> > u8 tc;
> >
> > - if (unlikely(!child))
> > + if (unlikely(child == &noop_qdisc))
> > return NULL;
> >
> > if (TXTIME_ASSIST_IS_ENABLED(q->flags))
> > @@ -2183,6 +2183,9 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> > if (!dev_queue)
> > return -EINVAL;
> >
> > + if (!new)
> > + new = &noop_qdisc;
> > +
> > if (dev->flags & IFF_UP)
> > dev_deactivate(dev);
> >
> > @@ -2196,14 +2199,14 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> > *old = q->qdiscs[cl - 1];
> > if (FULL_OFFLOAD_IS_ENABLED(q->flags)) {
> > WARN_ON_ONCE(dev_graft_qdisc(dev_queue, new) != *old);
> > - if (new)
> > + if (new != &noop_qdisc)
> > qdisc_refcount_inc(new);
> > if (*old)
> > qdisc_put(*old);
> > }
> >
> > q->qdiscs[cl - 1] = new;
> > - if (new)
> > + if (new != &noop_qdisc)
> > new->flags |= TCQ_F_ONETXQUEUE | TCQ_F_NOPARENT;
> >
> > if (dev->flags & IFF_UP)
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH bpf v2 1/2] bpf: Reject TCP_NODELAY in TCP header option callbacks
From: Martin KaFai Lau @ 2026-04-16 17:35 UTC (permalink / raw)
To: KaFai Wan
Cc: daniel, john.fastabend, sdf, ast, andrii, eddyz87, memxor, song,
yonghong.song, jolsa, davem, edumazet, kuba, pabeni, horms, shuah,
jiayuan.chen, bpf, netdev, linux-kernel, linux-kselftest,
Quan Sun, Yinhao Hu, Kaiyan Mei
In-Reply-To: <20260416112308.1820332-2-kafai.wan@linux.dev>
On Thu, Apr 16, 2026 at 07:23:07PM +0800, KaFai Wan wrote:
> diff --git a/net/core/filter.c b/net/core/filter.c
> index fcfcb72663ca..911ff04bca5a 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5833,6 +5833,11 @@ BPF_CALL_5(bpf_sock_ops_setsockopt, struct bpf_sock_ops_kern *, bpf_sock,
> if (!is_locked_tcp_sock_ops(bpf_sock))
> return -EOPNOTSUPP;
>
> + if ((bpf_sock->op == BPF_SOCK_OPS_HDR_OPT_LEN_CB ||
> + bpf_sock->op == BPF_SOCK_OPS_WRITE_HDR_OPT_CB) &&
> + IS_ENABLED(CONFIG_INET) && level == SOL_TCP && optname == TCP_NODELAY)
IS_ENABLED(CONFIG_INET) is unnecessary.
pw-bot: cr
> + return -EOPNOTSUPP;
> +
> return _bpf_setsockopt(bpf_sock->sk, level, optname, optval, optlen);
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net 1/1] mptcp: hold subflow request owners when cloning reqsk
From: Matthieu Baerts @ 2026-04-16 17:45 UTC (permalink / raw)
To: Ren Wei, netdev, mptcp
Cc: davem, edumazet, kuba, pabeni, horms, ncardwell, kuniyu, dsahern,
martineau, geliang, daniel, kafai, yuantan098, yifanwucs,
tomapufckgml, bird, caoruide123, enjou1224z
In-Reply-To: <86e2514b533bf4d55d4aa2fdbf1404022e8c9430.1776149210.git.caoruide123@gmail.com>
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.
Thank you for this patch!
Indeed, it looks like this path has not been covered by the MPTCP test
suite so far.
By chance, do you have any simpler reproducer using packetdrill? (the
MPTCP fork)
https://github.com/multipath-tcp/packetdrill
Also, I see Sashiko is pointing to a potential issue with MP_CAPABLE and
the token, also only visible with net.ipv4.tcp_migrate_req=1:
https://sashiko.dev/#/patchset/86e2514b533bf4d55d4aa2fdbf1404022e8c9430.1776149210.git.caoruide123%40gmail.com
Are you also looking at that?
> Fixes: c905dee62232 ("tcp: Migrate TCP_NEW_SYN_RECV requests at retransmitting SYN+ACKs.")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Signed-off-by: Ruide Cao <caoruide123@gmail.com>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> include/net/request_sock.h | 2 ++
> net/ipv4/inet_connection_sock.c | 3 +++
> net/mptcp/subflow.c | 13 +++++++++++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/include/net/request_sock.h b/include/net/request_sock.h
> index 5a9c826a7092..560e464c400f 100644
> --- a/include/net/request_sock.h
> +++ b/include/net/request_sock.h
> @@ -36,6 +36,8 @@ struct request_sock_ops {
> struct sk_buff *skb,
> enum sk_rst_reason reason);
> void (*destructor)(struct request_sock *req);
> + void (*init_clone)(const struct request_sock *req,
> + struct request_sock *new_req);
@TCP/INET maintainers: are you OK with this new function pointer?
Currently, MPTCP is the only user, and "req" is not used, see below.
> };
>
> struct saved_syn {
> 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);
> +
> return nreq;
> }
>
> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
> index 4ff5863aa9fd..5f4069647822 100644
> --- a/net/mptcp/subflow.c
> +++ b/net/mptcp/subflow.c
> @@ -47,6 +47,17 @@ static void subflow_req_destructor(struct request_sock *req)
> mptcp_token_destroy_request(req);
> }
>
> +static void subflow_req_clone(const struct request_sock *req,
> + struct request_sock *new_req)
> +{
> + struct mptcp_subflow_request_sock *subflow_req = mptcp_subflow_rsk(new_req);
> +
> + (void)req;
Note: if 'req' is not used, and MPTCP is currently the only user of this
new init_clone() callback, perhaps enough to pass only 'new_req' for the
moment? 'req' can be added later if other users need it, no?
With only init_close(nreq) in a v2, or if TCP maintainers prefer to keep
it, feel free to add:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net v6 1/2] dpll: export __dpll_pin_change_ntf() for use under dpll_lock
From: Vadim Fedorenko @ 2026-04-16 17:50 UTC (permalink / raw)
To: Petr Oros, netdev
Cc: Ivan Vecera, Arkadiusz Kubalewski, Jiri Pirko, Tony Nguyen,
Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-kernel,
intel-wired-lan, Aleksandr Loktionov, Rinitha S, Michal Schmidt,
Jacob Keller
In-Reply-To: <20260416113952.389405-2-poros@redhat.com>
On 16/04/2026 12:39, Petr Oros wrote:
> From: Ivan Vecera <ivecera@redhat.com>
>
> Export __dpll_pin_change_ntf() so that drivers can send pin change
> notifications from within pin callbacks, which are already called
> under dpll_lock. Using dpll_pin_change_ntf() in that context would
> deadlock.
>
> Add lockdep_assert_held() to catch misuse without the lock held.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> Signed-off-by: Petr Oros <poros@redhat.com>
Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
^ permalink raw reply
* Re: [PATCH v2 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
From: Stephen Hemminger @ 2026-04-16 17:55 UTC (permalink / raw)
To: chia-yu.chang
Cc: victor, hxzene, linux-hardening, kees, gustavoars, jhs, jiri,
davem, edumazet, kuba, pabeni, linux-kernel, netdev, horms, ij,
ncardwell, koen.de_schepper, g.white, ingemar.s.johansson,
mirja.kuehlewind, cheshire, rs.ietf, Jason_Livingood, vidhi_goel
In-Reply-To: <20260416170906.66432-1-chia-yu.chang@nokia-bell-labs.com>
On Thu, 16 Apr 2026 19:09:06 +0200
chia-yu.chang@nokia-bell-labs.com wrote:
> From: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
>
> Fix dualpi2_change() to correctly enforce updated limit and memlimit values
> after a configuration change of the dualpi2 qdisc.
>
> Before this patch, dualpi2_change() always attempted to dequeue packets via
> the root qdisc (C-queue) when reducing backlog or memory usage, and
> unconditionally assumed that a valid skb will be returned. When traffic
> classification results in packets being queued in the L-queue while the
> C-queue is empty, this leads to a NULL skb dereference during limit or
> memlimit enforcement.
>
> This is fixed by first dequeuing from the C-queue path if it is non-empty.
> Once the C-queue is empty, packets are dequeued directly from the L-queue.
> Return values from qdisc_dequeue_internal() are checked for both queues. When
> dequeuing from the L-queue, the parent qdisc qlen and backlog counters are
> updated explicitly to keep overall qdisc statistics consistent.
>
> Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc")
> Reported-by: "Kito Xu (veritas501)" <hxzene@gmail.com>
> Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
> ---
I was a little concerned about the complexity of managing qlen here.
But could not find anything obvious.
Turned to AI review and it found some things:
Right fix direction and the reported crash is real. A few issues before this is ready:
1. The `c_len` construction is fragile. Declared `int`, initialized
from a `u32 - u32`. If the invariant `qdisc_qlen(sch) >=
qdisc_qlen(q->l_queue)` is ever violated, you get a large positive
value, the C-queue branch is taken on an empty C-queue,
`qdisc_dequeue_internal()` returns NULL, and the loop breaks out
without draining the L-queue -- leaving the qdisc over limit. Simpler
and more robust to just compare the two qlens directly and drop the
delta variable entirely.
2. Missing else/termination. If both branches' conditions are false
(neither `c_len` nor `qdisc_qlen(q->l_queue)`) but the outer `while`
still holds because `memory_used > memory_limit`, the loop spins
forever. An explicit `else break;` guards against an accounting desync
becoming a hang.
3. Whitespace: two lines in the L-queue branch use spaces instead of tabs --
+ q->memory_used -= skb->truesize;
+ rtnl_qdisc_drop(skb, q->l_queue);
checkpatch will flag this.
4. Comment style. The three-line comment at the end of the L-queue
branch doesn't follow the net subsystem multi-line comment style
(leading ' * ' on continuation lines, closing ' */' on its own line).
Once the code is cleaner, the comment could also just be dropped or
shortened to one line.
5. The accounting in the L-queue branch is correct, but only if you
trace the enqueue invariants carefully: L-queue packets are counted in
*both* `sch` and `q->l_queue` on enqueue (see dualpi2_enqueue_skb lines
413-423), `qdisc_dequeue_internal(q->l_queue, true)` adjusts l_queue's
side, and the explicit `--sch->q.qlen` + `qdisc_qstats_backlog_dec(sch,
skb)` adjusts sch's side. Separately, the C-queue branch now quietly
relies on the post-CVE-2025-39677 semantics of
`qdisc_dequeue_internal()` handling parent backlog -- which is why the
pre-patch `qdisc_qstats_backlog_dec(sch, skb)` could be removed.
Neither of these load-bearing invariants is documented in the code or
the commit message. Please add an inline comment in the L-queue branch
explaining the double-count-on-enqueue, and mention the
qdisc_dequeue_internal() dependency in the commit log.
6. Commit message / subject. Subject reads as if only the L-queue path
changed, but the whole drain loop was restructured. Something like
"sch_dualpi2: drain both C-queue and L-queue in dualpi2_change()" would
describe it better. Also, on NULL return from qdisc_dequeue_internal()
the loop silently breaks -- if that ever triggers it means qdisc_qlen()
> 0 but dequeue returned NULL, which is a real invariant violation.
> Worth a WARN_ON_ONCE().
Suggested shape:
while (qdisc_qlen(sch) > sch->limit ||
q->memory_used > q->memory_limit) {
struct sk_buff *skb;
if (qdisc_qlen(sch) > qdisc_qlen(q->l_queue)) {
skb = qdisc_dequeue_internal(sch, true);
if (!skb)
break;
q->memory_used -= skb->truesize;
rtnl_qdisc_drop(skb, sch);
} else if (qdisc_qlen(q->l_queue)) {
skb = qdisc_dequeue_internal(q->l_queue, true);
if (!skb)
break;
/* L-queue packets are counted in both sch and
* l_queue on enqueue; qdisc_dequeue_internal()
* handled l_queue, account sch here.
*/
sch->q.qlen--;
qdisc_qstats_backlog_dec(sch, skb);
q->memory_used -= skb->truesize;
rtnl_qdisc_drop(skb, q->l_queue);
qdisc_qstats_drop(sch);
} else {
break;
}
}
As with any AI feedback, expect it to generate hints but also be wrong.
^ permalink raw reply
* Re: [PATCH net] ipv6: fix possible UAF in icmpv6_rcv()
From: Joe Damato @ 2026-04-16 18:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Ido Schimmel, netdev, eric.dumazet
In-Reply-To: <20260416103505.2380753-1-edumazet@google.com>
On Thu, Apr 16, 2026 at 10:35:05AM +0000, Eric Dumazet wrote:
> Caching saddr and daddr before pskb_pull() is problematic
> since skb->head can change.
>
> Remove these temporary variables:
>
> - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr
> when net_dbg_ratelimited() is called in the slow path.
>
> - Avoid potential future misuse after pskb_pull() call.
>
> Fixes: 4b3418fba0fe ("ipv6: icmp: include addresses in debug messages")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv6/icmp.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
Reviewed-by: Joe Damato <joe@dama.to>
^ 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