* [PATCH v6.1 0/3] Fix CVE-2026-23272
From: Shivani Agarwal @ 2026-06-19 9:28 UTC (permalink / raw)
To: stable, gregkh
Cc: pablo, fw, phil, davem, edumazet, kuba, pabeni, horms,
netfilter-devel, coreteam, netdev, linux-kernel, ajay.kaher,
alexey.makhalov, vamsi-krishna.brahmajosyula, yin.ding,
tapas.kundu, Shivani Agarwal
To fix CVE-2026-23272, commit def602e498a4 is required; however,
it depends on commit d4b7f29eb85c and 8d738c1869f6. Therefore,
both patches have been backported to v6.1.
Florian Westphal (1):
netfilter: nf_tables: always increment set element count
Pablo Neira Ayuso (2):
netfilter: nf_tables: fix set size with rbtree backend
netfilter: nf_tables: unconditionally bump set->nelems before
insertion
include/net/netfilter/nf_tables.h | 6 +++
net/netfilter/nf_tables_api.c | 72 ++++++++++++++++++++++++++-----
net/netfilter/nft_set_rbtree.c | 43 ++++++++++++++++++
3 files changed, 110 insertions(+), 11 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH net] netpoll: run NAPI poll in softirq context to avoid rq->lock self-deadlock
From: Petr Mladek @ 2026-06-19 9:53 UTC (permalink / raw)
To: John Ogness
Cc: Breno Leitao, Peter Zijlstra, Jakub Kicinski,
Sebastian Andrzej Siewior, Sergey Senozhatsky, Vlad Poenaru,
Thomas Gleixner, netdev, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Clark Williams, Steven Rostedt,
linux-rt-devel, linux-kernel, stable, Frederic Weisbecker,
Ingo Molnar, Vincent Guittot, Dietmar Eggemann, K Prateek Nayak
In-Reply-To: <87tsr1m6y5.fsf@jogness.linutronix.de>
On Wed 2026-06-17 19:13:30, John Ogness wrote:
> On 2026-06-17, Breno Leitao <leitao@debian.org> wrote:
> > On Wed, Jun 17, 2026 at 01:19:58PM +0200, Peter Zijlstra wrote:
> >> But anything using locking is not ->write_atomic() and should be driven
> >> from a kthread, no?
> >
> > Good point. If that's the case, netconsole might not ever be able to drop
> > CON_NBCON_ATOMIC_UNSAFE for any network-based console driver at all.
>
> It depends on what it needs to synchronize against. For example, the
> UART consoles cannot write if the port lock is taken by another
> context. And the port lock is the sole lock for writing to the UART. To
> deal with this, we added wrappers [0] for acquiring/releasing the port
> lock. The wrappers acquire the nbcon hardware after taking the port
> lock.
>
> The write_atomic() implementations for UART consoles do not take the
> port lock. Only the nbcon hardware is acquired (which can be done from
> any context). This automatically provides the synchronization based on
> the port lock.
>
> > As far as I can tell, there isn't a network driver today whose transmit
> > path is completely lockless, so, even if we make netpoll lockless.
> >
> > It's unlikely any NIC will ever achieve this, given that NIC TX
> > fundamentally relies on a shared DMA ring and doorbell register, which
> > inherently cannot be made lockless.
> >
> > So, is it correct to state that CON_NBCON_ATOMIC_UNSAFE will be part of
> > netconsole forever-ish?
>
> Is there some lock that can be taken to synchronize all writing of
> packets to the network? If yes, the netconsole can use a similar
> solution.
We need to be careful here. If more locks depend on the nbcon
ownership than it might become a kind of big kernel lock.
It might suffer from lock contention.
Another complication is that it is supposed to be a tail lock.
Finally, it might create tricky lockdep dependencies. But nbcon
context locking is not tracked by locked so it is not easy to be sure.
More details:
I always forget the details. But it seems that sleeping is allowed
in the nbcon context, see cant_migrate() in nbcon_device_try_acquire().
Which might break when someone tries to take it in atomic context.
AFAIK, the motivation was to allow using the normal (sleeping)
spin locks for serial console synchronization in RT. The nested nbcon
context locking should not disable the preemption when called
in NBCON_PRIO_NORMAL context.
It would still allow to take the nbcon context in atomic context
when called in NBCON_PRIO_EMERGENCY or _PANIC context because
nbcon_context_try_acquire() is able to take over the ownership
even from a sleeping NBCON_PRIO_NORMAL context.
But we need to make sure that outer locks behave the same.
In practice, they must be normal spin_locks. We could probably
add some lockdep annotation to catch eventual problems.
Sigh, I hope that I have got it right. I seem to be a bit lost
this week.
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/serial_core.h?h=v7.1#n715
Best Regards,
Petr
^ permalink raw reply
* Re: AW: AW: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
From: Nicolai Buchwitz @ 2026-06-19 9:53 UTC (permalink / raw)
To: Sven Schuchmann
Cc: Thangaraj Samynathan, Rengarajan Sundararajan, UNGLinuxDriver,
Woojung.Huh, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-usb, linux-kernel
In-Reply-To: <BEZP281MB2245422BB9FBFF4AFE081451D9E22@BEZP281MB2245.DEUP281.PROD.OUTLOOK.COM>
Hi Sven
On 19.6.2026 11:18, Sven Schuchmann wrote:
> Hello Nicolai,
>
> my first opservation is that calling lan78xx_write_vlan_table()
> at the end lan78xx_start_rx_path() fixes the problem. I was able
> to do over 200 connect/disconnects without any problem.
Thanks, that's the right direction. For the final patch I'd move it
to lan78xx_mac_link_up(), which is IMHO a bit "cleaner":
[...]
static void lan78xx_rx_urb_submit_all(struct lan78xx_net *dev);
+static int lan78xx_write_vlan_table(struct lan78xx_net *dev);
[...]
static void lan78xx_mac_link_up(struct phylink_config *config,
[...]
if (ret < 0)
goto link_up_fail;
+ ret = lan78xx_write_vlan_table(dev);
+ if (ret < 0)
+ goto link_up_fail;
+
netif_start_queue(net);
[...]
Could you give this version a quick test and confirm? Then I'll add
your Tested-by.
> [...]
Thanks
Nicolai
^ permalink raw reply
* [PATCH net v2] octeontx2-af: npc: cn20k: Fix subbank free list indexing for search order
From: Ratheesh Kannoth @ 2026-06-19 9:51 UTC (permalink / raw)
To: kuba, linux-kernel, netdev, rkannoth
Cc: andrew+netdev, davem, edumazet, pabeni, sgoutham
subbank_srch_order[i] is the physical subbank at search-order slot i,
so each subbank's arr_idx must be i (its slot), not
subbank_srch_order[sb->idx]. The old logic mis-keyed xa_sb_free
and broke allocation traversal order.
Populate arr_idx and xa_sb_free in a single pass over the search
order after subbank structs are initialized.
Fixes: 7ac9d4c4075c ("octeontx2-af: npc: cn20k: add subbank search order control")
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
---
v1 -> v2: Addressed simon comments
https://lore.kernel.org/netdev/20260619091341.918165-1-horms@kernel.org/
---
.../ethernet/marvell/octeontx2/af/cn20k/npc.c | 51 ++++++++++++++-----
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
index 354c4e881c6a..51fe82f1343f 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
@@ -3423,6 +3423,36 @@ static int npc_create_srch_order(int cnt)
return 0;
}
+static int npc_subbanks_srch_order_init(struct rvu *rvu)
+{
+ struct npc_subbank *sb;
+ int sb_idx;
+ int i, j;
+ int rc;
+
+ for (i = 0; i < npc_priv->num_subbanks; i++) {
+ sb_idx = subbank_srch_order[i];
+ sb = &npc_priv->sb[sb_idx];
+ sb->arr_idx = i;
+
+ dev_dbg(rvu->dev, "%s: sb->idx=%u sb->arr_idx=%u\n",
+ __func__, sb->idx, sb->arr_idx);
+
+ rc = xa_err(xa_store(&npc_priv->xa_sb_free, sb->arr_idx,
+ xa_mk_value(sb->idx), GFP_KERNEL));
+ if (rc) {
+ dev_err(rvu->dev,
+ "%s: xa_store(xa_sb_free) failed at slot %d (sb=%d): %d\n",
+ __func__, i, sb_idx, rc);
+ for (j = 0; j < i; j++)
+ xa_erase(&npc_priv->xa_sb_free, j);
+ return rc;
+ }
+ }
+
+ return 0;
+}
+
static void npc_subbank_init(struct rvu *rvu, struct npc_subbank *sb, int idx)
{
mutex_init(&sb->lock);
@@ -3435,16 +3465,6 @@ static void npc_subbank_init(struct rvu *rvu, struct npc_subbank *sb, int idx)
sb->flags = NPC_SUBBANK_FLAG_FREE;
sb->idx = idx;
- sb->arr_idx = subbank_srch_order[idx];
-
- dev_dbg(rvu->dev, "%s: sb->idx=%u sb->arr_idx=%u\n",
- __func__, sb->idx, sb->arr_idx);
-
- /* Keep first and last subbank at end of free array; so that
- * it will be used at last
- */
- xa_store(&npc_priv->xa_sb_free, sb->arr_idx,
- xa_mk_value(sb->idx), GFP_KERNEL);
}
static int npc_pcifunc_map_create(struct rvu *rvu)
@@ -4635,6 +4655,7 @@ static int npc_priv_init(struct rvu *rvu)
int num_subbanks, subbank_depth;
u64 npc_const1, npc_const2 = 0;
struct npc_subbank *sb;
+ int ret = -ENOMEM;
u64 cfg;
int i;
@@ -4727,13 +4748,19 @@ static int npc_priv_init(struct rvu *rvu)
for (i = 0, sb = npc_priv->sb; i < num_subbanks; i++, sb++)
npc_subbank_init(rvu, sb, i);
+ ret = npc_subbanks_srch_order_init(rvu);
+ if (ret)
+ goto fail3;
+
/* Get number of pcifuncs in the system */
npc_priv->pf_cnt = npc_pcifunc_map_create(rvu);
npc_priv->xa_pf2idx_map = kcalloc(npc_priv->pf_cnt,
sizeof(struct xarray),
GFP_KERNEL);
- if (!npc_priv->xa_pf2idx_map)
+ if (!npc_priv->xa_pf2idx_map) {
+ ret = -ENOMEM;
goto fail3;
+ }
for (i = 0; i < npc_priv->pf_cnt; i++)
xa_init_flags(&npc_priv->xa_pf2idx_map[i], XA_FLAGS_ALLOC);
@@ -4760,7 +4787,7 @@ static int npc_priv_init(struct rvu *rvu)
fail1:
kfree(npc_priv);
npc_priv = NULL;
- return -ENOMEM;
+ return ret;
}
void npc_cn20k_deinit(struct rvu *rvu)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] octeontx2-af: npc: cn20k: Fix subbank free list indexing for search order
From: Ratheesh Kannoth @ 2026-06-19 9:45 UTC (permalink / raw)
To: Simon Horman
Cc: kuba, linux-kernel, netdev, andrew+netdev, davem, edumazet,
pabeni, sgoutham
In-Reply-To: <20260619091341.918165-1-horms@kernel.org>
On 2026-06-19 at 14:43:41, Simon Horman (horms@kernel.org) wrote:
> 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://netdev-ai.bots.linux.dev/sashiko/
> ---
> octeontx2-af: npc: cn20k: Fix subbank free list indexing for search order
>
> This change re-keys the xa_sb_free free list using each subbank's slot
> in subbank_srch_order[] rather than using subbank_srch_order[sb->idx],
> moving the population into a new helper called from npc_priv_init().
> A few comments inline.
>
> > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> > index 354c4e881c6a..d38e848add93 100644
> > --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> > +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> > @@ -3423,6 +3423,36 @@ static int npc_create_srch_order(int cnt)
> > return 0;
> > }
> >
> > +static int npc_subbanks_srch_oder_init(struct rvu *rvu)
> ^^^^
>
> [Low]
> Is "oder" intended here? The neighbouring identifiers
> npc_create_srch_order() and subbank_srch_order use "order", so this
> appears to be a typo that would be easier to fix before the symbol
> lands.
>
> > +{
> > + struct npc_subbank *sb;
> > + int sb_idx;
> > + int i, j;
> > + int rc;
> > +
> > + for (i = 0; i < npc_priv->num_subbanks; i++) {
> > + sb_idx = subbank_srch_order[i];
> > + sb = &npc_priv->sb[sb_idx];
> > + sb->arr_idx = i;
> > +
> > + dev_dbg(rvu->dev, "%s: sb->idx=%u sb->arr_idx=%u\n",
> > + __func__, sb->idx, sb->arr_idx);
> > +
> > + rc = xa_err(xa_store(&npc_priv->xa_sb_free, sb->arr_idx,
> > + xa_mk_value(sb->idx), GFP_KERNEL));
> > + if (rc) {
> > + dev_err(rvu->dev,
> > + "%s: xa_store(xa_sb_free) failed at slot %d (sb=%d): %d\n",
> > + __func__, i, sb_idx, rc);
> > + for (j = 0; j < i; j++)
> > + xa_erase(&npc_priv->xa_sb_free, j);
> > + return rc;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> [ ... ]
>
> > @@ -4727,6 +4748,10 @@ static int npc_priv_init(struct rvu *rvu)
> > for (i = 0, sb = npc_priv->sb; i < num_subbanks; i++, sb++)
> > npc_subbank_init(rvu, sb, i);
> >
> > + ret = npc_subbanks_srch_oder_init(rvu);
> > + if (ret)
> > + goto fail2;
> > +
>
> [Medium]
> Can this leak subbank_srch_order on the new failure path?
>
> npc_create_srch_order() allocates subbank_srch_order via kcalloc().
> Before this patch, the only way to reach fail2 was when
> npc_create_srch_order() itself failed and left subbank_srch_order
> NULL, so fail2 not freeing it was safe.
>
> With this new goto fail2, subbank_srch_order has already been
> allocated, but the fail2 label only frees npc_priv->sb and npc_priv:
>
> fail2:
> xa_destroy(&npc_priv->xa_sb_used);
> [...]
> kfree(npc_priv->sb);
> npc_priv->sb = NULL;
> fail1:
> kfree(npc_priv);
> npc_priv = NULL;
> return ret;
>
> A subsequent re-init would unconditionally reassign
> subbank_srch_order = kcalloc(...) in npc_create_srch_order(),
> permanently leaking the previous buffer.
>
> Should this path go to a new label that also kfree()s
> subbank_srch_order, or should fail2 free it?
>
> > /* Get number of pcifuncs in the system */
> > npc_priv->pf_cnt = npc_pcifunc_map_create(rvu);
> > npc_priv->xa_pf2idx_map = kcalloc(npc_priv->pf_cnt,
>
> [High]
> Can npc_priv_init() return 0 on a real failure here?
>
> After npc_subbanks_srch_oder_init() returns successfully, ret is 0.
> If the kcalloc() for npc_priv->xa_pf2idx_map fails right after, the
> code does goto fail3 which falls through fail2 and fail1 to
> return ret, propagating 0 to the caller:
>
> fail3:
> kfree(subbank_srch_order);
> subbank_srch_order = NULL;
>
> fail2:
> [...]
> fail1:
> kfree(npc_priv);
> npc_priv = NULL;
> return ret;
>
> The caller npc_cn20k_init() then sees err == 0 and continues into
> npc_setup_mcam_section(), which dereferences npc_priv (now NULL).
>
> Pre-patch the function ended in return -ENOMEM, so the fail3 path
> returned -ENOMEM unconditionally. Should ret be reset to -ENOMEM
> before goto fail3, or should a separate variable be used for the
> new helper's return value?
>
> > @@ -4760,7 +4785,7 @@ static int npc_priv_init(struct rvu *rvu)
> > fail1:
> > kfree(npc_priv);
> > npc_priv = NULL;
> > - return -ENOMEM;
> > + return ret;
> > }
ACK for all.
pw-bot: changes-requested
^ permalink raw reply
* Re: [PATCH net 4/6] ipv6: fix error handling in disable_policy sysctl
From: Nicolas Dichtel @ 2026-06-19 9:35 UTC (permalink / raw)
To: Fernando Fernandez Mancera, netdev
Cc: shemminger, dforster, gospo, ddutt, brian.haley, horms, pabeni,
kuba, edumazet, davem, idosch, dsahern
In-Reply-To: <20260618162225.4588-5-fmancera@suse.de>
Le 18/06/2026 à 18:22, Fernando Fernandez Mancera a écrit :
> When writing to the disable_policy sysctl, if proc_dointvec() fails to
> parse the input, it returns a negative error code. The current
> implementation is resetting the position argument even if an error
> occurred during proc_dointvec() and not only during sysctl restart.
>
> Fix this by checking the return value of proc_dointvec() and returning
> early on failure.
>
> Fixes: df789fe75206 ("ipv6: Provide ipv6 version of "disable_policy" sysctl")
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net 2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
From: Simon Horman @ 2026-06-19 9:35 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260618-airoha-qos-fixes-v1-2-37192652157f@kernel.org>
On Thu, Jun 18, 2026 at 08:00:30AM +0200, Lorenzo Bianconi wrote:
> airoha_tc_htb_alloc_leaf_queue() assigns queue IDs based on the channel
> index (opt->qid = AIROHA_NUM_TX_RING + channel), but updates
> real_num_tx_queues with a simple increment (num_tx_queues + 1). When QoS
> channels are allocated sparsely (e.g., channels 0 and 3 without 1 and
> 2), the returned qid can exceed real_num_tx_queues, causing out-of-bounds
> accesses in the networking stack.
> For example, allocating channel 0 then channel 3 results in
> real_num_tx_queues = 34 but qid = 35, which is out of range [0, 34).
> Fix this by computing real_num_tx_queues based on the highest active
> channel index rather than using a simple counter, in both the allocation
> and deletion paths.
>
> Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
...
> @@ -2806,7 +2806,10 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
> if (err)
> goto error;
>
> - err = netif_set_real_num_tx_queues(netdev, num_tx_queues + 1);
> + if (num_tx_queues <= netdev->real_num_tx_queues)
> + goto set_qos_sq_bmap;
> +
> + err = netif_set_real_num_tx_queues(netdev, num_tx_queues);
> if (err) {
> airoha_qdma_set_tx_rate_limit(netdev, channel, 0,
> opt->quantum);
> @@ -2815,6 +2818,7 @@ static int airoha_tc_htb_alloc_leaf_queue(struct net_device *netdev,
> goto error;
> }
>
> +set_qos_sq_bmap:
I would prefer if this could be achieved without a goto.
> set_bit(channel, dev->qos_sq_bmap);
> opt->qid = AIROHA_NUM_TX_RING + channel;
>
...
^ permalink raw reply
* Re: [PATCH net 3/6] ipv6: fix error handling in forwarding sysctl
From: Nicolas Dichtel @ 2026-06-19 9:34 UTC (permalink / raw)
To: Fernando Fernandez Mancera, netdev
Cc: shemminger, dforster, gospo, ddutt, brian.haley, horms, pabeni,
kuba, edumazet, davem, idosch, dsahern
In-Reply-To: <20260618162225.4588-4-fmancera@suse.de>
Le 18/06/2026 à 18:22, Fernando Fernandez Mancera a écrit :
> When writing to the forwarding sysctl, if proc_dointvec() fails to parse
> the input, it returns a negative error code. The current implementation
> is overwriting that error for write operations.
>
> This results in a silent failure, it returns a successful write although
> the configuration was not modified at all. When modifying the "all"
> variant it can also modify the configuration of existing interfaces to
> the wrong value.
>
> Fix this by checking the return value of proc_dointvec() and returning
> early on failure.
>
> Fixes: b325fddb7f86 ("ipv6: Fix sysctl unregistration deadlock")
The bug existed before the git era.
Maybe
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
^ permalink raw reply
* Re: [PATCH net 1/2] net: airoha: Fix off-by-one in airoha_tc_remove_htb_queue()
From: Simon Horman @ 2026-06-19 9:34 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wayen Yan, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260618-airoha-qos-fixes-v1-1-37192652157f@kernel.org>
On Thu, Jun 18, 2026 at 08:00:29AM +0200, Lorenzo Bianconi wrote:
> airoha_tc_htb_alloc_leaf_queue() computes the HTB QoS channel index
> as opt->classid % AIROHA_NUM_QOS_CHANNELS and stores it in qos_sq_bmap.
> However, airoha_tc_remove_htb_queue() clears the HTB configuration
> using queue + 1 as the channel index, causing an off-by-one error.
> Use queue directly as the QoS channel index to match the allocation
> logic.
>
> Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net 2/6] ipv6: fix error handling in ignore_routes_with_linkdown sysctl
From: Nicolas Dichtel @ 2026-06-19 9:34 UTC (permalink / raw)
To: Fernando Fernandez Mancera, netdev
Cc: shemminger, dforster, gospo, ddutt, brian.haley, horms, pabeni,
kuba, edumazet, davem, idosch, dsahern
In-Reply-To: <20260618162225.4588-3-fmancera@suse.de>
Le 18/06/2026 à 18:22, Fernando Fernandez Mancera a écrit :
> When writing to the ignore_routes_with_linkdown sysctl, if
> proc_dointvec() fails to parse the input, it returns a negative error
> code. The current implementation is overwriting that error for write
> operations.
>
> This results in a silent failure, it returns a successful write although
> the configuration was not modified at all. When modifying the "all"
> variant it can also modify the configuration of existing interfaces to
> the wrong value.
>
> Fix this by checking the return value of proc_dointvec() and returning
> early on failure.
>
> Fixes: 35103d11173b ("net: ipv6 sysctl option to ignore routes when nexthop link is down")
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net 1/6] ipv6: fix error handling in disable_ipv6 sysctl
From: Nicolas Dichtel @ 2026-06-19 9:33 UTC (permalink / raw)
To: Fernando Fernandez Mancera, netdev
Cc: shemminger, dforster, gospo, ddutt, brian.haley, horms, pabeni,
kuba, edumazet, davem, idosch, dsahern
In-Reply-To: <20260618162225.4588-2-fmancera@suse.de>
Le 18/06/2026 à 18:22, Fernando Fernandez Mancera a écrit :
> When writing to the disable_ipv6 sysctl, if proc_dointvec() fails to
> parse the input, it returns a negative error code. The current
> implementation is overwriting that error for write operations.
>
> This results in a silent failure, it returns a successful write although
> the configuration was not modified at all. When modifying the "all"
> variant it can also modify the configuration of existing interfaces to
> the wrong value.
>
> Fix this by checking the return value of proc_dointvec() and returning
> early on failure.
>
> Fixes: 56d417b12e57 ("IPv6: Add 'autoconf' and 'disable_ipv6' module parameters")
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* [PATCH 5.10] netdevsim: Fix memory leak of nsim_dev->fa_cookie
From: Mikhail Dmitrichenko @ 2026-06-19 9:15 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman
Cc: Mikhail Dmitrichenko, Jakub Kicinski, David S. Miller, Jiri Pirko,
Ido Schimmel, netdev, linux-kernel, Andrew Lunn, Eric Dumazet,
Paolo Abeni, Jiri Pirko, lvc-project, Wang Yufen
From: Wang Yufen <wangyufen@huawei.com>
commit 064bc7312bd09a48798418663090be0c776183db upstream.
kmemleak reports this issue:
unreferenced object 0xffff8881bac872d0 (size 8):
comm "sh", pid 58603, jiffies 4481524462 (age 68.065s)
hex dump (first 8 bytes):
04 00 00 00 de ad be ef ........
backtrace:
[<00000000c80b8577>] __kmalloc+0x49/0x150
[<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim]
[<0000000093d78e77>] full_proxy_write+0xf3/0x180
[<000000005a662c16>] vfs_write+0x1c5/0xaf0
[<000000007aabf84a>] ksys_write+0xed/0x1c0
[<000000005f1d2e47>] do_syscall_64+0x3b/0x90
[<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
The issue occurs in the following scenarios:
nsim_dev_trap_fa_cookie_write()
kmalloc() fa_cookie
nsim_dev->fa_cookie = fa_cookie
..
nsim_drv_remove()
The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To
fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().
Fixes: d3cbb907ae57 ("netdevsim: add ACL trap reporting cookie as a metadata")
Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Link: https://lore.kernel.org/r/1668504625-14698-1-git-send-email-wangyufen@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ The context change is due to the commit 5e388f3dc38c
("netdevsim: move vfconfig to nsim_dev") in v5.16
which is irrelevant to the logic of this patch. ]
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko@astralinux.ru>
---
Backport fix for CVE-2022-49803
drivers/net/netdevsim/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index c8834ea84732..a106365ce485 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -1173,6 +1173,7 @@ void nsim_dev_remove(struct nsim_bus_dev *nsim_bus_dev)
ARRAY_SIZE(nsim_devlink_params));
devlink_unregister(devlink);
devlink_resources_unregister(devlink, NULL);
+ kfree(nsim_dev->fa_cookie);
devlink_free(devlink);
}
--
2.47.3
^ permalink raw reply related
* AW: AW: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
From: Sven Schuchmann @ 2026-06-19 9:18 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Thangaraj Samynathan, Rengarajan Sundararajan,
UNGLinuxDriver@microchip.com, Woojung.Huh@microchip.com,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <6d638042ad07a8bfb09ff3ee923e7b3f@tipi-net.de>
Hello Nicolai,
my first opservation is that calling lan78xx_write_vlan_table()
at the end lan78xx_start_rx_path() fixes the problem. I was able
to do over 200 connect/disconnects without any problem.
On 19.6.2026 10:30, Nicolai Buchwitz wrote:
> [...]
>
> Can you please try with the following changes to lan78xx_mac_reset()?
>
> ret = lan78xx_stop_rx_path(dev);
> if (ret < 0)
> goto link_down_fail;
>
> - /* MAC reset seems to not affect MAC configuration, no idea if it is
> - * really needed, but it was done in previous driver version. So,
> leave
> - * it here.
> - */
> - ret = lan78xx_mac_reset(dev);
> - if (ret < 0)
> - goto link_down_fail;
> -
> return;
Actually with removing the the call to lan78xx_mac_reset()
in lan78xx_mac_link_down() problem still persists.
(Note: lan78xx_mac_reset() will never be called then!)
See over here:
[Fri Jun 19 11:06:37 2026] Connect LAN Cable
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:38 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:41 2026] Disconnect LAN Cable
[Fri Jun 19 11:06:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 11:06:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 11:06:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 11:06:41 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 11:06:42 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 11:06:42 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 11:06:42 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 11:06:42 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 11:06:43 2026] Connect LAN Cable
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:43 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:45 2026] Disconnect LAN Cable
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 11:06:46 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 11:06:47 2026] Connect LAN Cable
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:47 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:48 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:49 2026] Disconnect LAN Cable
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 11:06:50 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 11:06:52 2026] Connect LAN Cable
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:52 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:54 2026] Disconnect LAN Cable
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_down()
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop tx path
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: stop rx path
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Down
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_down()
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop tx path
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: stop rx path
[Fri Jun 19 11:06:54 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Down
[Fri Jun 19 11:06:56 2026] Connect LAN Cable
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_mac_link_up()
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: lan78xx_configure_usb()
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start tx path
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: start rx path
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: VLAN TABLE 0: 0x05 0x05 - Ok
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.2:1.0 100BASE-T1-2: Link is Up - 100Mbps/Full - flow control off
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_mac_link_up()
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_flowcontrol()
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: lan78xx_configure_usb()
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start tx path
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: start rx path
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: VLAN TABLE 0: 0x05 0x00 - ERROR
[Fri Jun 19 11:06:56 2026] lan78xx 1-1.1:1.0 100BASE-T1-1: Link is Up - 100Mbps/Full - flow control off
Best Regards,
Sven
^ permalink raw reply
* Re: [PATCH net] ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().
From: Fernando Fernandez Mancera @ 2026-06-19 9:13 UTC (permalink / raw)
To: xmei5, dsahern, idosch, netdev
Cc: davem, edumazet, pabeni, kuba, horms, bestswngs
In-Reply-To: <20260619045334.2427073-1-xmei5@asu.edu>
On 6/19/26 6:53 AM, xmei5@asu.edu wrote:
> From: Xiang Mei <xmei5@asu.edu>
>
> fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and
> dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown()
> clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has
> released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and
> oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(),
> but this re-fetch is unguarded; nexthop-backed routes survive
> addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is
> nulled.
>
> Return 0 when idev is NULL, matching rt6_mtu_change_route() and the
> fib6_mtu() fix in commit 5ad509c1fdad ("ipv6: Fix null-ptr-deref in
> fib6_mtu().").
>
> Oops: general protection fault, ... KASAN: null-ptr-deref in range
> [0x00000000000002a8-0x00000000000002af]
> RIP: 0010:fib6_nh_mtu_change+0x203/0x990
> rt6_mtu_change_route+0x141/0x1d0
> __fib6_clean_all+0xd0/0x160
> rt6_mtu_change+0xb4/0x100
> ndisc_router_discovery+0x24b5/0x2cb0
> icmpv6_rcv+0x12e9/0x1710
> ipv6_rcv+0x39b/0x410
>
> Fixes: c0b220cf7d80 ("ipv6: Refactor exception functions")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Thanks!
^ permalink raw reply
* Re: [PATCH net] octeontx2-af: npc: cn20k: Fix subbank free list indexing for search order
From: Simon Horman @ 2026-06-19 9:13 UTC (permalink / raw)
To: rkannoth
Cc: Simon Horman, kuba, linux-kernel, netdev, andrew+netdev, davem,
edumazet, pabeni, sgoutham
In-Reply-To: <20260618035926.1490794-1-rkannoth@marvell.com>
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://netdev-ai.bots.linux.dev/sashiko/
---
octeontx2-af: npc: cn20k: Fix subbank free list indexing for search order
This change re-keys the xa_sb_free free list using each subbank's slot
in subbank_srch_order[] rather than using subbank_srch_order[sb->idx],
moving the population into a new helper called from npc_priv_init().
A few comments inline.
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> index 354c4e881c6a..d38e848add93 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> @@ -3423,6 +3423,36 @@ static int npc_create_srch_order(int cnt)
> return 0;
> }
>
> +static int npc_subbanks_srch_oder_init(struct rvu *rvu)
^^^^
[Low]
Is "oder" intended here? The neighbouring identifiers
npc_create_srch_order() and subbank_srch_order use "order", so this
appears to be a typo that would be easier to fix before the symbol
lands.
> +{
> + struct npc_subbank *sb;
> + int sb_idx;
> + int i, j;
> + int rc;
> +
> + for (i = 0; i < npc_priv->num_subbanks; i++) {
> + sb_idx = subbank_srch_order[i];
> + sb = &npc_priv->sb[sb_idx];
> + sb->arr_idx = i;
> +
> + dev_dbg(rvu->dev, "%s: sb->idx=%u sb->arr_idx=%u\n",
> + __func__, sb->idx, sb->arr_idx);
> +
> + rc = xa_err(xa_store(&npc_priv->xa_sb_free, sb->arr_idx,
> + xa_mk_value(sb->idx), GFP_KERNEL));
> + if (rc) {
> + dev_err(rvu->dev,
> + "%s: xa_store(xa_sb_free) failed at slot %d (sb=%d): %d\n",
> + __func__, i, sb_idx, rc);
> + for (j = 0; j < i; j++)
> + xa_erase(&npc_priv->xa_sb_free, j);
> + return rc;
> + }
> + }
> +
> + return 0;
> +}
> +
[ ... ]
> @@ -4727,6 +4748,10 @@ static int npc_priv_init(struct rvu *rvu)
> for (i = 0, sb = npc_priv->sb; i < num_subbanks; i++, sb++)
> npc_subbank_init(rvu, sb, i);
>
> + ret = npc_subbanks_srch_oder_init(rvu);
> + if (ret)
> + goto fail2;
> +
[Medium]
Can this leak subbank_srch_order on the new failure path?
npc_create_srch_order() allocates subbank_srch_order via kcalloc().
Before this patch, the only way to reach fail2 was when
npc_create_srch_order() itself failed and left subbank_srch_order
NULL, so fail2 not freeing it was safe.
With this new goto fail2, subbank_srch_order has already been
allocated, but the fail2 label only frees npc_priv->sb and npc_priv:
fail2:
xa_destroy(&npc_priv->xa_sb_used);
[...]
kfree(npc_priv->sb);
npc_priv->sb = NULL;
fail1:
kfree(npc_priv);
npc_priv = NULL;
return ret;
A subsequent re-init would unconditionally reassign
subbank_srch_order = kcalloc(...) in npc_create_srch_order(),
permanently leaking the previous buffer.
Should this path go to a new label that also kfree()s
subbank_srch_order, or should fail2 free it?
> /* Get number of pcifuncs in the system */
> npc_priv->pf_cnt = npc_pcifunc_map_create(rvu);
> npc_priv->xa_pf2idx_map = kcalloc(npc_priv->pf_cnt,
[High]
Can npc_priv_init() return 0 on a real failure here?
After npc_subbanks_srch_oder_init() returns successfully, ret is 0.
If the kcalloc() for npc_priv->xa_pf2idx_map fails right after, the
code does goto fail3 which falls through fail2 and fail1 to
return ret, propagating 0 to the caller:
fail3:
kfree(subbank_srch_order);
subbank_srch_order = NULL;
fail2:
[...]
fail1:
kfree(npc_priv);
npc_priv = NULL;
return ret;
The caller npc_cn20k_init() then sees err == 0 and continues into
npc_setup_mcam_section(), which dereferences npc_priv (now NULL).
Pre-patch the function ended in return -ENOMEM, so the fail3 path
returned -ENOMEM unconditionally. Should ret be reset to -ENOMEM
before goto fail3, or should a separate variable be used for the
new helper's return value?
> @@ -4760,7 +4785,7 @@ static int npc_priv_init(struct rvu *rvu)
> fail1:
> kfree(npc_priv);
> npc_priv = NULL;
> - return -ENOMEM;
> + return ret;
> }
^ permalink raw reply
* Re: [PATCH bpf v3 2/2] selftests/bpf: Cover partial copy of non-linear test_run output
From: sun jian @ 2026-06-19 9:08 UTC (permalink / raw)
To: Paul Chaignon
Cc: bot+bpf-ci, bpf, netdev, linux-kselftest, linux-kernel, ast,
daniel, andrii, martin.lau, eddyz87, memxor, song, yonghong.song,
jolsa, davem, edumazet, kuba, pabeni, horms, shuah, hawk,
john.fastabend, sdf, toke, lorenzo, martin.lau, clm,
ihor.solodrai
In-Reply-To: <ajT3x2H0swzg4yhm@mail.gmail.com>
On Fri, Jun 19, 2026 at 4:03 PM Paul Chaignon <paul.chaignon@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 06:45:18PM +0800, sun jian wrote:
> > On Thu, Jun 18, 2026 at 4:44 PM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> > >
> > > On Wed, Jun 17, 2026 at 10:19:52PM +0800, sun jian wrote:
> > > > On Wed, Jun 17, 2026 at 6:31 PM <bot+bpf-ci@kernel.org> wrote:
>
> [...]
>
> > > > I tried reusing pkt_v4 and the existing TC program, but they do not fit
> > > > the skb case this test is trying to cover.
> > > >
> > > > For skb test_run, IPv4/IPv6 inputs with a too-short L3 header in the
> > > > linear area are rejected before bpf_test_finish(). With pkt_v4 and a
> > > > linear area of ETH_HLEN, the test fails with -EINVAL before reaching the
> > > > partial copy-out path. If the linear area is increased enough to pass the
> > > > IPv4 check, pkt_v4 is too small to both trigger the old
> > > > copy_size - frag_size path and verify that the copied prefix spans the
> > > > linear data and the first fragment. pkt_v6 has the same issue: after
> > > > making the IPv6 header linear, only 20 bytes remain in frags.
> > > >
> > > > The existing test_pkt_access program has its own packet-access coverage
> > > > goals and is not just a pass-through carrier. With such a short linear
> > > > area or small packet fixture, it can fail before the test hits the
> > > > bpf_test_finish()'s partial copy-out path. A pass-through TC program is
> > > > therefore a better fit, because it keeps the test focused on the
> > > > bpf_test_finish() copy-out semantics.
> > >
> > > If we're keeping tc_pass_prog() then can't we use pkt_v4 and get rid of
> > > init_pkt?
> > >
> >
> > pkt_v4 is too small to construct a meaningful nonlinear skb with a stable
> > linear/frag split while still exercising the partial copy-out boundary in
> > bpf_test_finish().
> >
> > With pkt_v4, we either do not reach a fragmented layout, or lose control over
> > the linear/frag boundary needed to exercise the regression path.
>
> I think I'm missing something. Why can't we use pkt_v4 with
> tc_pass_prog() and a linear area of ETH_HLEN? That would leave 42 bytes
> of non-linear area, so a SHORT_OUT_LEN of 30 should work to trigger the
> bug, no?
>
I should have made that part clearer. With a linear area of ETH_HLEN, the
skb test_run path fails before reaching bpf_test_finish(). After
eth_type_trans(), skb->data is advanced past the Ethernet header, so the
remaining linear L3 area is 0. The short IPv4 input check then rejects the
packet with -EINVAL.
To pass that check with pkt_v4, the linear area has to include the IPv4
header as well, i.e. ETH_HLEN + sizeof(struct iphdr). That leaves only about
20 bytes in frags, so a SHORT_OUT_LEN of 30 no longer triggers the old
copy_size - frag_size < 0 path.
> >
> > This test uses a 9000B packet so it does not depend on small-packet
> > allocation details. Smaller packets might work depending on allocation
> > state, but 9000B reliably gives us a non-linear skb with page frags and a
> > stable linear/frag boundary for the copy-out regression.
> >
> > init_pkt() is needed to ensure deterministic byte content across both linear
> > and fragmented regions so that the memcmp-based validation is stable.
> >
> > Thanks,
> > Sun Jian
> >
> >
> > > >
> > > > For XDP, this object does not have an existing xdp.frags pass-through
> > > > program, so the small XDP frags program is needed to cover the other
> > > > caller of the shared bpf_test_finish() path.
> > > >
> > > > Thanks,
> > > > Sun Jian
^ permalink raw reply
* [PATCH net 2/2] octeontx2-af: suppress kpu profile loading warning
From: nshettyj @ 2026-06-19 9:07 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, lcherian, gakula, hkelam, sbhatta, andrew+netdev, davem,
edumazet, kuba, pabeni, Sunil.Goutham, naveenm, hkalra,
Nitin Shetty J
In-Reply-To: <20260619090746.1829416-1-nshettyj@marvell.com>
From: Harman Kalra <hkalra@marvell.com>
There are three ways in which a KPU profile can be loaded
(in high to low priority order):
1. profile image integrated in kernel image
2. firmware database method
3. default profile
In most cases the profile is loaded using the 2nd method, which
causes a spurious warning from the Linux firmware subsystem (method 1)
due to the absence of firmware in the kernel image.
Replace request_firmware_direct() with firmware_request_nowarn() to
suppress such warnings when no image is integrated into the kernel image.
Fixes: cf2437626502 ("octeontx2-af: suppress external profile loading warning")
Signed-off-by: Harman Kalra <hkalra@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
index 4994385a822b..a2de7f1c6c22 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
@@ -1966,7 +1966,7 @@ void npc_load_kpu_profile(struct rvu *rvu)
* Firmware database method.
* Default KPU profile.
*/
- if (!request_firmware_direct(&fw, kpu_profile, rvu->dev)) {
+ if (!firmware_request_nowarn(&fw, kpu_profile, rvu->dev)) {
dev_info(rvu->dev, "Loading KPU profile from firmware: %s\n",
kpu_profile);
rvu->kpu_fwdata = kzalloc(fw->size, GFP_KERNEL);
--
2.48.1
^ permalink raw reply related
* [PATCH net 1/2] octeontx2-af: fix VF bringup affecting PF promiscuous state
From: nshettyj @ 2026-06-19 9:07 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, lcherian, gakula, hkelam, sbhatta, andrew+netdev, davem,
edumazet, kuba, pabeni, Sunil.Goutham, naveenm, hkalra,
Nitin Shetty J
In-Reply-To: <20260619090746.1829416-1-nshettyj@marvell.com>
From: Harman Kalra <hkalra@marvell.com>
Mbox handling of nix_set_rx_mode for a VF with promiscuous and
all_multi flags set to false causes deletion of the PF's promiscuous
and allmulti MCAM rules. This occurs because the APIs that
enable/disable these rules operate only on the PF, even when the
mbox request is made via a VF interface.
Guard both rvu_npc_enable_allmulti_entry() and
rvu_npc_enable_promisc_entry() disable paths with an is_vf() check so
that a VF bringing up or tearing down its interface cannot inadvertently
clear the PF's MCAM rules.
Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature")
Signed-off-by: Harman Kalra <hkalra@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
index f977734ae712..f4c066aff371 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c
@@ -4548,7 +4548,7 @@ int rvu_mbox_handler_nix_set_rx_mode(struct rvu *rvu, struct nix_rx_mode *req,
rvu_npc_install_allmulti_entry(rvu, pcifunc, nixlf,
pfvf->rx_chan_base);
} else {
- if (!nix_rx_multicast)
+ if (!nix_rx_multicast && !is_vf(pcifunc))
rvu_npc_enable_allmulti_entry(rvu, pcifunc, nixlf, false);
}
@@ -4558,7 +4558,7 @@ int rvu_mbox_handler_nix_set_rx_mode(struct rvu *rvu, struct nix_rx_mode *req,
pfvf->rx_chan_base,
pfvf->rx_chan_cnt);
else
- if (!nix_rx_multicast)
+ if (!nix_rx_multicast && !is_vf(pcifunc))
rvu_npc_enable_promisc_entry(rvu, pcifunc, nixlf, false);
return 0;
--
2.48.1
^ permalink raw reply related
* [PATCH net 0/2] octeontx2-af: Bug fixes for KPU profile and VF RX mode
From: nshettyj @ 2026-06-19 9:07 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, lcherian, gakula, hkelam, sbhatta, andrew+netdev, davem,
edumazet, kuba, pabeni, Sunil.Goutham, naveenm, hkalra,
Nitin Shetty J
From: Nitin Shetty J <nshettyj@marvell.com>
This patch series contains two standalone bug fixes for the Octeontx2
administrative function (AF) driver targeting the net branch.
The first patch addresses a spurious firmware loading warning by
switching to the non-warning variant of the firmware request API when
falling back to alternative loading methods.
The second patch resolves an issue where a VF changing its interface
state could inadvertently delete the RX promiscuous and all-multicast
MCAM rules belonging to the host PF.
Harman Kalra (2):
octeontx2-af: fix VF bringup affecting PF promiscuous state
octeontx2-af: suppress kpu profile loading warning
drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 4 ++--
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.48.1
^ permalink raw reply
* Re: [PATCH 1/1] xfrm: nat_keepalive: avoid double free on send error
From: Qianyu Luo @ 2026-06-19 9:06 UTC (permalink / raw)
To: Eyal Birger
Cc: Ren Wei, netdev, steffen.klassert, herbert, davem, yuantan098,
bird
In-Reply-To: <CAHsH6Gvsf-JEQyetucAVT6mjaJDi=gMT1pDWFDagb1fhjmveGg@mail.gmail.com>
On Fri, Jun 19, 2026 at 1:21 AM Eyal Birger <eyal.birger@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 9:36 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
> >
> > From: Qianyu Luo <qianyuluo3@gmail.com>
> >
> > nat_keepalive_send() frees the keepalive skb whenever the IPv4 or IPv6
> > send helper reports an error.
> >
> > That cleanup is only correct before the skb is handed to the output
> > path. Once ip_build_and_send_pkt() or ip6_xmit() takes ownership, the
> > networking stack may already have consumed the skb before returning an
> > error, so freeing it again is unsafe.
> >
> > Handle the pre-handoff failure cases inside nat_keepalive_send_ipv4()
> > and nat_keepalive_send_ipv6(), where the caller still owns the skb, and
> > keep nat_keepalive_send() responsible only for family dispatch and the
> > unsupported-family cleanup path.
>
> Thanks for the fix!
>
> >
> > Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states")
> > Cc: stable@vger.kernel.org
> > Reported-by: Yuan Tan <yuantan098@gmail.com>
> > Reported-by: Xin Liu <bird@lzu.edu.cn>
> > Signed-off-by: Qianyu Luo <qianyuluo3@gmail.com>
> > Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> > ---
> > net/xfrm/xfrm_nat_keepalive.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c
> > index 458931062a04..f71328096f11 100644
> > --- a/net/xfrm/xfrm_nat_keepalive.c
> > +++ b/net/xfrm/xfrm_nat_keepalive.c
> > @@ -55,8 +55,10 @@ static int nat_keepalive_send_ipv4(struct sk_buff *skb,
> > ka->encap_sport, sock_net_uid(net, NULL));
> >
> > rt = ip_route_output_key(net, &fl4);
> > - if (IS_ERR(rt))
> > + if (IS_ERR(rt)) {
> > + kfree_skb(skb);
> > return PTR_ERR(rt);
> > + }
> >
> > skb_dst_set(skb, &rt->dst);
> >
> > @@ -100,6 +102,7 @@ static int nat_keepalive_send_ipv6(struct sk_buff *skb,
> > sock_net_set(sk, net);
> > dst = ip6_dst_lookup_flow(net, sk, &fl6, NULL);
> > if (IS_ERR(dst)) {
> > + kfree_skb(skb);
> > local_unlock_nested_bh(&nat_keepalive_sk_ipv6.bh_lock);
>
> Any reason to do the kfree under lock?
>
Thank you for your reply! I did this without particular reason.
Just to keep the pre-handoff cleanup in the same error path.
kfree_skb() does not need the bh lock there, so I can move it after the
unlock in v2 if you need!
> Eyal
^ permalink raw reply
* Re: [PATCH net] net: mana: Sync page pool RX frags for CPU
From: Simon Horman @ 2026-06-19 9:05 UTC (permalink / raw)
To: Dexuan Cui
Cc: kys, haiyangz, wei.liu, longli, andrew+netdev, davem, edumazet,
kuba, pabeni, kotaranov, ernis, dipayanroy, kees, jacob.e.keller,
ssengar, linux-hyperv, netdev, linux-kernel, linux-rdma, stable
In-Reply-To: <20260618035029.249361-1-decui@microsoft.com>
On Wed, Jun 17, 2026 at 08:50:29PM -0700, Dexuan Cui wrote:
> MANA allocates RX buffers from page pool fragments when frag_count is
> greater than 1. In that case the buffers remain DMA mapped by page pool
> and the RX completion path does not call dma_unmap_single(). As a result,
> the implicit sync-for-CPU normally performed by dma_unmap_single() is
> missing before the packet data is passed to the networking stack.
>
> This breaks RX on configurations which require explicit DMA syncing, for
> example when booted with swiotlb=force.
>
> Fix this by recording the page pool page and DMA sync offset when the RX
> buffer is allocated, and syncing the received packet range for CPU access
> before handing the RX buffer to the stack.
>
> Also validate the packet length reported in the RX CQE before using it as
> a DMA sync length or passing it to skb processing. The CQE is supplied
> by the device and should not be blindly trusted by Confidential VMs.
I think this last part warrants being split out into a separate patch.
>
> Fixes: 730ff06d3f5c ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
...
^ permalink raw reply
* [PATCH net] net: wwan: iosm: bound device offsets in the MUX downlink decoder
From: Maoyi Xie @ 2026-06-19 9:03 UTC (permalink / raw)
To: Loic Poulain, Sergey Ryazanov, Johannes Berg
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, linux-kernel, stable
mux_dl_adb_decode() walks a chain of aggregated datagram tables using
offsets and lengths taken from the modem. first_table_index,
next_table_index, table_length, datagram_index and datagram_length are
all device supplied le values. Only first_table_index was checked, and
only for being non zero. The decoder then formed adth = block +
adth_index and read the table header and the datagram entries with no
bound against the received skb. A modem that reports an index or a
length past the downlink buffer makes the decoder read out of bounds.
The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most
that, so skb->len is the real limit, but none of these in band offsets
were checked against it.
Validate every device offset and length against skb->len before use.
The block header must fit. Each table header, on entry and after every
next_table_index, must lie inside the skb. The datagram table must fit.
Each datagram index and length must stay inside the skb. The header
padding must not exceed the datagram length so the receive length does
not wrap.
This was reproduced under KASAN as a slab out of bounds read on a normal
downlink receive once the iosm net device is up.
Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support")
Cc: stable@vger.kernel.org
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/net/wwan/iosm/iosm_ipc_mux_codec.c | 23 ++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
index bff46f7ca59f..1c021bb0aa7a 100644
--- a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
+++ b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
@@ -557,15 +557,21 @@ static int mux_dl_process_dg(struct iosm_mux *ipc_mux, struct mux_adbh *adbh,
< sizeof(struct mux_adbh))
goto dg_error;
- /* Is the packet inside of the ADB */
+ /* Is the packet inside of the ADB and the received skb ? */
if (le32_to_cpu(dg->datagram_index) >=
- le32_to_cpu(adbh->block_length)) {
+ le32_to_cpu(adbh->block_length) ||
+ le32_to_cpu(dg->datagram_index) >= skb->len ||
+ le16_to_cpu(dg->datagram_length) >
+ skb->len - le32_to_cpu(dg->datagram_index)) {
goto dg_error;
} else {
packet_offset =
le32_to_cpu(dg->datagram_index) +
dl_head_pad_len;
dg_len = le16_to_cpu(dg->datagram_length);
+ /* The header padding must not exceed the datagram. */
+ if (dl_head_pad_len >= dg_len)
+ goto dg_error;
/* Pass the packet to the netif layer. */
rc = ipc_mux_net_receive(ipc_mux, if_id, ipc_mux->wwan,
packet_offset,
@@ -595,6 +601,10 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
block = skb->data;
adbh = (struct mux_adbh *)block;
+ /* The block header itself must fit in the received skb. */
+ if (skb->len < sizeof(struct mux_adbh))
+ goto adb_decode_err;
+
/* Process the aggregated datagram tables. */
adth_index = le32_to_cpu(adbh->first_table_index);
@@ -606,6 +616,11 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
/* Loop through mixed session tables. */
while (adth_index) {
+ /* The table header must lie within the received skb. */
+ if (adth_index < sizeof(struct mux_adbh) ||
+ adth_index > skb->len - sizeof(struct mux_adth))
+ goto adb_decode_err;
+
/* Get the reference to the table header. */
adth = (struct mux_adth *)(block + adth_index);
@@ -629,6 +644,10 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
if (le16_to_cpu(adth->table_length) < sizeof(struct mux_adth))
goto adb_decode_err;
+ /* The whole datagram table must fit in the received skb. */
+ if (le16_to_cpu(adth->table_length) > skb->len - adth_index)
+ goto adb_decode_err;
+
/* Calculate the number of datagrams. */
nr_of_dg = (le16_to_cpu(adth->table_length) -
sizeof(struct mux_adth)) /
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net 1/2] net: dsa: mxl862xx: avoid unaligned 16-bit access in api_wrap
From: David Laight @ 2026-06-19 9:01 UTC (permalink / raw)
To: Daniel Golle
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <599327521db465a534d277de53ab9b6cac01928b.1781702256.git.daniel@makrotopia.org>
On Fri, 19 Jun 2026 04:39:25 +0100
Daniel Golle <daniel@makrotopia.org> wrote:
> The MXL862XX_API_* macros pass the address of a stack-allocated, __packed
> firmware-ABI struct to mxl862xx_api_wrap() as a void *. The struct has an
> alignment of 1, so the compiler is free to place it at an odd address.
>
> mxl862xx_api_wrap() reinterprets that buffer as a __le16 * and accesses it
> with data[i], for which the compiler assumes the natural 2-byte alignment
> of __le16 and emits aligned 16-bit loads/stores (e.g. lhu/sh on MIPS).
> When the buffer lands on an odd address these fault on architectures that
> do not support unaligned access, such as MIPS32.
Isn't the correct fix to not pack the structure?
(or probably any of the associated structures??)
David
>
> -Waddress-of-packed-member does not catch this: the packed origin is
> laundered through the void * parameter, so the cast inside api_wrap looks
> alignment-safe to the compiler and no warning is emitted.
>
> Use get_unaligned_le16()/put_unaligned_le16() for the three 16-bit word
> accesses. The byte accesses (*(u8 *)&data[i], crc16()) are already safe
> and are left unchanged.
>
> Link: https://sashiko.dev/#/patchset/cover.1781319534.git.daniel%40makrotopia.org?part=4
> Fixes: 23794bec1cb6 ("net: dsa: add basic initial driver for MxL862xx switches")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> drivers/net/dsa/mxl862xx/mxl862xx-host.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/dsa/mxl862xx/mxl862xx-host.c b/drivers/net/dsa/mxl862xx/mxl862xx-host.c
> index d55f9dff6433..882c5d960941 100644
> --- a/drivers/net/dsa/mxl862xx/mxl862xx-host.c
> +++ b/drivers/net/dsa/mxl862xx/mxl862xx-host.c
> @@ -12,6 +12,7 @@
> #include <linux/crc16.h>
> #include <linux/iopoll.h>
> #include <linux/limits.h>
> +#include <linux/unaligned.h>
> #include <net/dsa.h>
> #include "mxl862xx.h"
> #include "mxl862xx-host.h"
> @@ -349,7 +350,7 @@ int mxl862xx_api_wrap(struct mxl862xx_priv *priv, u16 cmd, void *_data,
> * zero words individually.
> */
> for (i = 0, zeros = 0; i < size / 2 && zeros < RST_DATA_THRESHOLD; i++)
> - if (!data[i])
> + if (!get_unaligned_le16(&data[i]))
> zeros++;
>
> if (zeros < RST_DATA_THRESHOLD && (size & 1) && !*(u8 *)&data[i])
> @@ -395,7 +396,7 @@ int mxl862xx_api_wrap(struct mxl862xx_priv *priv, u16 cmd, void *_data,
> */
> val = *(u8 *)&data[i] | ((crc & 0xff) << 8);
> } else {
> - val = le16_to_cpu(data[i]);
> + val = get_unaligned_le16(&data[i]);
> }
>
> /* After RST_DATA, skip zero data words as the registers
> @@ -453,7 +454,7 @@ int mxl862xx_api_wrap(struct mxl862xx_priv *priv, u16 cmd, void *_data,
> *(uint8_t *)&data[i] = ret & 0xff;
> crc = (ret >> 8) & 0xff;
> } else {
> - data[i] = cpu_to_le16((u16)ret);
> + put_unaligned_le16((u16)ret, &data[i]);
> }
> }
>
^ permalink raw reply
* Re: [PATCH] net: phy: realtek: Clear MDIO_AN_10GBT_CTRL_ADV10G bit
From: Maxime Chevallier @ 2026-06-19 8:49 UTC (permalink / raw)
To: Jan Klos, Heiner Kallweit, Andrew Lunn, Russell King, netdev; +Cc: linux-kernel
In-Reply-To: <20260619011519.50009-2-honza.klos@gmail.com>
Hi,
On 6/19/26 03:15, Jan Klos wrote:
> On RTL8127A connected to a link partner that advertises 10000baseT
> speed cannot be changed to anything other than 10000baseT as 10GbE
> is always advertised regardless of any setting. Fix this by
> clearing MDIO_AN_10GBT_CTRL_ADV10G bit in rtl822x_config_aneg()'s
> call to phy_modify_mmd_changed().
Makes sense, this is also done as part of the C45 config_aneg sequence.
You're missing a few things process-wise :
- a Fixes tag to indicate the commit that introduced the bug
- You must CC all the relevant maintainers, including the top-level networking
maintainers, use ./scripts/get_maintainers.pl to get the list
- The patch must have in the subject an indication that this targets the
'net' tree, for bugfixes, see :
https://docs.kernel.org/process/maintainer-netdev.html
Feel free to re-send a V2 (after waiting 24h), and add my review tag :
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
>
> Signed-off-by: Jan Klos <honza.klos@gmail.com>
> ---
> drivers/net/phy/realtek/realtek_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index 27268811f564..b65d0f5fa1a0 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -1802,7 +1802,8 @@ static int rtl822x_config_aneg(struct phy_device *phydev)
> ret = phy_modify_mmd_changed(phydev, MDIO_MMD_VEND2,
> RTL_MDIO_AN_10GBT_CTRL,
> MDIO_AN_10GBT_CTRL_ADV2_5G |
> - MDIO_AN_10GBT_CTRL_ADV5G, adv);
> + MDIO_AN_10GBT_CTRL_ADV5G |
> + MDIO_AN_10GBT_CTRL_ADV10G, adv);
> if (ret < 0)
> return ret;
> }
>
> base-commit: 7d8297e26b4e20b5d1c3c3fe51fe81a1c7fbc823
^ permalink raw reply
* Re: [net PATCH v3] octeontx2-af: Validate NIX maximum LFs correctly
From: Simon Horman @ 2026-06-19 8:46 UTC (permalink / raw)
To: Subbaraya Sundeep
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, sgoutham, gakula,
bbhushan2, rkannoth, netdev, linux-kernel
In-Reply-To: <1781710853-23420-1-git-send-email-sbhatta@marvell.com>
On Wed, Jun 17, 2026 at 09:10:53PM +0530, Subbaraya Sundeep wrote:
> NIX maximum number of LFs can be set via devlink command
> but that can be done before assigning any LFs to a PF/VF.
> The condition used to check whether any LFs are assigned is
> incorrect. This patch fixes that condition.
>
> Fixes: dd7842878633 ("octeontx2-af: Add new devlink param to configure maximum usable NIX block LFs")
> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
> ---
> v3 changes:
> None, updated changelog
> v2 changes:
> Fixed AI review by updating error message
> Updated comment to mention modifying NIXLFs has to be done prior
> to attaching NIXLFs to any PFs/VFs.
Thanks for the updates.
Reviewed-by: Simon Horman <horms@kernel.org>
^ 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