* Re: [PATCH v19 net-next 00/11] nbl driver for Nebulamatrix NICs
From: Jakub Kicinski @ 2026-06-17 20:46 UTC (permalink / raw)
To: illusion.wang
Cc: dimon.zhao, alvin.wang, sam.chen, netdev, andrew+netdev, corbet,
horms, linux-doc, pabeni, vadim.fedorenko, lukas.bulwahn,
edumazet, enelsonmoore, skhan, hkallweit1, open list
In-Reply-To: <20260617044702.2439-1-illusion.wang@nebula-matrix.com>
On Wed, 17 Jun 2026 12:46:45 +0800 illusion.wang wrote:
> This patch series represents the first phase. We plan to integrate it in
> two phases: the first phase covers mailbox and chip configuration,
> while the second phase involves net dev configuration.
> Together, they will provide basic PF-based Ethernet port transmission and
> reception capabilities.
## Form letter - net-next-closed
We have already submitted our pull request with net-next material for v7.2,
and therefore net-next is closed for new drivers, features, code refactoring
and optimizations. We are currently accepting bug fixes only.
Please repost when net-next reopens after June 29th.
RFC patches sent for review only are obviously welcome at any time.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer
pv-bot: closed
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jakub Kicinski @ 2026-06-17 20:54 UTC (permalink / raw)
To: Jacob Keller
Cc: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, linux-mips,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <31630db0-85cb-421b-8ebe-bbae07521533@intel.com>
On Tue, 16 Jun 2026 16:42:18 -0700 Jacob Keller wrote:
> I'd probably also argue this may go against the desired goals of
> net-next with only wanting such cleanups when in the context of other
> larger work. Of course that decision ultimately belongs to the maintainers.
Yes, feeding const EINVAL into dev_err_probe() is pretty pointless
so if this helps it's just by "saving" 2 LoC. I'm not sure it's worth
it even in context of larger work, let along by itself.
--
pw-bot: reject
^ permalink raw reply
* Re: [PATCH v1 bpf-next 0/2] bpf: bpf_redirect_peer egress redirection
From: Jordan Rife @ 2026-06-17 21:10 UTC (permalink / raw)
To: Jiayuan Chen
Cc: Paul Chaignon, bpf, netdev, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Stanislav Fomichev
In-Reply-To: <9da94ca2-a479-42e2-8941-b38c1a08566b@linux.dev>
> Agree.
>
>
> For the existing bpf_redirect_peer(ifindex, 0), there are two ways to
> read what 0 means:
>
> 1. If we consider the operated object to be the peer of ifindex, then 0
> means the peer does ingress.
> 2. If we consider the operated object to be ifindex itself, then 0 means
> ifindex does egress
> (which results in its peer doing ingress).
>
> This patch's new mode operates on the peer — on the host side, we want
> to "write" to the dev inside the pod to
> make the packet look like it leaves the pod. That fits reading (1), where
> the flag describes the peer's direction: 0 is peer ingress, and this new
> mode is peer egress.
> So BPF_F_EGRESS would be the clearer name; reusing BPF_F_INGRESS for
> what is really a
> peer-egress action is what creates the ambiguity.
(2) is my original interpretation that makes BPF_F_INGRESS make sense;
you're operating on ifindex, so the flag matches the direction
relative to ifindex. Under that interpretation, 0 for "egress" (really
ingress on the peer side) and BPF_F_INGRESS for "ingress" (really
egress on the peer side) makes sense.
That said, I agree BPF_F_EGRESS is probably clearer, so I'll go with
that in the next version of the series.
^ permalink raw reply
* Re: [syzbot] [net?] WARNING in tls_err_abort
From: Jakub Kicinski @ 2026-06-17 21:14 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: syzbot, davem, edumazet, horms, john.fastabend, linux-kernel,
netdev, pabeni, syzkaller-bugs
In-Reply-To: <ajJwP14SWmdwwFYg@krikkit>
On Wed, 17 Jun 2026 12:00:31 +0200 Sabrina Dubroca wrote:
> 2026-06-16, 23:46:28 +0200, Sabrina Dubroca wrote:
> > 2026-06-16, 14:23:59 -0700, Jakub Kicinski wrote:
> > > In which case the question is whether we should try to remove
> > > the sock_error() instead? (stating the obvious I guess)
> >
> > That would make sense, but we can't prevent sock_error() being called
> > from some helper.
>
> Actually, getsockopt(SO_ERROR) will also clear sk_err. If we want to
> prevent further state transitions, we'll have to use something else
> (probably a flag in tls_context set by tls_err_abort()).
>
> So I'd go with 2 separate patches. The 2nd one will be a change in
> userspace-visible behavior, but hopefully not one they'd be upset
> about.
Seems reasonable, FWIW
^ permalink raw reply
* Re: [PATCH net-next v4 0/2] net: lan743x: add RMII support for PCI11x1x
From: Jakub Kicinski @ 2026-06-17 21:17 UTC (permalink / raw)
To: Thangaraj Samynathan
Cc: netdev, andrew+netdev, davem, edumazet, pabeni, horms,
bryan.whitehead, UNGLinuxDriver, linux-kernel
In-Reply-To: <20260617053241.157932-1-thangaraj.s@microchip.com>
On Wed, 17 Jun 2026 11:02:39 +0530 Thangaraj Samynathan wrote:
> This series adds RMII interface support for the Microchip PCI11x1x
> Ethernet controller.
>
> The PCI11x1x device supports RMII as an alternative MAC-PHY interface,
> selected via the STRAP_READ software strap register. Patch 1 reads the
> RMII strap bits from this register and sets the is_rmii_en flag. Patch 2
> uses this flag to configure the PHY interface mode, phylink supported
> interfaces, and enables RMII in hardware via the RMII_CTL register.
## Form letter - net-next-closed
We have already submitted our pull request with net-next material for v7.2,
and therefore net-next is closed for new drivers, features, code refactoring
and optimizations. We are currently accepting bug fixes only.
Please repost when net-next reopens after June 29th.
RFC patches sent for review only are obviously welcome at any time.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer
pv-bot: closed
^ permalink raw reply
* Re: [PATCH v27 4/5] sfc: obtain and map cxl range using devm_cxl_probe_mem
From: Alejandro Lucero Palau @ 2026-06-17 21:18 UTC (permalink / raw)
To: Dan Williams (nvidia), alejandro.lucero-palau, linux-cxl, netdev,
edward.cree, davem, kuba, pabeni, edumazet, dave.jiang
In-Reply-To: <a423702c-05f6-4b4b-9ad4-fcaec2e07957@amd.com>
On 6/17/26 10:42, Alejandro Lucero Palau wrote:
>
> On 6/16/26 20:51, Dan Williams (nvidia) wrote:
>> Alejandro Lucero Palau wrote:
>>> On 6/10/26 14:56, Alejandro Lucero Palau wrote:
>>>> On 6/10/26 07:10, Alejandro Lucero Palau wrote:
>>>>> On 6/10/26 00:30, Dan Williams (nvidia) wrote:
>>>>>> alejandro.lucero-palau@ wrote:
>>>>>>> From: Alejandro Lucero <alucerop@amd.com>
>>>>>>>
>>>>>>> Use core API for safely obtain the CXL range linked to an HDM
>>>>>>> committed
>>>>>>> by the BIOS. Map such a range for being used as the ctpio buffer.
>>>>>>>
>>>>>>> A potential user space action through sysfs unbinding or core cxl
>>>>>>> modules remove will trigger sfc driver device detachment, with that
>>>>>>> case
>>>>>>> not racing with this mapping as this is done during driver probe
>>>>>>> and
>>>>>>> therefore protected with device lock against those user space
>>>>>>> actions.
>>>>>>>
>>>>>>> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
>>>>>>> ---
>>>>>>> drivers/net/ethernet/sfc/efx.c | 1 +
>>>>>>> drivers/net/ethernet/sfc/efx_cxl.c | 24 ++++++++++++++++++++++++
>>>>>>> drivers/net/ethernet/sfc/efx_cxl.h | 3 +++
>>>>>>> 3 files changed, 28 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ethernet/sfc/efx.c
>>>>>>> b/drivers/net/ethernet/sfc/efx.c
>>>>>>> index 90ccbe310386..578054c21e79 100644
>>>>>>> --- a/drivers/net/ethernet/sfc/efx.c
>>>>>>> +++ b/drivers/net/ethernet/sfc/efx.c
>>>>>>> @@ -984,6 +984,7 @@ static void efx_pci_remove(struct pci_dev
>>>>>>> *pci_dev)
>>>>>>> efx_fini_io(efx);
>>>>>>> probe_data = container_of(efx, struct efx_probe_data,
>>>>>>> efx);
>>>>>>> + efx_cxl_exit(probe_data);
>>>>>>> pci_dbg(efx->pci_dev, "shutdown successful\n");
>>>>>>> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c
>>>>>>> b/drivers/net/ethernet/sfc/efx_cxl.c
>>>>>>> index 4d55c08cf2a1..d5766a40e2cf 100644
>>>>>>> --- a/drivers/net/ethernet/sfc/efx_cxl.c
>>>>>>> +++ b/drivers/net/ethernet/sfc/efx_cxl.c
>>>>>>> @@ -18,6 +18,7 @@ int efx_cxl_init(struct efx_probe_data
>>>>>>> *probe_data)
>>>>>>> {
>>>>>>> struct efx_nic *efx = &probe_data->efx;
>>>>>>> struct pci_dev *pci_dev = efx->pci_dev;
>>>>>>> + struct range cxl_pio_range;
>>>>>>> struct efx_cxl *cxl;
>>>>>>> u16 dvsec;
>>>>>>> int rc;
>>>>>>> @@ -75,9 +76,32 @@ int efx_cxl_init(struct efx_probe_data
>>>>>>> *probe_data)
>>>>>>> return -ENODEV;
>>>>>>> }
>>>>>>> + cxl->cxlmd = devm_cxl_probe_mem(&cxl->cxlds,
>>>>>>> &cxl_pio_range);
>>>>>>> + if (IS_ERR(cxl->cxlmd)) {
>>>>>>> + pci_err(pci_dev, "CXL accel memdev creation failed\n");
>>>>>>> + return PTR_ERR(cxl->cxlmd);
>>>>>>> + }
>>>>>>> +
>>>>>>> + cxl->ctpio_cxl = ioremap_wc(cxl_pio_range.start,
>>>>>>> + range_len(&cxl_pio_range));
>>>>>>> + if (!cxl->ctpio_cxl) {
>>>>>>> + pci_err(pci_dev, "CXL ioremap region (%pra) failed\n",
>>>>>>> + &cxl_pio_range);
>>>>>>> + return -ENOMEM;
>>>>>> Dave caught the iounmap leak, but another concern is since you
>>>>>> want to
>>>>>> continue operation if efx_cxl_init() fails then you probably also
>>>>>> want
>>>>>> to release the successful attachment to the CXL domain if this
>>>>>> happens.
>>>>>
>>>>> I will do that.
>>>>>
>>>> Looking at this issue, I think an error when creating the memdev or
>>>> during the region attach triggers the memdev removal, but ...
>>>>
>>>>
>>>>>> Minor since something else is likely to fail if ioremap is not
>>>>>> reliable.
>>>>
>>>> .. if we want to specifically do that with an unlikely (but possible)
>>>> ioremap error something else needs to be exported like
>>>> cxl_memdev_unregister(). Are you happy with that approach?
>>>>
>>> I have just tested with this:
>>>
>>> +void cxl_memdev_remove(void *_cxlmd)
>>> +{
>>> + struct cxl_memdev *cxlmd = _cxlmd;
>>> + struct device *dev = &cxlmd->dev;
>>> +
>>> + devm_remove_action_nowarn(cxlmd->cxlds->dev,
>>> cxl_memdev_unregister,
>>> + cxlmd);
>>> +
>>> + cdev_device_del(&cxlmd->cdev, dev);
>>> + cxl_memdev_shutdown(dev);
>>> + put_device(dev);
>>> +}
>>> +EXPORT_SYMBOL_NS_GPL(cxl_memdev_remove, "CXL");
>>>
>>>
>>> only called if the ioremap fails.
>>>
>>>
>>> Please, let me know if you like this approach before sending another
>>> version.
>> A devres group can automatically cleanup after devm_cxl_memdev_probe()
>> in the error path with no new exports needed from the CXL core.
>> Something like:
>>
>> void *group = devres_open_group(cxl->cxlds.dev, NULL,
>> GFP_KERNEL);
>> int rc = 0;
>>
>> if (!group)
>> return -ENOMEM;
>> cxl->cxlmd = devm_cxl_probe_mem(&cxl->cxlds,
>> &cxl_pio_range);
>> if (IS_ERR(cxl->cxlmd)) {
>> pci_err(pci_dev, "CXL accel memdev creation failed\n");
>> rc = PTR_ERR(cxl->cxlmd);
>> goto out;
>> }
>>
>> cxl->ctpio_cxl =
>> ioremap_wc(cxl_pio_range.start,
>> range_len(&cxl_pio_range));
>> if (!cxl->ctpio_cxl) {
>> pci_err(pci_dev, "CXL ioremap region (%pra) failed\n",
>> &cxl_pio_range);
>> rc = -ENOMEM;
>> }
>>
>> out:
>> if (rc)
>> devres_release_group(group);
>> else
>> devres_remove_group(group);
>> return rc;
>
>
> OK. I will use this in v28 instead of that export.
>
Adding this implies the full driver is detached from the device. The
same can be obtained changing the check of efx_cxl_init() call and make
the probe to fail if an error is returned.
I prefer to do this after discussing this internally. After all, if
CXL.mem is there and the related initialization fails, this is not
expected and it should be fixed.
Sending v28 shortly.
>
> Thanks
>
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jacob Keller @ 2026-06-17 21:26 UTC (permalink / raw)
To: Jakub Kicinski
Cc: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, linux-mips,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617135407.6ff54e27@kernel.org>
On 6/17/2026 1:54 PM, Jakub Kicinski wrote:
> On Tue, 16 Jun 2026 16:42:18 -0700 Jacob Keller wrote:
>> I'd probably also argue this may go against the desired goals of
>> net-next with only wanting such cleanups when in the context of other
>> larger work. Of course that decision ultimately belongs to the maintainers.
>
> Yes, feeding const EINVAL into dev_err_probe() is pretty pointless
> so if this helps it's just by "saving" 2 LoC. I'm not sure it's worth
> it even in context of larger work, let along by itself.
It does claim that it has benefit since you get the error code emitted
symbolically. But we have %pe for that. I wonder if dev_err_probe
predates %pe?
Per commit: 532888a59505 ("driver core: Better advertise dev_err_probe()"):
> Describing the usage of dev_err_probe() as being (only?) "deemed
> acceptable" has a bad connotation. In fact dev_err_probe() fulfills
> three tasks:
>
> - handling of EPROBE_DEFER (even more than degrading to dev_dbg())
> - symbolic output of the error code
> - return err for compact error code paths
This was in 2023.. %pe was introduced in 2019, so I guess %pe is even older.
I personally find dev_err_probe acceptable and might find it nice when
writing new code, but I agree its not really meaningful gain to refactor
existing legacy code.
Anyways, all this to say in too many words: this patch doesn't seem to
have much value for netdev.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v3] net: mvneta_bm: add suspend/resume support to prevent crash after resume
From: Jakub Kicinski @ 2026-06-17 21:35 UTC (permalink / raw)
To: Yun Zhou
Cc: marcin.s.wojtas, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <20260616112540.4181231-1-yun.zhou@windriver.com>
On Tue, 16 Jun 2026 19:25:40 +0800 Yun Zhou wrote:
> Add a device_link (DL_FLAG_AUTOREMOVE_CONSUMER) in mvneta_probe to
> guarantee BM resumes before mvneta and suspends after mvneta.
You say "guarantee" but you pretty much ignore the failure to add it:
+ if (!device_link_add(&pdev->dev,
+ &pp->bm_priv->pdev->dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER))
+ dev_warn(&pdev->dev,
+ "failed to create device link to BM\n");
}
Why not handle this error properly ?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 6.6.y] rxrpc: Fix the ACK parser to extract the SACK table for parsing
From: Sasha Levin @ 2026-06-17 21:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: stable, David Howells, Michael Bommarito, Marc Dionne,
Jeffrey Altman, Eric Dumazet, David S. Miller, Paolo Abeni,
Simon Horman, linux-afs, netdev, stable
In-Reply-To: <20260617132704.0e1fe56b@kernel.org>
On Wed, Jun 17, 2026 at 01:27:04PM -0700, Jakub Kicinski wrote:
>On Wed, 17 Jun 2026 14:04:10 -0400 Sasha Levin wrote:
>> Subject: [PATCH 6.6.y] rxrpc: Fix the ACK parser to extract the SACK table for parsing
>> Date: Wed, 17 Jun 2026 14:04:10 -0400
>> X-Mailer: git-send-email 2.53.0
>>
>> From: David Howells <dhowells@redhat.com>
>>
>> [ Upstream commit 333b6d5bb9f87827ac2639c737bf9613dbae7253 ]
>
>nit: you missed the "skip patchwork" header on this?
Hey Jakub,
This one is a backport crafted in response to a failed backport of a stable
tagged commit.
I followed Greg's template to sending those backports to him, but I also think
that I do want folks to review the actual backport itself.
Do you think it makes sense to add a skip patchwork header on these too?
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH net] net/sched: act_ct: fix nf_connlabels leak on two error paths
From: Michael Bommarito @ 2026-06-17 21:57 UTC (permalink / raw)
To: Jamal Hadi Salim, Jiri Pirko
Cc: Pablo Neira Ayuso, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
tcf_ct_fill_params() calls nf_connlabels_get() (setting put_labels) when
TCA_CT_LABELS is present, but two later error sites use a bare return
instead of "goto err", skipping the err: nf_connlabels_put() cleanup.
They also precede the "p->put_labels = put_labels" assignment, so the
tcf_ct_params_free() fallback does not release the count either. Each
failed RTM_NEWACTION on these paths leaks one nf_connlabels reference:
net->ct.labels_used is incremented and never released. The action is
reachable with CAP_NET_ADMIN over the netns, i.e. from an unprivileged
user namespace on default-userns kernels.
Impact: an unprivileged user with CAP_NET_ADMIN over a network namespace
(e.g. via user namespaces) leaks one nf_connlabels reference per failed
RTM_NEWACTION on the two error paths; net->ct.labels_used is never
released.
The err: label is safe to reach from both sites: p->tmpl is still NULL
there (kzalloc'd, not yet assigned) and nf_ct_put(NULL) is a no-op, so
no inline release is needed.
Fixes: 70f06c115bcc ("sched: act_ct: switch to per-action label counting")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Testing: refcount/counter leak (CWE-772); no sanitizer for this class, so
the oracle is the nf_connlabels accounting counter net->ct.labels_used.
Reproduction (UML, before/after, same trigger): CONFIG_NET_ACT_CT=y,
NF_CONNTRACK_LABELS=y, NF_CONNTRACK_ZONES=n (forces the zone-disabled
path). A raw RTM_NEWACTION trigger adds "action ct label 0x1/0x1 zone 1"
20 times; each returns -EOPNOTSUPP.
stock: net->ct.labels_used climbs 1,2,...,20 (get, then bare return,
no put) -- 20 leaked counts, never recovered.
patched: counter stays balanced (get then goto err -> put); baseline.
Control: the same loop without "label" (no nf_connlabels_get) leaves the
counter unchanged on both trees -- the trigger reached the labels path and
the synthesis is not itself the cause.
Conditions: reachable via RTM_NEWACTION with CAP_NET_ADMIN over the netns,
i.e. an unprivileged user in a fresh user+net namespace on default-userns
distros. The easy path needs CONFIG_NF_CONNTRACK_ZONES=n; the
nf_ct_tmpl_alloc ENOMEM path leaks on any config under memory pressure.
Mitigations: restrict unprivileged user namespaces; otherwise none short of
the fix. Harness (trigger.c, init) available on request.
net/sched/act_ct.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
index 6158e13c98d35..f5866a364a74a 100644
--- a/net/sched/act_ct.c
+++ b/net/sched/act_ct.c
@@ -1295,7 +1295,8 @@ static int tcf_ct_fill_params(struct net *net,
if (tb[TCA_CT_ZONE]) {
if (!IS_ENABLED(CONFIG_NF_CONNTRACK_ZONES)) {
NL_SET_ERR_MSG_MOD(extack, "Conntrack zones isn't enabled.");
- return -EOPNOTSUPP;
+ err = -EOPNOTSUPP;
+ goto err;
}
tcf_ct_set_key_val(tb,
@@ -1308,7 +1309,8 @@ static int tcf_ct_fill_params(struct net *net,
tmpl = nf_ct_tmpl_alloc(net, &zone, GFP_KERNEL);
if (!tmpl) {
NL_SET_ERR_MSG_MOD(extack, "Failed to allocate conntrack template");
- return -ENOMEM;
+ err = -ENOMEM;
+ goto err;
}
p->tmpl = tmpl;
if (tb[TCA_CT_HELPER_NAME]) {
--
2.53.0
^ permalink raw reply related
* [PATCH] mptcp: only honor zero-length DATA_FIN when a mapping is present
From: Michael Bommarito @ 2026-06-17 21:57 UTC (permalink / raw)
To: Matthieu Baerts, Mat Martineau
Cc: Geliang Tang, Paolo Abeni, Eric Dumazet, Jakub Kicinski, mptcp,
netdev, linux-kernel
mptcp_get_options() initializes only the status group of struct
mptcp_options_received; data_seq, subflow_seq and data_len are set by
mptcp_parse_option() only inside the DSS mapping block, which runs when
the DSS M (mapping present) bit is set.
A peer can send a DSS option with DATA_FIN set but the mapping bit clear.
The parser then sets mp_opt.data_fin while leaving data_len and data_seq
uninitialized, and for a zero-length segment mptcp_incoming_options()
reads them; KMSAN reports an uninit-value in mptcp_incoming_options().
Impact: a remote peer that has completed the MPTCP handshake makes
mptcp_incoming_options() read uninitialized data_len and data_seq (KMSAN
uninit-value) by sending a DSS option with DATA_FIN set and the mapping
bit clear.
A DATA_FIN is always sent with a mapping (mptcp_write_data_fin()), so
gating this path on the mapping bit drops only the malformed no-map case
and leaves valid DATA_FIN handling unchanged.
Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
The stale data_seq then reaches mptcp_update_rcv_data_fin(); no further
consequence is demonstrated, so this is a robustness fix. The read site
for a zero-length segment is:
if (mp_opt.data_fin && mp_opt.data_len == 1 &&
mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
Reproduced under KMSAN: a no-map DSS DATA_FIN crafted on the wire and
injected over a TUN device into a real MPTCP listener produces twelve
"uninit-value in mptcp_incoming_options" reports on stock and none on the patched build (the unrelated mm-side
KMSAN boot noise present on both trees is not affected); a well-formed mapped DATA_FIN
(control) drives the same branch with no report. Harness on request.
net/mptcp/options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index dff3fd5d3b559..e40efa26a6694 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -1227,7 +1227,7 @@ bool mptcp_incoming_options(struct sock *sk, struct sk_buff *skb)
* present, needs to be updated here before the skb is freed.
*/
if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq) {
- if (mp_opt.data_fin && mp_opt.data_len == 1 &&
+ if (mp_opt.use_map && mp_opt.data_fin && mp_opt.data_len == 1 &&
mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
mptcp_schedule_work((struct sock *)msk);
--
2.53.0
^ permalink raw reply related
* [PATCH] idpf: bound interrupt-vector register fill to the allocated array
From: Michael Bommarito @ 2026-06-17 21:57 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Joshua Hay, Pavan Kumar Linga,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
idpf_get_reg_intr_vecs() fills the caller-allocated reg_vals[] array from
the VIRTCHNL2_OP_ALLOC_VECTORS reply in adapter->req_vec_chunks, bounding
its inner loop only by the per-chunk num_vectors. The array is sized
separately: idpf_intr_reg_init() allocates
kzalloc_objs(struct idpf_vec_regs, total_vecs) from
caps.num_allocated_vectors and only checks the returned count after the
fill. The sum of per-chunk num_vectors is never reconciled against
total_vecs, so a reply with a small num_allocated_vectors but chunks
summing higher writes past the end of reg_vals[].
Impact: a control plane (a PF or hypervisor device model) that returns a
VIRTCHNL2_OP_ALLOC_VECTORS reply whose per-chunk num_vectors sum exceeds
num_allocated_vectors writes struct idpf_vec_regs entries past the end of
the reg_vals kmalloc allocation (KASAN slab-out-of-bounds write).
Bound the fill loop to the array capacity passed in by the callers,
mirroring the sibling idpf_vport_get_q_reg(). The existing
num_regs < num_vecs check then rejects an undersized reply without the
out-of-bounds write happening first.
Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport")
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
The reply originates from the control plane (a PF or hypervisor device
model), which is trusted in a standard deployment, so this is a
defense-in-depth / robustness fix: it bounds a malformed or internally
inconsistent ALLOC_VECTORS reply. It is a genuine trust-boundary crossing
only where the guest distrusts the control plane (a confidential VM or an
Intel IPU posture) or the control plane is simply buggy. It is not
remotely or unprivileged-reachable.
Reproduced with a KUnit harness that calls the unmodified
idpf_get_reg_intr_vecs() against a crafted req_vec_chunks reply
(num_allocated_vectors = 1, four chunks of sixteen vectors) under KASAN:
stock reports a slab-out-of-bounds write 0 bytes past a 12-byte kmalloc-16
object and the test fails; the patched build is KASAN-clean; a well-formed
64-vector reply still fills 64 entries on both. The KUnit wiring is
repro-only scaffolding, not part of this patch; harness on request.
drivers/net/ethernet/intel/idpf/idpf_dev.c | 2 +-
drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 2 +-
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 5 +++--
drivers/net/ethernet/intel/idpf/idpf_virtchnl.h | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_dev.c b/drivers/net/ethernet/intel/idpf/idpf_dev.c
index 1a0c71c95ef12..4079a787657f1 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_dev.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_dev.c
@@ -87,7 +87,7 @@ static int idpf_intr_reg_init(struct idpf_vport *vport,
if (!reg_vals)
return -ENOMEM;
- num_regs = idpf_get_reg_intr_vecs(adapter, reg_vals);
+ num_regs = idpf_get_reg_intr_vecs(adapter, reg_vals, total_vecs);
if (num_regs < num_vecs) {
err = -EINVAL;
goto free_reg_vals;
diff --git a/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c b/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c
index a07d7e808ca9b..6726084f6cfa0 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c
@@ -86,7 +86,7 @@ static int idpf_vf_intr_reg_init(struct idpf_vport *vport,
if (!reg_vals)
return -ENOMEM;
- num_regs = idpf_get_reg_intr_vecs(adapter, reg_vals);
+ num_regs = idpf_get_reg_intr_vecs(adapter, reg_vals, total_vecs);
if (num_regs < num_vecs) {
err = -EINVAL;
goto free_reg_vals;
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index be66f9b2e101c..ec7330603ff84 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -1318,11 +1318,12 @@ idpf_vport_init_queue_reg_chunks(struct idpf_vport_config *vport_config,
* idpf_get_reg_intr_vecs - Get vector queue register offset
* @adapter: adapter structure to get the vector chunks
* @reg_vals: Register offsets to store in
+ * @num_vecs: number of entries the @reg_vals array can hold
*
* Return: number of registers that got populated
*/
int idpf_get_reg_intr_vecs(struct idpf_adapter *adapter,
- struct idpf_vec_regs *reg_vals)
+ struct idpf_vec_regs *reg_vals, int num_vecs)
{
struct virtchnl2_vector_chunks *chunks;
struct idpf_vec_regs reg_val;
@@ -1346,7 +1347,7 @@ int idpf_get_reg_intr_vecs(struct idpf_adapter *adapter,
dynctl_reg_spacing = le32_to_cpu(chunk->dynctl_reg_spacing);
itrn_reg_spacing = le32_to_cpu(chunk->itrn_reg_spacing);
- for (i = 0; i < num_vec; i++) {
+ for (i = 0; i < num_vec && num_regs < num_vecs; i++) {
reg_vals[num_regs].dyn_ctl_reg = reg_val.dyn_ctl_reg;
reg_vals[num_regs].itrn_reg = reg_val.itrn_reg;
reg_vals[num_regs].itrn_index_spacing =
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
index 6876e3ed9d1be..9b1c9c86f6eac 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.h
@@ -104,7 +104,7 @@ int idpf_vc_core_init(struct idpf_adapter *adapter);
void idpf_vc_core_deinit(struct idpf_adapter *adapter);
int idpf_get_reg_intr_vecs(struct idpf_adapter *adapter,
- struct idpf_vec_regs *reg_vals);
+ struct idpf_vec_regs *reg_vals, int num_vecs);
int idpf_queue_reg_init(struct idpf_vport *vport,
struct idpf_q_vec_rsrc *rsrc,
struct idpf_queue_id_reg_info *chunks);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone
From: Ilya Maximets @ 2026-06-17 22:01 UTC (permalink / raw)
To: Gustavo A. R. Silva, netdev
Cc: i.maximets, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Kees Cook, Gustavo A. R. Silva,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-kernel, linux-hardening, llvm, Johan Thomsen
In-Reply-To: <9e941b82-23d4-44e6-a240-b7949ace76ab@embeddedor.com>
On 6/17/26 10:08 PM, Gustavo A. R. Silva wrote:
> Hi,
>
> On 6/16/26 04:03, Ilya Maximets wrote:
>> kmalloc_flex() in metadata_dst_alloc() sets __counted_by for the
>> structure to the options_len, which is then initialized to zero.
>> Later, we're initializing the structure by copying the tunnel info
>> together with the options, and this triggers a warning for a potential
>> memcpy overflow, since the compiler estimates that the options can't
>> fit into the structure, even though the memory for them is actually
>> allocated.
>>
>> memcpy: detected buffer overflow: 104 byte write of buffer size 96
>> WARNING: CPU: X PID: Y at lib/string_helpers.c:1036 __fortify_report
>> skb_tunnel_info_unclone+0x179/0x190
>> geneve_xmit+0x7fe/0xe00
>
> This warning has nothing to do with counted_by. See below for more
> comments.
>
>>
>> The issue is triggered when built with clang and source fortification.
>>
>> Fix that by doing the copy in two stages: first - the main data with
>> the options_len, then the options. This way the correct length should
>> be known at the time of the copy.
>>
>> It would be better if the options_len never changed after allocation,
>> but the allocation code is a little separate from the initialization
>> and it would be awkward and potentially dangerous to return a struct
>> with options_len set to a non-zero value from the metadata_dst_alloc().
>>
>> Another option would be to use ip_tunnel_info_opts_set(), but it is
>> doing too many unnecessary operations for the use case here.
>>
>> Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
>> Reported-by: Johan Thomsen <write@ownrisk.dk>
>> Closes: https://lore.kernel.org/netdev/CAKv6aAM8_EWgXScnKmKYm_4SwGDVBK++dzfP+Y6msUXbp99QUw@mail.gmail.com/
>> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
>> ---
>>
>> Johan, if you can test this one in your setup as well, that would
>> be great. Thanks.
>>
>> include/net/dst_metadata.h | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
>> index 1fc2fb03ce3f..f45d1e3163f0 100644
>> --- a/include/net/dst_metadata.h
>> +++ b/include/net/dst_metadata.h
>> @@ -164,8 +164,11 @@ static inline struct metadata_dst *tun_dst_unclone(struct sk_buff *skb)
>> if (!new_md)
>> return ERR_PTR(-ENOMEM);
>>
>> - memcpy(&new_md->u.tun_info, &md_dst->u.tun_info,
>> - sizeof(struct ip_tunnel_info) + md_size);
>
> What's going on here is that, internally, fortified memcpy() retrieves
> the destination size via __builtin_dynamic_object_size() in mode 1.
>
> That is:
>
> __builtin_dynamic_object_size(&new_md->u.tun_info, 1)
>
> For the above case, Clang returns sizeof(new_md->u.tun_info) == 96.
>
> So the warning is reporting that 104 bytes don't fit in an object of
> size 96 bytes, regardless of any counted_by annotation or allocation.
Hmm. Does __builtin_dynamic_object_size(&new_md->u.tun_info, 1) return
104 when the options_len is 8? If so, isn't that because it is counted
by that field? Asking because the fortification doesn't complain if we
keep the full 104-byte copy as-is, but set the options_len beforehand,
as tested by Johan.
>
> Of course, in this case, the write of 104 bytes into new_md->u.tun_info
> is intentional and controlled, but what if it weren't?
>
> On the other hand, for this same case, GCC currently returns SIZE_MAX,
> which translates to -1 inside fortified memcpy(). Thus, bounds-checking
> is bypassed, which is why this warning doesn't show up with GCC.
>
> However, this is a bug in GCC. We're already looking into that.
>
> I think we've had just a handful of cases like this across the whole
> kernel tree. We can deal with them as you did here (by directly copying
> the composite structure first, and then using memcpy() to copy into the
> flexible-array member). If these cases ever become more common, we
> could create some kind of helper to do both things at once. :)
>
>> + /* Copy in two stages to keep the __counted_by happy. */
>
> So based on my comments above, this code comment is not correct.
I feel like some comment is still needed, do you have some suggestions
for what would be a better wording?
>
>> + new_md->u.tun_info = md_dst->u.tun_info;
>
> This is fine.
>
>> + memcpy(ip_tunnel_info_opts(&new_md->u.tun_info),
>> + ip_tunnel_info_opts(&md_dst->u.tun_info), md_size);
>
> Is ip_tunnel_info_opts() really needed here?
>
> Probably this works just fine:
>
> memcpy(new_md->u.tun_info.options, md_dst->u.tun_info.options, md_size);
The logic here is: we have the access function, therefore we should use it.
It gives a bad example if we don't.
Best regards, Ilya Maximets.
^ permalink raw reply
* Re: [PATCH 6.6.y] rxrpc: Fix the ACK parser to extract the SACK table for parsing
From: Jakub Kicinski @ 2026-06-17 22:05 UTC (permalink / raw)
To: Sasha Levin
Cc: stable, David Howells, Michael Bommarito, Marc Dionne,
Jeffrey Altman, Eric Dumazet, David S. Miller, Paolo Abeni,
Simon Horman, linux-afs, netdev, stable
In-Reply-To: <ajMXGIoyTqpZCvw-@laps>
On Wed, 17 Jun 2026 17:52:24 -0400 Sasha Levin wrote:
> On Wed, Jun 17, 2026 at 01:27:04PM -0700, Jakub Kicinski wrote:
> >On Wed, 17 Jun 2026 14:04:10 -0400 Sasha Levin wrote:
> >> Subject: [PATCH 6.6.y] rxrpc: Fix the ACK parser to extract the SACK table for parsing
> >> Date: Wed, 17 Jun 2026 14:04:10 -0400
> >> X-Mailer: git-send-email 2.53.0
> >>
> >> From: David Howells <dhowells@redhat.com>
> >>
> >> [ Upstream commit 333b6d5bb9f87827ac2639c737bf9613dbae7253 ]
> >
> >nit: you missed the "skip patchwork" header on this?
>
> Hey Jakub,
>
> This one is a backport crafted in response to a failed backport of a stable
> tagged commit.
>
> I followed Greg's template to sending those backports to him, but I also think
> that I do want folks to review the actual backport itself.
I see!
> Do you think it makes sense to add a skip patchwork header on these too?
Hm, maybe some clever patchwork DB query would tell us what others do.
For networking the patchwork queue is purely for patches we have to
apply. So my preference would be to skip, but I didn't realize this
was intentional.
It'd still be useful to add _some_ header that we could filter on.
We have bots which complain if people repost patches too fast,
they will get confused.
^ permalink raw reply
* Re: [PATCH] net: stmmac: loongson1: Use dev_err_probe()
From: Jakub Kicinski @ 2026-06-17 22:07 UTC (permalink / raw)
To: Jacob Keller
Cc: keguang.zhang, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, linux-mips,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <6b8db599-5bb2-47f9-ab53-a0b5141af2e5@intel.com>
On Wed, 17 Jun 2026 14:26:25 -0700 Jacob Keller wrote:
> It does claim that it has benefit since you get the error code emitted
> symbolically. But we have %pe for that. I wonder if dev_err_probe
> predates %pe?
I'd argue
No of match data provided: -EINVAL
is more confusing than just:
No of match data provided
the EINVAL is meaningless and hardcoded in this case?
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox