* [PATCH iwl-net v4 0/2] ice: fix DFLT Rx rule handling for promisc and switchdev
From: Petr Oros @ 2026-07-08 12:57 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alice Michael, Jacob Keller, Ivan Vecera, Simon Horman,
Martyna Szapar-Mudlaw, Marcin Szycik, intel-wired-lan,
linux-kernel
Two fixes for the uplink default VSI Rx rule (DFLT) on E810 when the
netdev is in IFF_PROMISC.
Patch 1 drops the redundant per-VLAN promisc expansion that exhausts
the FLU pool on a wide VLAN trunk across several PFs.
Patch 2 keeps the DFLT Rx rule across a switchdev teardown instead of
clobbering the promisc state the operator asked for.
Changes since v3 (review comments from Marcin Szycik):
- Patch 1: reworded the ice_clear_promisc() and the per-VID cleanup
comments, and flipped the ice_vsi_clear_vlan_mc_promisc() guard to an
early return (noting the clear is best-effort). No functional change.
- Patch 2: no change, added Marcin's and Aleksandr's Reviewed-by.
Link to v3:
https://lore.kernel.org/all/20260701133601.2118382-1-poros@redhat.com/
Link to v2:
https://lore.kernel.org/all/20260622113428.2565255-1-poros@redhat.com/
Link to v1:
https://lore.kernel.org/all/cover.1781786935.git.poros@redhat.com/
Petr Oros (2):
ice: skip per-VLAN promisc rules when default VSI Rx rule is set
ice: preserve uplink DFLT Rx rule on switchdev release
drivers/net/ethernet/intel/ice/ice_eswitch.c | 18 ++-
drivers/net/ethernet/intel/ice/ice_main.c | 109 +++++++++++++++----
2 files changed, 102 insertions(+), 25 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH iwl-net v4 1/2] ice: skip per-VLAN promisc rules when default VSI Rx rule is set
From: Petr Oros @ 2026-07-08 12:57 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alice Michael, Jacob Keller, Ivan Vecera, Simon Horman,
Martyna Szapar-Mudlaw, Marcin Szycik, intel-wired-lan,
linux-kernel
In-Reply-To: <20260708125755.706263-1-poros@redhat.com>
When an ice port in a vlan-filtering bridge goes promiscuous (typical for
bond slaves), the driver installs a per-VLAN ICE_SW_LKUP_PROMISC_VLAN rule
for every VID on top of the broad ICE_SW_LKUP_DFLT VSI Rx rule. Each rule
consumes one of the ~32K Flow Lookup Unit (FLU) entries the device shares
across PFs, so a wide trunk (vid 2-4094) over several PFs overruns the
pool: firmware rejects further Add Switch Rules with ENOSPC (AQ 0x10) and
the DFLT Rx rule itself fails to install:
ice 0000:5c:00.1: Failed to set VSI 14 as the default forwarding
VSI, error -5
ice 0000:5c:00.1 ens1f1: Error -5 setting default VSI 14 Rx rule
Once a switch context is overrun the retries can also come back as ENOENT
(AQ 0x2), which has misled triage toward a perceived recipe binding defect
rather than a capacity issue.
The DFLT rule already catches every packet on the port regardless of VLAN
tag, so the per-VLAN promisc expansion is redundant while it is installed.
Skip it at the two sites that drive it, ice_set_promisc() and
ice_vlan_rx_add_vid(), keyed on ice_is_vsi_dflt_vsi() rather than the
netdev IFF_PROMISC flag so a failed or LAG-suppressed DFLT install still
falls back to the per-VLAN rules.
IFF_ALLMULTI and IFF_PROMISC can reach ice_vsi_sync_fltr() in separate
passes (a bridge join sets them through separate calls), so the allmulti
pass may expand the per-VID rules before the DFLT rule exists. Drop those
now-redundant rules right after ice_set_dflt_vsi() installs the DFLT rule;
ice_vsi_exit_dflt_promisc() reinstates them when promisc is cleared.
ice_vsi_sync_fltr() subscribed multicast promiscuity only inside the
"default VSI not yet in use" branch, so a promiscuous VSI that finds the
default VSI rule already present (owned by another VSI, or preserved
across a switchdev session) ended up in unicast promisc with no multicast
subscription. Issue ice_set_promisc(ICE_MCAST_PROMISC_BITS) whenever the
netdev is promiscuous; it is idempotent and returns 0 if the rule is
already present.
Fixes: 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling")
Signed-off-by: Petr Oros <poros@redhat.com>
---
v4 (review comments from Marcin Szycik):
- Reworded the ice_clear_promisc() and the per-VID cleanup comments.
- Flipped the ice_vsi_clear_vlan_mc_promisc() guard to an early return to
reduce indentation, and noted that the clear is best-effort.
No functional change.
v3: https://lore.kernel.org/all/20260701133601.2118382-2-poros@redhat.com/
v2: https://lore.kernel.org/all/20260622113428.2565255-2-poros@redhat.com/
v1: https://lore.kernel.org/all/89efbea9831175e6f57e9fe8557f7a0e48e050b7.1781786935.git.poros@redhat.com/
---
drivers/net/ethernet/intel/ice/ice_main.c | 109 +++++++++++++++++-----
1 file changed, 88 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index b43d420ece99ca..f1fef26eeadac9 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -274,7 +274,8 @@ static int ice_set_promisc(struct ice_vsi *vsi, u8 promisc_m)
if (vsi->type != ICE_VSI_PF)
return 0;
- if (ice_vsi_has_non_zero_vlans(vsi)) {
+ /* skip per-VID expansion; the DFLT Rx rule already covers every VID */
+ if (ice_vsi_has_non_zero_vlans(vsi) && !ice_is_vsi_dflt_vsi(vsi)) {
promisc_m |= (ICE_PROMISC_VLAN_RX | ICE_PROMISC_VLAN_TX);
status = ice_fltr_set_vlan_vsi_promisc(&vsi->back->hw, vsi,
promisc_m);
@@ -304,9 +305,20 @@ static int ice_clear_promisc(struct ice_vsi *vsi, u8 promisc_m)
return 0;
if (ice_vsi_has_non_zero_vlans(vsi)) {
- promisc_m |= (ICE_PROMISC_VLAN_RX | ICE_PROMISC_VLAN_TX);
+ u8 vlan_promisc_m = promisc_m | ICE_PROMISC_VLAN_RX |
+ ICE_PROMISC_VLAN_TX;
+ int vid0_status;
+
+ /* the vid=0 rule may be in either recipe (the recipe used to
+ * set it is not recorded), so clear both; clearing an absent
+ * rule returns 0
+ */
status = ice_fltr_clear_vlan_vsi_promisc(&vsi->back->hw, vsi,
- promisc_m);
+ vlan_promisc_m);
+ vid0_status = ice_fltr_clear_vsi_promisc(&vsi->back->hw,
+ vsi->idx, promisc_m, 0);
+ if (!status)
+ status = vid0_status;
} else {
status = ice_fltr_clear_vsi_promisc(&vsi->back->hw, vsi->idx,
promisc_m, 0);
@@ -317,6 +329,61 @@ static int ice_clear_promisc(struct ice_vsi *vsi, u8 promisc_m)
return status;
}
+/**
+ * ice_vsi_exit_dflt_promisc - drop the default VSI Rx rule on promisc off
+ * @vsi: the VSI leaving promiscuous mode
+ *
+ * For an IFF_ALLMULTI VSI with VLANs the per-VID multicast rules are
+ * reinstated before the default rule is cleared so coverage never lapses;
+ * the then redundant vid=0 rule is dropped best-effort. The callees log
+ * their own failures, so error returns are not re-logged here.
+ *
+ * Return: 0 on success, negative on error with the default rule left in place.
+ */
+static int ice_vsi_exit_dflt_promisc(struct ice_vsi *vsi)
+{
+ struct ice_vsi_vlan_ops *vlan_ops = ice_get_compat_vsi_vlan_ops(vsi);
+ struct net_device *netdev = vsi->netdev;
+ struct ice_hw *hw = &vsi->back->hw;
+ bool restore_mc;
+ int err;
+
+ restore_mc = (vsi->current_netdev_flags & IFF_ALLMULTI) &&
+ ice_vsi_has_non_zero_vlans(vsi);
+
+ if (restore_mc) {
+ err = ice_fltr_set_vlan_vsi_promisc(hw, vsi,
+ ICE_MCAST_VLAN_PROMISC_BITS);
+ if (err && err != -EEXIST)
+ return err;
+ }
+
+ err = ice_clear_dflt_vsi(vsi);
+ if (err)
+ return err;
+
+ if (netdev->features & NETIF_F_HW_VLAN_CTAG_FILTER)
+ vlan_ops->ena_rx_filtering(vsi);
+
+ if (restore_mc)
+ ice_fltr_clear_vsi_promisc(hw, vsi->idx, ICE_MCAST_PROMISC_BITS,
+ 0);
+
+ return 0;
+}
+
+/* Drop the per-VID multicast promisc rules made redundant by the default
+ * VSI Rx rule; best-effort, a leftover is harmless while that rule stands.
+ */
+static void ice_vsi_clear_vlan_mc_promisc(struct ice_vsi *vsi)
+{
+ if (!ice_vsi_has_non_zero_vlans(vsi))
+ return;
+
+ ice_fltr_clear_vlan_vsi_promisc(&vsi->back->hw, vsi,
+ ICE_MCAST_VLAN_PROMISC_BITS);
+}
+
/**
* ice_vsi_sync_fltr - Update the VSI filter list to the HW
* @vsi: ptr to the VSI
@@ -429,30 +496,31 @@ static int ice_vsi_sync_fltr(struct ice_vsi *vsi)
err = 0;
vlan_ops->dis_rx_filtering(vsi);
- /* promiscuous mode implies allmulticast so
- * that VSIs that are in promiscuous mode are
- * subscribed to multicast packets coming to
- * the port
+ /* a prior allmulti pass may have added per-VID
+ * rules now covered by the DFLT rule
*/
- err = ice_set_promisc(vsi,
- ICE_MCAST_PROMISC_BITS);
- if (err)
- goto out_promisc;
+ ice_vsi_clear_vlan_mc_promisc(vsi);
}
+
+ /* Promiscuous mode implies allmulticast. Subscribe
+ * the VSI to all multicast even when the default VSI
+ * rule is already in use and the block above is
+ * skipped (it may be owned by another VSI, or
+ * preserved across a switchdev session); the unicast
+ * catch-all does not cover the multicast subscription.
+ */
+ err = ice_set_promisc(vsi, ICE_MCAST_PROMISC_BITS);
+ if (err)
+ goto out_promisc;
} else {
/* Clear Rx filter to remove traffic from wire */
if (ice_is_vsi_dflt_vsi(vsi)) {
- err = ice_clear_dflt_vsi(vsi);
+ err = ice_vsi_exit_dflt_promisc(vsi);
if (err) {
- netdev_err(netdev, "Error %d clearing default VSI %i Rx rule\n",
- err, vsi->vsi_num);
vsi->current_netdev_flags |=
IFF_PROMISC;
goto out_promisc;
}
- if (vsi->netdev->features &
- NETIF_F_HW_VLAN_CTAG_FILTER)
- vlan_ops->ena_rx_filtering(vsi);
}
/* disable allmulti here, but only if allmulti is not
@@ -3676,10 +3744,9 @@ int ice_vlan_rx_add_vid(struct net_device *netdev, __be16 proto, u16 vid)
while (test_and_set_bit(ICE_CFG_BUSY, vsi->state))
usleep_range(1000, 2000);
- /* Add multicast promisc rule for the VLAN ID to be added if
- * all-multicast is currently enabled.
- */
- if (vsi->current_netdev_flags & IFF_ALLMULTI) {
+ /* skip the per-VID rule when the DFLT Rx rule already covers this VID */
+ if ((vsi->current_netdev_flags & IFF_ALLMULTI) &&
+ !ice_is_vsi_dflt_vsi(vsi)) {
ret = ice_fltr_set_vsi_promisc(&vsi->back->hw, vsi->idx,
ICE_MCAST_VLAN_PROMISC_BITS,
vid);
--
2.54.0
^ permalink raw reply related
* [PATCH iwl-net v4 2/2] ice: preserve uplink DFLT Rx rule on switchdev release
From: Petr Oros @ 2026-07-08 12:57 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Marcin Szycik, Aleksandr Loktionov, Tony Nguyen,
Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alice Michael, Jacob Keller,
Ivan Vecera, Simon Horman, Martyna Szapar-Mudlaw, intel-wired-lan,
linux-kernel
In-Reply-To: <20260708125755.706263-1-poros@redhat.com>
When the uplink PF is promiscuous, ice_vsi_sync_fltr() installs an
ICE_SW_LKUP_DFLT catch-all Rx rule on the uplink VSI. Entering switchdev
re-affirms it through the idempotent ice_set_dflt_vsi(), but
ice_eswitch_release_env() removed both the Rx and Tx DFLT rules
unconditionally on teardown. That clobbered a promisc-owned Rx rule: it
disappeared while IFF_PROMISC was still set and the sync path was not
retriggered, leaving the uplink without the catch-all the netdev
requested.
Skip the Rx DFLT removal when the uplink is promiscuous, both in
ice_eswitch_release_env() and the err_def_tx unwind of
ice_eswitch_setup_env(); the Tx leg, owned by switchdev, is still removed.
Test the live netdev->flags, the same value ena_rx_filtering() ->
ice_cfg_vlan_pruning() above already keys on, so the preserved rule and
the pruning state stay consistent, including for a promisc change made
while switchdev ran (which never reached the gated filter sync).
Fixes: 5c07be96d8b3 ("ice: Avoid setting default Rx VSI twice in switchdev setup")
Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Petr Oros <poros@redhat.com>
---
v4:
- No code change, added Marcin's and Aleksandr's Reviewed-by.
v3: https://lore.kernel.org/all/20260701133601.2118382-3-poros@redhat.com/
v2: https://lore.kernel.org/all/20260622113428.2565255-3-poros@redhat.com/
v1: https://lore.kernel.org/all/deef5756e534ef06c12d910c5305d3fd205d30a0.1781786935.git.poros@redhat.com/
---
drivers/net/ethernet/intel/ice/ice_eswitch.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c b/drivers/net/ethernet/intel/ice/ice_eswitch.c
index c30e27bbfe6e25..07e2016fb9481f 100644
--- a/drivers/net/ethernet/intel/ice/ice_eswitch.c
+++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c
@@ -66,8 +66,10 @@ static int ice_eswitch_setup_env(struct ice_pf *pf)
ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx, false,
ICE_FLTR_TX);
err_def_tx:
- ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx, false,
- ICE_FLTR_RX);
+ /* keep the Rx DFLT rule if the uplink is promiscuous (see release_env) */
+ if (!(uplink_vsi->netdev->flags & IFF_PROMISC))
+ ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx,
+ false, ICE_FLTR_RX);
err_def_rx:
ice_vsi_del_vlan_zero(uplink_vsi);
err_vlan_zero:
@@ -276,8 +278,16 @@ static void ice_eswitch_release_env(struct ice_pf *pf)
vlan_ops->ena_rx_filtering(uplink_vsi);
ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx, false,
ICE_FLTR_TX);
- ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx, false,
- ICE_FLTR_RX);
+
+ /* Keep the Rx DFLT rule if the uplink is promiscuous; it must outlive
+ * the session. Test the live netdev->flags, the same value
+ * ena_rx_filtering() -> ice_cfg_vlan_pruning() above keys its decision
+ * on, so the preserved DFLT rule and the pruning state stay consistent.
+ */
+ if (!(uplink_vsi->netdev->flags & IFF_PROMISC))
+ ice_cfg_dflt_vsi(uplink_vsi->port_info, uplink_vsi->idx,
+ false, ICE_FLTR_RX);
+
ice_fltr_add_mac_and_broadcast(uplink_vsi,
uplink_vsi->port_info->mac.perm_addr,
ICE_FWD_TO_VSI);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Fix potential use-after-free in airoha_ppe_deinit()
From: Lorenzo Bianconi @ 2026-07-08 13:03 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178351022574.97989.6880403520276841703@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
> airoha_ppe_deinit() replaces the NPU pointer with NULL via
> rcu_replace_pointer() but does not wait for existing RCU readers
> to exit before calling ppe_deinit() and airoha_npu_put(). This can
> cause a use-after-free if a reader in an RCU read-side critical
> section still holds a reference to the NPU when it is freed.
>
> The init path (airoha_ppe_init) already calls synchronize_rcu()
> after rcu_assign_pointer(), but the deinit path introduced in
> commit 6abcf751bc08 ("net: airoha: Fix schedule while atomic in
> airoha_ppe_deinit()") omitted the matching barrier when switching
> from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer().
>
> Add synchronize_rcu() before ppe_deinit() to ensure all existing
> RCU readers have completed before the NPU resources are released.
>
> Fixes: 6abcf751bc084804a9e5b3051442e8a2ce67f48a ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_ppe.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index e7c78293002a..f6396925722d 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -1659,6 +1659,7 @@ void airoha_ppe_deinit(struct airoha_eth *eth)
> npu = rcu_replace_pointer(eth->npu, NULL,
> lockdep_is_held(&flow_offload_mutex));
> if (npu) {
> + synchronize_rcu();
> npu->ops.ppe_deinit(npu);
> airoha_npu_put(npu);
> }
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: Add soft reset for 88E1510
From: Andrew Lunn @ 2026-07-08 13:04 UTC (permalink / raw)
To: Ben Brown
Cc: hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Chris Packham
In-Reply-To: <c77dd281-9ae2-4634-a670-bd6c70afb3df@alliedtelesis.co.nz>
> > Lets take a step back.
> >
> > What sort of reset are we talking about? Software or hardware?
> >
> > Andrew
>
> It is doing a hardware reset using a GPIO line.
>
> When linked down the phy gets put into reset using a hardware GPIO line,
> during link up the phy initializes the hardware using phy_init_hw(),
> which de-asserts that reset GPIO. Then trivial setup is done before
> the driver specific config_init().
>
> When we are doing the marvell m88e1510_config_init() the first page
> write is not applying so it ends up writing configuration to the wrong
> registers. When testing fixes adding a 15us sleep before changing the
> page also meant the page was updated correctly.
reset-gpios:
maxItems: 1
description:
The GPIO phandle and specifier for the PHY reset signal.
reset-assert-us:
description:
Delay after the reset was asserted in microseconds. If this
property is missing the delay will be skipped.
reset-deassert-us:
description:
Delay after the reset was deasserted in microseconds. If
this property is missing the delay will be skipped.
What delays are you using?
Andrew
^ permalink raw reply
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Petr Pavlu @ 2026-07-08 13:04 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Qingfang Deng, Breno Leitao, Norbert Szetei, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Taegu Ha, Kees Cook, linux-ppp, linux-kernel, Guillaume Nault,
netdev, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, linux-modules, Paul E. McKenney
In-Reply-To: <20260708074904.xnpi0mlh@linutronix.de>
On 7/8/26 9:49 AM, Sebastian Andrzej Siewior wrote:
> On 2026-07-07 17:32:10 [+0200], Petr Pavlu wrote:
>>> --- a/kernel/module/main.c
>>> +++ b/kernel/module/main.c
>>> @@ -858,6 +858,9 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
>>> goto out;
>>>
>>> mutex_unlock(&module_mutex);
>>> +
>>> + /* Ensure all rcu callbacks issued by the module have completed */
>>> + rcu_barrier();
>>> /* Final destruction now no one is using it. */
>>> if (mod->exit != NULL)
>>> mod->exit();
>>>
>>> make sense?
>>
>> This is discussed in Documentation/RCU/rcubarrier.rst and
>> Documentation/RCU/Design/Requirements/Requirements.rst. The latter
>> contains:
>
> I am aware of this. It is just not the first time I stumble about this.
> But maybe with the AI review these days there won't be a miss.
>
>> I don't know if the last part about unacceptable latencies is still
>> relevant. I haven't done any measurements myself.
>
> There is a synchronize_rcu() later on. I think I could replace it with a
> call_rcu() so we might end up even. I was thinking about about it last
> time I was touching modules but somehow I stopped where I stopped.
> The question is just, is it worth doing it or is it reasonable to expect
> that it is done correctly.
As RCU usage in modules is now more common, I see an argument for the
module loader to invoke rcu_barrier() during module unload to make RCU
usage easier. In general, module unloading is a rare operation, so even
if it becomes somewhat slower, I don't expect it to be a significant
issue.
One problem is that I'm not sure where the new rcu_barrier() call should
be placed. The prototype adds it before calling the module's exit
function. Would this actually fit all modules? From a quick look, I can
see that various modules call it at different points during their exit.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH net] nfc: nci: fix out-of-bounds read in activation parameter parsing
From: Simon Horman @ 2026-07-08 13:07 UTC (permalink / raw)
To: Muhammad Bilal
Cc: David Heidelberg, netdev, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, oe-linux-nfc, linux-kernel
In-Reply-To: <20260628210026.129941-1-meatuni001@gmail.com>
On Mon, Jun 29, 2026 at 02:00:26AM +0500, Muhammad Bilal wrote:
> nci_extract_activation_params_iso_dep() and
> nci_extract_activation_params_nfc_dep() receive a pointer into the
> RF_INTF_ACTIVATED_NTF notification but are not told how many bytes
> remain. Each reads a one-byte length field (rats_res_len,
> attrib_res_len, atr_res_len or atr_req_len) and then memcpy()s that many
> bytes from the packet. The length is clamped to the destination size,
> but it is never checked against the remaining activation-parameter data,
> so a notification whose length field is larger than the data present
> reads past the end of the buffer.
>
> The sibling nci_extract_rf_params_*() helpers were recently given a
> data_len argument and matching remaining-length checks, but the
> activation-parameter helpers were not updated.
>
> Pass the remaining length down and validate each field against it before
> copying, as the rf_params helpers do.
>
> Fixes: ac2068384034 ("NFC: Parse NCI NFC-DEP activation params")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
FTR, there is an AI-=generated review of this patch on sashiko.dev.
However, I think that the issues raised there can be treated
as possible follow-up rather than impeding the progress of this patch.
^ permalink raw reply
* [PATCH net] cxgb4: consider EtherType when validating filter priority ordering
From: Harshita V Rajput @ 2026-07-08 13:16 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, edumazet, pabeni, andrew+netdev, bharat,
harshitha.vr
cxgb4_filter_prio_in_range() currently validates the priority
ordering of adjacent filters based only on tc_prio. This can
incorrectly reject insertion of a new filter when an existing
filter with a higher priority matches a different EtherType.
For example:
- An LLDP filter (pref 4) blocks IPv4 (pref 2) and IPv6 (pref 3)
filters from being added.
- An IPv6 filter (pref 3) blocks an IPv4 (pref 2) filter from being
added.
In both cases the filters match different EtherTypes, so they could
never have matched the same packet anyway.
Fix this by considering both tc_prio and the matched EtherType. A
neighbouring filter only blocks the new filter if it has no specific
EtherType set, or its EtherType is the same as the new filter's.
Filters with different EtherTypes are now allowed regardless of
priority order. Filters with the same EtherType still follow the
original strict priority check, since they really can overlap.
Fixes: 41ec03e534ca ("cxgb4: check rule prio conflicts before offload")
Signed-off-by: Harshita V Rajput <harshitha.vr@chelsio.com>
Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
---
.../net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 19 ++++++++++++++-----
.../ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 4 ++--
.../chelsio/cxgb4/cxgb4_tc_matchall.c | 2 +-
.../net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 2 +-
.../net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 2 +-
5 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index 657d96b9e2f6..8462455d9330 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -443,7 +443,7 @@ int cxgb4_get_filter_counters(struct net_device *dev, unsigned int fidx,
}
static bool cxgb4_filter_prio_in_range(struct tid_info *t, u32 idx, u8 nslots,
- u32 prio)
+ u32 prio, u32 ethtype)
{
struct filter_entry *prev_tab, *next_tab, *prev_fe, *next_fe;
u32 prev_ftid, next_ftid;
@@ -536,15 +536,24 @@ static bool cxgb4_filter_prio_in_range(struct tid_info *t, u32 idx, u8 nslots,
if (!prev_fe->fs.type)
prev_fe = &prev_tab[prev_ftid];
- if ((prev_fe->valid && prev_fe->fs.tc_prio > prio) ||
- (next_fe->valid && next_fe->fs.tc_prio < prio))
+ /* Filters with different EtherTypes can never match the same
+ * packet, so skip the priority check between them.
+ */
+ if (prev_fe->valid && prev_fe->fs.tc_prio > prio &&
+ (!prev_fe->fs.mask.ethtype || !ethtype ||
+ prev_fe->fs.val.ethtype == ethtype))
+ return false;
+
+ if (next_fe->valid && next_fe->fs.tc_prio < prio &&
+ (!next_fe->fs.mask.ethtype || !ethtype ||
+ next_fe->fs.val.ethtype == ethtype))
return false;
return true;
}
int cxgb4_get_free_ftid(struct net_device *dev, u8 family, bool hash_en,
- u32 tc_prio)
+ u32 tc_prio, u32 ethtype)
{
struct adapter *adap = netdev2adap(dev);
struct tid_info *t = &adap->tids;
@@ -671,7 +680,7 @@ int cxgb4_get_free_ftid(struct net_device *dev, u8 family, bool hash_en,
* with existing rules.
*/
if (cxgb4_filter_prio_in_range(t, ftid, n,
- tc_prio)) {
+ tc_prio, ethtype)) {
ftid &= ~(n - 1);
found = true;
break;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
index 41a2998ee2a0..754d9f5f0fe0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
@@ -911,8 +911,8 @@ int cxgb4_flow_rule_replace(struct net_device *dev, struct flow_rule *rule,
* rule. Only insert rule if its prio doesn't conflict with
* existing rules.
*/
- fidx = cxgb4_get_free_ftid(dev, inet_family, fs->hash,
- tc_prio);
+ fidx = cxgb4_get_free_ftid(dev, inet_family, fs->hash, tc_prio,
+ fs->mask.ethtype ? fs->val.ethtype : 0);
if (fidx < 0) {
NL_SET_ERR_MSG_MOD(extack,
"No free LETCAM index available");
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c
index bc290430245e..bab263785082 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c
@@ -312,7 +312,7 @@ static int cxgb4_matchall_add_filter(struct net_device *dev,
* existing rules.
*/
fidx = cxgb4_get_free_ftid(dev, filter_type ? PF_INET6 : PF_INET,
- false, cls->common.prio);
+ false, cls->common.prio, 0);
if (fidx < 0) {
NL_SET_ERR_MSG_MOD(extack,
"No free LETCAM index available");
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
index 1c1a7bc5a896..37a878f07f91 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
@@ -174,7 +174,7 @@ int cxgb4_config_knode(struct net_device *dev, struct tc_cls_u32_offload *cls)
* existing rules.
*/
filter_id = cxgb4_get_free_ftid(dev, inet_family, false,
- TC_U32_NODE(cls->knode.handle));
+ TC_U32_NODE(cls->knode.handle), 0);
if (filter_id < 0) {
NL_SET_ERR_MSG_MOD(extack,
"No free LETCAM index available");
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
index d7713038386c..42efc239df88 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
@@ -282,7 +282,7 @@ struct chcr_ktls {
struct ch_filter_specification;
int cxgb4_get_free_ftid(struct net_device *dev, u8 family, bool hash_en,
- u32 tc_prio);
+ u32 tc_prio, u32 ethtype);
int __cxgb4_set_filter(struct net_device *dev, int filter_id,
struct ch_filter_specification *fs,
struct filter_ctx *ctx);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] mlxsw: Make the driver ops-locked
From: Eric Dumazet @ 2026-07-08 13:24 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, kuba, pabeni, petrm, andrew+netdev
In-Reply-To: <20260708123933.1303291-1-idosch@nvidia.com>
On Wed, Jul 8, 2026 at 2:41 PM Ido Schimmel <idosch@nvidia.com> wrote:
>
> Make the driver ops-locked in order to allow ethtool operations to be
> invoked without RTNL being held.
>
> An ops-locked driver has most of its NDOs, all of its ethtool operations
> and some net device notifications run with the netdev instance lock
> held.
>
> In the specific case of mlxsw, the driver is not using any functions
> that acquire this lock nor functions that expect the lock to be held for
> an ops-locked driver. Therefore, converting its NDOs to run with the
> lock being held is trivial except for a small quirk which is handled in
> patch #1.
>
> The driver does not generate any net device notifications, so there is
> no risk of nested notifications of the ops-locked types. For the
> notifications that run under the instance lock, RTNL is also held, and
> the driver does not acquire the instance lock itself, so no changes are
> required in its notifier handling.
>
> Ethtool operations can be invoked without RTNL except for two operations
> that are annotated in patch #2.
>
> Lastly, patch #3 converts the driver to be ops-locked.
>
> A probe on rtnl_lock() shows it is no longer taken when dumping
> statistics:
>
> # perf probe --add rtnl_lock
>
> Before:
>
> # perf stat -e probe:rtnl_lock -- ethtool -S swp1 --all-groups
> [...]
> 1 probe:rtnl_lock
>
> After:
>
> # perf stat -e probe:rtnl_lock -- ethtool -S swp1 --all-groups
> [...]
> 0 probe:rtnl_lock
>
We probably want to add noinline_for_tracing to rtnl_lock() and friends...
^ permalink raw reply
* Re: [PATCH net-next v3] net: skb: isolate skb data area allocations into a separate bucket
From: Harry Yoo @ 2026-07-08 13:27 UTC (permalink / raw)
To: Pedro Falcato, Paolo Abeni
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Jason Xing, Kuniyuki Iwashima, netdev, linux-kernel,
linux-hardening, Kees Cook, linux-mm, Vlastimil Babka
In-Reply-To: <ak4w2k4Woj55E0On@pedro-suse>
On 7/8/26 8:16 PM, Pedro Falcato wrote:
> On Wed, Jul 08, 2026 at 10:30:50AM +0200, Paolo Abeni wrote:
>> On 7/2/26 7:07 PM, Pedro Falcato wrote:> @@ -586,6 +586,8 @@ struct
>> sk_buff *napi_build_skb(void *data, unsigned int frag_size)
>>> }
>>> EXPORT_SYMBOL(napi_build_skb);
>>>
>>> +static kmem_buckets *skb_data_buckets __ro_after_init;
>>> +
>>> static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
>>> {
>>> if (!gfp_pfmemalloc_allowed(flags))
>>> @@ -593,7 +595,8 @@ static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
>>> if (!obj_size)
>>> return kmem_cache_alloc_node(net_hotdata.skb_small_head_cache,
>>> flags, node);
>>> - return kmalloc_node_track_caller(obj_size, flags, node);
>>> + return kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
>>> + flags, node);
>>
>> Sashiko noted that some drivers may require GFP_DMA buckets, and the
>> above may break them:
>>
>> https://sashiko.dev/#/patchset/20260702170728.168755-1-pfalcato%40suse.de
>
> Oh, this is really awkward. Adding linux-mm and slab maintainers for input here.
>
> Considering the current slab bucketing does not seem to duplicate DMA or
> CGROUP caches, could it make sense to duplicate those as well?
Could we specify what kmalloc types the user needs when creating
kmem_buckets and duplicate caches for the requested kmalloc types only?
> Otherwise we could add a branch like:
>
> if (gfp_flags & __GFP_DMA)
> /* use the global dma kmalloc caches */
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
* Re: [PATCH bpf-next 1/1] selftests: drv-net: add XDP RX checksum metadata tests
From: bot+bpf-ci @ 2026-07-08 13:28 UTC (permalink / raw)
To: deliran, lorenzo
Cc: sdf, kuba, andrii, ast, daniel, hawk, john.fastabend, martin.lau,
sdf.kernel, bpf, netdev, deliran, ast, andrii, daniel, martin.lau,
eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <6c7a059057d309e999b706b5b547be9c620ce544.1783514455.git.deliran@verdict.gg>
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
> diff --git a/tools/testing/selftests/drivers/net/hw/xdp_metadata.py b/tools/testing/selftests/drivers/net/hw/xdp_metadata.py
> index 33a1985356d9..687c43a1797a 100644
> --- a/tools/testing/selftests/drivers/net/hw/xdp_metadata.py
> +++ b/tools/testing/selftests/drivers/net/hw/xdp_metadata.py
[ ... ]
> @@ -81,8 +83,22 @@ _RSS_KEY_TYPE = 1
> _RSS_KEY_PKT_CNT = 2
> _RSS_KEY_ERR_CNT = 3
>
> +_CSUM_KEY_IP_SUMMED = 0
> +_CSUM_KEY_CKSUM = 1
> +_CSUM_KEY_LEVEL = 2
> +_CSUM_KEY_PKT_CNT = 3
> +_CSUM_KEY_ERR_CNT = 4
> +
> XDP_RSS_L4 = 0x8 # BIT(3) from enum xdp_rss_hash_type
>
> +# Mirror of enum xdp_checksum from include/net/xdp.h
> +XDP_CHECKSUM_NONE = 0x1
> +XDP_CHECKSUM_UNNECESSARY = 0x2
> +XDP_CHECKSUM_COMPLETE = 0x4
This isn't a bug, but XDP_CHECKSUM_NONE does not seem to be used anywhere
in the test; was it intended to mirror the full enum for documentation, or
could it be dropped to match the nearby XDP_RSS_L4 which defines only the
bit it uses?
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28945032378
^ permalink raw reply
* Re: [PATCH net v3] nfc: nci: Fix conn_info use-after-free
From: Simon Horman @ 2026-07-08 13:28 UTC (permalink / raw)
To: sanghyun.park.cnu
Cc: Simon Horman, david+nfc, krzk, davem, edumazet, kuba, pabeni,
ian.ray, joe, kuniyu, kees, ashutoshdesai993, vadim.fedorenko,
deepak.sharma.472935, michael.thalmeier, christophe.ricard, sameo,
oe-linux-nfc, netdev, linux-kernel
In-Reply-To: <20260630071717.3618185-2-sanghyun.park.cnu@gmail.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://sashiko.dev
---
nfc: nci: Fix conn_info use-after-free
This commit fixes a use-after-free in nci_tx_work() by introducing a dedicated
spinlock (conn_info_lock) to protect the conn_info_list and conn_info aliases
during lookup, insertion, and removal.
> diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
> --- a/net/nfc/nci/core.c
> +++ b/net/nfc/nci/core.c
> @@ -1333,11 +1367,16 @@ void nci_unregister_device(struct nci_dev *ndev)
> destroy_workqueue(ndev->rx_wq);
> destroy_workqueue(ndev->tx_wq);
>
> + spin_lock_bh(&ndev->conn_info_lock);
> list_for_each_entry_safe(conn_info, n, &ndev->conn_info_list, list) {
> list_del(&conn_info->list);
> + if (conn_info == ndev->rf_conn_info)
> + ndev->rf_conn_info = NULL;
> + if (conn_info == ndev->hci_dev->conn_info)
> + ndev->hci_dev->conn_info = NULL;
[Severity: Critical]
Can this cause a NULL pointer dereference for devices without HCI support?
For NCI devices without HCI support (like nfcmrvl or s3fwrn5), ndev->hci_dev
is NULL. Because all NCI devices add at least the static RF connection to
conn_info_list during discovery, this loop will always execute.
Evaluating conn_info == ndev->hci_dev->conn_info will crash when
ndev->hci_dev is NULL.
Should this check ndev->hci_dev before accessing its conn_info field? The
same issue appears in nci_core_conn_close_rsp_packet() in net/nfc/nci/rsp.c.
> diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
> --- a/net/nfc/nci/data.c
> +++ b/net/nfc/nci/data.c
> @@ -171,40 +174,47 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
[ ... ]
> + spin_lock_bh(&ndev->conn_info_lock);
> ndev->cur_conn_id = conn_id;
> - queue_work(ndev->tx_wq, &ndev->tx_work);
[Severity: High]
This is a pre-existing issue, but does ndev->cur_conn_id suffer from
concurrent overwrites?
If a logical connection is being closed, nci_core_conn_close() sets
ndev->cur_conn_id and waits for the response.
If nci_send_data() is called concurrently, it overwrites ndev->cur_conn_id
without holding req_lock.
When the close response arrives, nci_core_conn_close_rsp_packet() will free
the conn_info for the actively transmitting connection instead of the closed
one. Does cur_conn_id need better protection or a different tracking
mechanism?
> @@ -282,11 +292,15 @@ void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb)
[ ... ]
> /* strip the nci data header */
> skb_pull(skb, NCI_DATA_HDR_SIZE);
[Severity: High]
This is a pre-existing issue, but can this lead to an out-of-bounds read
if the packet is empty?
If a target sends an empty packet (skb->len == 0), the skb_pull() just above
fails gracefully leaving skb->len at 0.
Then in nci_rx_data_packet(), the code accesses skb->data[skb->len - 1] to
read the status byte, reading out-of-bounds memory.
Does this need an skb->len > 0 check before accessing the status byte?
> diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
> --- a/net/nfc/nci/hci.c
> +++ b/net/nfc/nci/hci.c
> @@ -599,10 +632,20 @@ int nci_hci_set_param(struct nci_dev *ndev, u8 gate, u8 idx,
[ ... ]
> + message = (struct nci_hcp_message *)rx_skb->data;
> r = nci_hci_result_to_errno(
> NCI_HCP_MSG_GET_CMD(message->header));
> - skb_pull(conn_info->rx_skb, NCI_HCI_HCP_MESSAGE_HEADER_LEN);
> + skb_pull(rx_skb, NCI_HCI_HCP_MESSAGE_HEADER_LEN);
> + spin_unlock_bh(&ndev->conn_info_lock);
> }
[Severity: High]
This is a pre-existing issue, but does this leak the response skb?
After pulling the header to check the result, nci_hci_set_param() returns
without consuming the skb or calling kfree_skb().
The buffer remains in conn_info->rx_skb, and the next time an HCI response
is received, nci_hci_resp_received() unconditionally overwrites the pointer,
permanently leaking the memory.
Should the skb be freed if it's not being passed back to the caller?
> diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
> --- a/net/nfc/nci/rsp.c
> +++ b/net/nfc/nci/rsp.c
> @@ -298,20 +313,20 @@ static void nci_core_conn_create_rsp_packet(struct nci_dev *ndev,
> conn_info->dest_params->id = ndev->cur_params.id;
> conn_info->dest_params->protocol = ndev->cur_params.protocol;
> conn_info->conn_id = rsp->conn_id;
> + conn_info->max_pkt_payload_len = rsp->max_ctrl_pkt_payload_len;
> + atomic_set(&conn_info->credits_cnt, rsp->credits_cnt);
[Severity: High]
This is a pre-existing issue, but does this properly validate the length
of the response packet?
The skb->data is cast to struct nci_core_conn_create_rsp, but if the
hardware sends a truncated response (e.g., just the status byte), the code
blindly accesses the connection parameters and credit count from
uninitialized adjacent memory.
Does this need an skb->len check before parsing the structure?
^ permalink raw reply
* [PATCH] net: use sync wakeups for socket error reports
From: Usama Arif @ 2026-07-08 13:38 UTC (permalink / raw)
To: davem, edumazet, horms, kuba, kuniyu, linux-kernel, netdev,
pabeni, willemb, shakeel.butt, hannes, riel, kernel-team
Cc: Usama Arif
sock_def_readable() and sock_def_write_space() pass WF_SYNC to their
waitqueue wakeups, switch sock_def_error_report() to
wake_up_interruptible_sync_poll() so EPOLLERR waiters get the same hint.
ep_poll_callback() forwards it through to
try_to_wake_up() / select_task_rq_fair(), where wake_affine() can
prefer the waker CPU and skip a cross-CPU wakelist IPI when its
heuristics agree.
WF_SYNC matches the choice already made for readable/write_space. Some
error reports have the same producer/consumer shape: the waker has queued
an skb on sk->sk_error_queue, and the wakee is about to dequeue and copy
it out. Other reports publish sk_err/socket state directly, but still wake
a task likely to consume that socket state immediately.
Measured on a 176-core EPYC 9D64 host running a Meta production
workload, bpftrace on tracepoint:ipi:ipi_send_cpu with a kstack filter
attributed the sock_def_error_report -> ep_poll_callback ->
try_to_wake_up -> ttwu_queue_wakelist -> __smp_call_single_queue
chain to 16,326 IPIs/min. Switching to wake_up_interruptible_sync_poll()
will help reduce those IPIs.
Signed-off-by: Usama Arif <usama.arif@linux.dev>
---
net/core/sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 8a59bfaa8096..c724f1442987 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -3639,7 +3639,7 @@ static void sock_def_error_report(struct sock *sk)
rcu_read_lock();
wq = rcu_dereference(sk->sk_wq);
if (skwq_has_sleeper(wq))
- wake_up_interruptible_poll(&wq->wait, EPOLLERR);
+ wake_up_interruptible_sync_poll(&wq->wait, EPOLLERR);
sk_wake_async_rcu(sk, SOCK_WAKE_IO, POLL_ERR);
rcu_read_unlock();
}
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH iproute2-next v4] rdma: display resource limits in curr/max format
From: Tao Cui @ 2026-07-08 13:40 UTC (permalink / raw)
To: dsahern, leonro; +Cc: linux-rdma, netdev, cui.tao, cuitao
From: Tao Cui <cuitao@kylinos.cn>
Parse the new RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX netlink attribute
to show resource limits alongside current counts in curr/max format:
Before: 0: mlx5_0: qp 123 cq 45 mr 200 pd 10
After: 0: mlx5_0: qp 123/131072 cq 45/65536 mr 200/1000000 pd 10/32768
JSON output provides both current and max fields per resource type
(e.g. "qp": 123, "qp-max": 131072). Backward compatible: no output
change when kernel lacks the new attribute.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Link: https://lore.kernel.org/all/20260615003646.168704-1-cui.tao@linux.dev/
---
Changes in v4:
- Add Link to the kernel patch that introduces the new uapi attribute.
---
rdma/include/uapi/rdma/rdma_netlink.h | 5 +++++
rdma/res.c | 21 ++++++++++++++++++++-
rdma/utils.c | 1 +
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/rdma/include/uapi/rdma/rdma_netlink.h b/rdma/include/uapi/rdma/rdma_netlink.h
index 4356ec4a..e5b8b065 100644
--- a/rdma/include/uapi/rdma/rdma_netlink.h
+++ b/rdma/include/uapi/rdma/rdma_netlink.h
@@ -604,6 +604,11 @@ enum rdma_nldev_attr {
RDMA_NLDEV_ATTR_FRMR_POOL_PINNED_HANDLES, /* u32 */
RDMA_NLDEV_ATTR_FRMR_POOL_KEY_KERNEL_VENDOR_KEY, /* u64 */
+ /*
+ * Resource summary entry maximum value.
+ */
+ RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX, /* u64 */
+
/*
* Always the end
*/
diff --git a/rdma/res.c b/rdma/res.c
index 062f0007..046935e2 100644
--- a/rdma/res.c
+++ b/rdma/res.c
@@ -55,7 +55,26 @@ static int res_print_summary(struct nlattr **tb)
name = mnl_attr_get_str(nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_NAME]);
curr = mnl_attr_get_u64(nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR]);
- res_print_u64(name, curr, nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR]);
+ if (nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX]) {
+ uint64_t max;
+ char max_name[64];
+
+ max = mnl_attr_get_u64(
+ nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX]);
+ snprintf(max_name, sizeof(max_name), "%s-max", name);
+ print_u64(PRINT_JSON, name, NULL, curr);
+ print_u64(PRINT_JSON, max_name, NULL, max);
+ if (!is_json_context()) {
+ char buf[64];
+
+ snprintf(buf, sizeof(buf), "%s %" PRIu64 "/%" PRIu64 " ",
+ name, curr, max);
+ pr_out("%s", buf);
+ }
+ } else {
+ res_print_u64(name, curr,
+ nla_line[RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_CURR]);
+ }
}
return 0;
}
diff --git a/rdma/utils.c b/rdma/utils.c
index 87003b2c..90ea1c55 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -480,6 +480,7 @@ static const enum mnl_attr_data_type nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
[RDMA_NLDEV_ATTR_EVENT_TYPE] = MNL_TYPE_U8,
[RDMA_NLDEV_SYS_ATTR_MONITOR_MODE] = MNL_TYPE_U8,
[RDMA_NLDEV_ATTR_STAT_OPCOUNTER_ENABLED] = MNL_TYPE_U8,
+ [RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX] = MNL_TYPE_U64,
};
static int rd_attr_check(const struct nlattr *attr, int *typep)
--
2.43.0
^ permalink raw reply related
* [PATCH bpf v2 2/2] selftests/bpf: Test FIONREAD on a sockmap socket without a verdict program
From: Mattia Meleleo via B4 Relay @ 2026-07-08 13:40 UTC (permalink / raw)
To: bpf
Cc: netdev, John Fastabend, Jakub Sitnicki, Jiayuan Chen,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Mattia Meleleo
In-Reply-To: <20260708-fionread-no-verdict-v2-0-29dd293621c7@coralogix.com>
From: Mattia Meleleo <mattia.meleleo@coralogix.com>
Add a test validating that FIONREAD on a TCP socket in a sockmap
without a verdict program reports data pending in sk_receive_queue.
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com>
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
index cb3229711..f0f368201 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
@@ -1373,6 +1373,43 @@ static void test_sockmap_multi_channels(int sotype)
test_sockmap_pass_prog__destroy(skel);
}
+/* A socket in a sockmap without a verdict program keeps its ingress data
+ * in sk_receive_queue: FIONREAD must account for it.
+ */
+static void test_sockmap_no_verdict_fionread(void)
+{
+ int err, map, zero = 0, sent, avail;
+ int c0 = -1, c1 = -1, p0 = -1, p1 = -1;
+ struct test_sockmap_pass_prog *skel;
+ char buf[256] = "0123456789";
+
+ skel = test_sockmap_pass_prog__open_and_load();
+ if (!ASSERT_OK_PTR(skel, "open_and_load"))
+ return;
+ map = bpf_map__fd(skel->maps.sock_map_rx);
+
+ err = create_socket_pairs(AF_INET, SOCK_STREAM, &c0, &c1, &p0, &p1);
+ if (!ASSERT_OK(err, "create_socket_pairs()"))
+ goto out;
+
+ err = bpf_map_update_elem(map, &zero, &c1, BPF_NOEXIST);
+ if (!ASSERT_OK(err, "bpf_map_update_elem(c1)"))
+ goto out_close;
+
+ sent = xsend(p1, &buf, sizeof(buf), 0);
+ ASSERT_EQ(sent, sizeof(buf), "xsend(p1)");
+ avail = wait_for_fionread(c1, sizeof(buf), IO_TIMEOUT_SEC);
+ ASSERT_EQ(avail, sizeof(buf), "ioctl(FIONREAD)");
+
+out_close:
+ close(c0);
+ close(p0);
+ close(c1);
+ close(p1);
+out:
+ test_sockmap_pass_prog__destroy(skel);
+}
+
void test_sockmap_basic(void)
{
if (test__start_subtest("sockmap create_update_free"))
@@ -1415,6 +1452,8 @@ void test_sockmap_basic(void)
test_sockmap_skb_verdict_shutdown();
if (test__start_subtest("sockmap skb_verdict fionread"))
test_sockmap_skb_verdict_fionread(true);
+ if (test__start_subtest("sockmap no_verdict fionread"))
+ test_sockmap_no_verdict_fionread();
if (test__start_subtest("sockmap skb_verdict fionread on drop"))
test_sockmap_skb_verdict_fionread(false);
if (test__start_subtest("sockmap skb_verdict change tail"))
--
Git-155)
^ permalink raw reply related
* [PATCH bpf v2 0/2] bpf, sockmap: Fix FIONREAD for sockets without a verdict program
From: Mattia Meleleo via B4 Relay @ 2026-07-08 13:40 UTC (permalink / raw)
To: bpf
Cc: netdev, John Fastabend, Jakub Sitnicki, Jiayuan Chen,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Mattia Meleleo
Sockets added to a sockmap/sockhash with no stream/skb verdict program
attached answer FIONREAD with 0 even when unread data is pending in
sk_receive_queue. Fix tcp_bpf_ioctl() to account for the receive queue
in that case, and add a selftest.
Changes in v2:
- Split the fix and the selftest into separate patches
- Use READ_ONCE() to read the verdict program pointers
- Link to v1: https://patch.msgid.link/20260707-fionread-no-verdict-v1-1-ce94a72357ec@coralogix.com
Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com>
---
Mattia Meleleo (2):
bpf, sockmap: Account for receive queue in FIONREAD without a verdict program
selftests/bpf: Test FIONREAD on a sockmap socket without a verdict program
net/ipv4/tcp_bpf.c | 17 +++++++++-
.../selftests/bpf/prog_tests/sockmap_basic.c | 39 ++++++++++++++++++++++
2 files changed, 55 insertions(+), 1 deletion(-)
---
base-commit: d2c9a99135da931377240942d44f3dea104cedb8
change-id: 20260707-fionread-no-verdict-a4f8697ac9f9
Best regards,
--
Mattia Meleleo <mattia.meleleo@coralogix.com>
^ permalink raw reply
* [PATCH bpf v2 1/2] bpf, sockmap: Account for receive queue in FIONREAD without a verdict program
From: Mattia Meleleo via B4 Relay @ 2026-07-08 13:40 UTC (permalink / raw)
To: bpf
Cc: netdev, John Fastabend, Jakub Sitnicki, Jiayuan Chen,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Mattia Meleleo
In-Reply-To: <20260708-fionread-no-verdict-v2-0-29dd293621c7@coralogix.com>
From: Mattia Meleleo <mattia.meleleo@coralogix.com>
tcp_bpf_ioctl() answers SIOCINQ from psock->msg_tot_len, which only
counts bytes in ingress_msg. Without a stream/skb verdict program
nothing is diverted there: data stays in sk_receive_queue, so FIONREAD
returns 0 even though read() returns data.
Add tcp_inq() to the reported value when the psock has no verdict
program. The two queues are disjoint, so bytes redirected into
ingress_msg from other sockets stay correctly accounted through
msg_tot_len.
Fixes: 929e30f93125 ("bpf, sockmap: Fix FIONREAD for sockmap")
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com>
---
net/ipv4/tcp_bpf.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index cc0bd73f3..8e905b50d 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -334,6 +334,7 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
static int tcp_bpf_ioctl(struct sock *sk, int cmd, int *karg)
{
+ struct sk_psock *psock;
bool slow;
if (cmd != SIOCINQ)
@@ -344,7 +345,21 @@ static int tcp_bpf_ioctl(struct sock *sk, int cmd, int *karg)
return -EINVAL;
slow = lock_sock_fast(sk);
- *karg = sk_psock_msg_inq(sk);
+ psock = sk_psock_get(sk);
+ if (unlikely(!psock)) {
+ unlock_sock_fast(sk, slow);
+ return tcp_ioctl(sk, cmd, karg);
+ }
+ *karg = sk_psock_get_msg_len_nolock(psock);
+ /* Without a verdict program, ingress data is never diverted to
+ * ingress_msg: it stays in sk_receive_queue and is read through
+ * the fallback to tcp_recvmsg(), so account for it like
+ * tcp_ioctl() does.
+ */
+ if (!READ_ONCE(psock->progs.stream_verdict) &&
+ !READ_ONCE(psock->progs.skb_verdict))
+ *karg += tcp_inq(sk);
+ sk_psock_put(sk, psock);
unlock_sock_fast(sk, slow);
return 0;
--
Git-155)
^ permalink raw reply related
* Re: [PATCH 02/15] dt-bindings: clock: mediatek: regroup MT8188 dt-bindings into MT8186
From: Louis-Alexis Eyraud @ 2026-07-08 13:44 UTC (permalink / raw)
To: Rob Herring
Cc: Michael Turquette, Stephen Boyd, Brian Masney,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran, kernel, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260701193311.GA1402559-robh@kernel.org>
Hello Rob,
On Wed, 2026-07-01 at 14:33 -0500, Rob Herring wrote:
> On Wed, Jul 01, 2026 at 03:11:07PM +0200, Louis-Alexis Eyraud wrote:
> > Regroup the MT8188 clock and system clock dt-bindings into MT8186
> > ones
> > to ease maintainability and have common files for several currently
> > supported SoC or new future ones, that have the same kind of clock
> > controller design.
> >
> > Note:
> > The `#clock-cells` property is a required property for all
> > compatibles
> > declared in MT8188 clock and system clock dt-bindings but not in
> > MT8186
> > ones.
> > To avoid ABI breakage, conditional blocks to check this requirement
> > for MT8188 compatibles are added, rather than enforcing it for
> > MT8186
> > compatibles.
>
> If the existing DTs are just wrong, then I would just make #clock-
> cells
> required. But please update the .dts files so the warnings don't
> grow.
>
I've tested to make the #clock-cells required for the MT8186, MT8192
and MT8195 system and functional clock controllers.
I did not see new warnings, so no extra dts patches would be needed.
I'll add new patches (one per SoC) in the next revision of the series
for this, as it simplifies the grouping patches (no more if/then to
require #clock-cells for the MT8188/MT8189 clock controllers) and the
note in commit message could be removed.
> The grouping I would do here is:
>
> - clock controller only
> - reset controller only
> - both clock and reset controller
>
> That should avoid any if/then schemas.
>
By this grouping, I understand you suggest having separate dt-bindings
files, that could look like:
- mediatek,mt8186-clock.yaml: clock controllers
- <name to be found>: reset controllers
- <name to be found>: clock controllers with reset controller
- mediatek,mt8186-sys-clock.yaml: system clock controllers.
- <name to be found>: system clock controllers with reset controller
Is that what you meant?
There is no pure reset controllers for those SoC so no dedicated file
would needed at the moment.
The system clock controllers all have reset-controllers, even they may
currently be not all implemented, so no separate files for system clock
controllers would needed as well.
Also, from what I see the current dt-bindings, the system clocks
controllers for the MT8186/MT8188/MT8192/MT8195 SoC have the #reset-
cells property but it is not required for them (examples:
mediatek,mt8188-infracfg-ao or mediatek,mt8195-infracfg_ao).
With the patches to make the #clock-cells property required, I already
removed the biggest if/else block in mediatek,mt8186-clock.yaml, so
only the one regarding #reset-cells property remains.
So, should I create separate files, following the grouping suggestion,
for the v2 of this patch?
Regards,
Louis-Alexis
> Rob
^ permalink raw reply
* Re: [PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode
From: Andrew Lunn @ 2026-07-08 13:55 UTC (permalink / raw)
To: Markus Breitenberger
Cc: andrew+netdev, bre, davem, edumazet, kuba, netdev, pabeni, stable,
yong.liang.choong
In-Reply-To: <20260707220814.109028-1-bre@breiti.cc>
On Wed, Jul 08, 2026 at 12:08:14AM +0200, Markus Breitenberger wrote:
> Hi Andrew,
>
> Thanks for looking at this, and you're right - the runtime case is the
> more dangerous one. If a genuine interface change (SGMII <-> 2500BASE-X)
> happened at runtime while the disk was live, reprogramming the shared
> ModPHY LCPLL would disturb the SATA PHY under an active filesystem, and
> a failed boot would be preferable to that.
>
> Two points of clarification:
>
> - A plain switch change does not reprogram the ModPHY on my fixed-PHY
> setup. mac_finish() only runs a real reconfiguration when the
> MAC-side interface mode changes (e.g. a multi-rate SFP moving between
> SGMII and 2500BASE-X).
A fibre SFP is unlikely to use SGMII. It will swap between 2500BaseX
and 1000BaseX, if the SFP module is ejected and a different one
plugged in.
> On a fixed copper PHY the interface mode does
> not change, so changing the link partner / switch does not trigger
> the reconfiguration.
That depends on the PHY. Some change there host side interface to
match the line side. So they use 25000BaseX for 2.5G, but SGMII for
10/100/1G. Other use 'rate-adaptation'. They run the host side at the
fastest speed, 25000BaseX, and then insert pause frames to slow down
the MAC when the line side is running at 10/100/1G.
> Given that, I'd like to keep this patch scoped to the boot regression
> and leave the pre-existing shared-ModPHY-with-live-SATA question to the
> maintainers, who have the hardware knowledge to decide whether a
> stronger guard is warranted.
a42f6b3f1cc1 is from Intel, so i assume they thought about what
happens to the SATA controller, and are happy to take the risk of
destroying filesystems. So, yes, lets leave it as is for the moment.
Andrew
^ permalink raw reply
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Sebastian Andrzej Siewior @ 2026-07-08 13:56 UTC (permalink / raw)
To: Petr Pavlu
Cc: Qingfang Deng, Breno Leitao, Norbert Szetei, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Taegu Ha, Kees Cook, linux-ppp, linux-kernel, Guillaume Nault,
netdev, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, linux-modules, Paul E. McKenney
In-Reply-To: <bef05178-4856-4b62-9c3b-62bf636c239d@suse.com>
On 2026-07-08 15:04:32 [+0200], Petr Pavlu wrote:
> As RCU usage in modules is now more common, I see an argument for the
> module loader to invoke rcu_barrier() during module unload to make RCU
> usage easier. In general, module unloading is a rare operation, so even
> if it becomes somewhat slower, I don't expect it to be a significant
> issue.
Okay.
> One problem is that I'm not sure where the new rcu_barrier() call should
> be placed. The prototype adds it before calling the module's exit
> function. Would this actually fit all modules? From a quick look, I can
> see that various modules call it at different points during their exit.
I don't know why you would use call_rcu() in your module_exit()
(pointing to the same module). But you could have call_rcu() invoking
kmem_cache_free() and destroying that cache (kmem_cache_destroy()) in
your exit path. From that perspective it would make sense to flush all
calls before invoking module_exit().
> --
> Thanks,
> Petr
Sebastian
^ permalink raw reply
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Paul E. McKenney @ 2026-07-08 14:01 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Petr Pavlu, Qingfang Deng, Breno Leitao, Norbert Szetei,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Taegu Ha, Kees Cook, linux-ppp, linux-kernel,
Guillaume Nault, netdev, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, linux-modules
In-Reply-To: <20260708091147.O1d41Vi0@linutronix.de>
On Wed, Jul 08, 2026 at 11:11:47AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-07-07 09:39:01 [-0700], Paul E. McKenney wrote:
> > Alternatives include:
> >
> > o Provide a patch like that above, but only execute the
> > rcu_barrier() in some debug mode. If your code works when
> > that debug is enabled but does not otherwise, you add the
> > rcu_barrier().
> >
> > o If debug is enabled, make rcu_do_batch() check the function
> > before invoking it. If the function is not mapped, issue a
> > diagnostic, and don't try to invoke the function. (But is
> > there a sufficiently cheap way to check for the function not
> > being mapped?)
>
> In both cases you would see a backtrace and the name of the last
> unloaded module. And since we don't see a lot of these reports, people
> either don't run into this because it does not exist or RCU is quick
> enough.
Good point, the splat from calling the no-longer-mapped function should
call out the offending module. So maybe our debug code is good enough
already.
Thanx, Paul
^ permalink raw reply
* [PATCH net 00/17] netfilter: updates for net
From: Florian Westphal @ 2026-07-08 14:02 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
Hi,
The following patchset contains Netfilter fixes for *net*.
Most of these are LLM fixes for old issues flagged by sashiko/LLMs.
Many of these trigger drive-by-findings in sashiko. In particular:
- many load/store tearing and missing memory barriers, races
etc. in ipset, esp. with GC and resizing.
Keeping the proposed patches spinning for yet-another-iteration
keeps legit fixes back, so I prefer to add these now and follow
up with other reports later.
- flowtable work queue still has possible races with teardown,
but same rationale as with ipset: drive-by findings, not
problems coming with the flowtable IPIP changeset in this PR.
- ever since unreadable frag skb support was added in 6.12, we can no
longer do: BUG_ON(skb_copy_bits( ...): it will fire with such skbs.
Mina Almasry is looking at similar patterns elsewhere in the stack.
1) Guard skb->mac_header adjustment after IPv6 defragmentation in
nf_conntrack_reasm. From Xiang Mei.
2) NUL-terminate ebtables table names before calling find_table_lock() to
prevent stack-out-of-bounds reads. Also from Xiang Mei.
3) Zero the ebtables chainstack array, else error unwind may free bogus
pointer when CPU mask is sparse. All three issues date from 2.6 days.
4) Ensure ebtables module names are c-strings, same bug pattern as 2).
Bug added in 4.6.
5) Fix catchall element handling for inverted lookups in nft_lookup. Fold the
catchall lookup into ext before computing the match status. Was like
this ever since catchall elements got introduced in 5.13.
From Tamaki Yanagawa.
6-9) ipset updates from Jozsef Kadlecsik:
- mark rcu protected areas correctly
- address gc and resize clash in the comment extension
- add/del backlog cleanup in the error path
- allocate right size for the generic hash structure
10-12): IPIP flowtable updates from Pablo Neira Ayuso:
- Use the current direction's route when pushing IPIP headers
Fix incorrect headroom and fragmentation offset calculations.
- Avoid hardware offload for IPIP tunnels due to lack of driver support.
- Support IPIP tunnels with direct xmit in netfilter flowtable.
dst_cache and dst_cookie are moved outside the union to share route
state across flows. This is a followup to work done in 6.19 cycle.
13) Don't BUG() on skb_copy_bits error. Handle unreadable fragments by
either returning an error or restricting the copy operations to linear area,
This became an issue when unreable frag support was merged in 6.12.
14-16): IPVS updates from Yizhou Zhao:
- Pass parsed transport offset to IPVS state handlers.
update callback signatures.
- use correct transport header offset on state lookp in TCP.
As-is it was possible for ipv6 extension header data to be
treated as L4 header.
- same for SCTP. This was also broken since 2.6 days.
17) Ensure inner IP headers in ICMP errors are in the skb headroom after
stripping outer headers. Add more checks for the length of inner headers.
This was broken since 3.7 days.
From Julian Anastasov.
Please, pull these changes from:
The following changes since commit 6d27e29a90bc6a717b97c6ddcd866db7bd8e4adc:
Merge branch 'ipv4-ipv6-fix-uaf-and-memory-leak-in-igmp-mld' (2026-07-08 14:41:04 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-26-07-08
for you to fetch changes up to 3f7a535ff0fa627a0132803e4c2f903ceffcbc1c:
ipvs: ensure inner headers in ICMP errors are in headroom (2026-07-08 15:33:44 +0200)
----------------------------------------------------------------
netfilter pull request nf-26-07-08
----------------------------------------------------------------
Florian Westphal (3):
netfilter: ebtables: zero chainstack array
netfilter: ebtables: module names must be null-terminated
netfilter: handle unreadable frags
Jozsef Kadlecsik (4):
netfilter: ipset: mark the rcu locked areas properly
netfilter: ipset: exclude gc when resize is in progress
netfilter: ipset: cleanup the add/del backlog when resize failed
netfilter: ipset: allocate the proper memory for the generic hash structure
Julian Anastasov (1):
ipvs: ensure inner headers in ICMP errors are in headroom
Pablo Neira Ayuso (3):
netfilter: flowtable: use dst in this direction when pushing IPIP header
netfilter: flowtable: IPIP tunnel hardware offload is not yet support
netfilter: flowtable: support IPIP tunnel with direct xmit
Tamaki Yanagawa (1):
netfilter: nft_lookup: fix catchall element handling with inverted lookups
Xiang Mei (2):
netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag
netfilter: ebtables: terminate table name before find_table_lock()
Yizhou Zhao (3):
ipvs: pass parsed transport offset to state handlers
ipvs: use parsed transport offset in TCP state lookup
ipvs: use parsed transport offset in SCTP state lookup
include/net/ip_vs.h | 3 +-
include/net/netfilter/nf_flow_table.h | 7 +-
net/bridge/netfilter/ebtables.c | 12 +++-
net/ipv6/netfilter/nf_conntrack_reasm.c | 5 +-
net/netfilter/ipset/ip_set_hash_gen.h | 85 ++++++++++++++++---------
net/netfilter/ipvs/ip_vs_core.c | 31 +++++----
net/netfilter/ipvs/ip_vs_proto_sctp.c | 18 ++----
net/netfilter/ipvs/ip_vs_proto_tcp.c | 11 +---
net/netfilter/ipvs/ip_vs_proto_udp.c | 3 +-
net/netfilter/nf_flow_table_core.c | 19 +++---
net/netfilter/nf_flow_table_ip.c | 21 +++---
net/netfilter/nf_flow_table_offload.c | 22 ++++++-
net/netfilter/nfnetlink_log.c | 26 +++++---
net/netfilter/nfnetlink_queue.c | 16 +++--
net/netfilter/nft_lookup.c | 10 +--
net/netfilter/xt_u32.c | 16 +++--
16 files changed, 196 insertions(+), 109 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH net 01/17] netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag
From: Florian Westphal @ 2026-07-08 14:02 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260708140309.19633-1-fw@strlen.de>
From: Xiang Mei <xmei5@asu.edu>
nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6
fragment header and then unconditionally advances skb->mac_header:
skb->mac_header += sizeof(struct frag_hdr);
On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header
yet, so skb->mac_header is still the "not set" sentinel (u16)~0U. Adding
sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7),
after which skb_mac_header_was_set() wrongly reports a MAC header is
present and skb_mac_header() points into the headroom.
The reassembler has done this unconditional add since it was introduced;
it was harmless while mac_header was a bare pointer, but wrong once
mac_header became a u16 offset whose unset state is the ~0U sentinel
tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c
does the same relocation and does guard the adjustment; mirror the
guard here.
Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
Cc: stable@vger.kernel.org
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv6/netfilter/nf_conntrack_reasm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 64ab23ff559b..3637b20d3fa4 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -348,7 +348,8 @@ static int nf_ct_frag6_reasm(struct frag_queue *fq, struct sk_buff *skb,
skb_network_header(skb)[fq->nhoffset] = skb_transport_header(skb)[0];
memmove(skb->head + sizeof(struct frag_hdr), skb->head,
(skb->data - skb->head) - sizeof(struct frag_hdr));
- skb->mac_header += sizeof(struct frag_hdr);
+ if (skb_mac_header_was_set(skb))
+ skb->mac_header += sizeof(struct frag_hdr);
skb->network_header += sizeof(struct frag_hdr);
skb_reset_transport_header(skb);
--
2.54.0
^ permalink raw reply related
* [PATCH net 02/17] netfilter: ebtables: terminate table name before find_table_lock()
From: Florian Westphal @ 2026-07-08 14:02 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260708140309.19633-1-fw@strlen.de>
From: Xiang Mei <xmei5@asu.edu>
update_counters() and compat_update_counters() forward a user-supplied
32-byte table name to find_table_lock() without NUL-terminating it. On a
lookup miss, find_inlist_lock() calls try_then_request_module(..., "%s%s",
"ebtable_", name), and vsnprintf() reads past the name field and the
stack object until it hits a zero byte.
BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730)
Read of size 1 at addr ffff8880119dfb20 by task exploit/147
Call Trace:
...
string (lib/vsprintf.c:648 lib/vsprintf.c:730)
vsnprintf (lib/vsprintf.c:2945)
__request_module (kernel/module/kmod.c:150)
do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380)
update_counters (net/bridge/netfilter/ebtables.c:1440)
do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573)
nf_setsockopt (net/netfilter/nf_sockopt.c:101)
ip_setsockopt (net/ipv4/ip_sockglue.c:1424)
raw_setsockopt (net/ipv4/raw.c:847)
__sys_setsockopt (net/socket.c:2393)
...
compat_do_replace() shares the same unterminated name via
compat_copy_ebt_replace_from_user(); terminate it there too so all
find_table_lock() callers behave alike. The other callers already
terminate the name after the copy.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support")
Cc: stable@vger.kernel.org
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/bridge/netfilter/ebtables.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index f20c039e44c8..5b74ff827493 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1434,6 +1434,8 @@ static int update_counters(struct net *net, sockptr_t arg, unsigned int len)
if (copy_from_sockptr(&hlp, arg, sizeof(hlp)))
return -EFAULT;
+ hlp.name[sizeof(hlp.name) - 1] = '\0';
+
if (len != sizeof(hlp) + hlp.num_counters * sizeof(struct ebt_counter))
return -EINVAL;
@@ -2273,6 +2275,8 @@ static int compat_copy_ebt_replace_from_user(struct ebt_replace *repl,
memcpy(repl, &tmp, offsetof(struct ebt_replace, hook_entry));
+ repl->name[sizeof(repl->name) - 1] = '\0';
+
/* starting with hook_entry, 32 vs. 64 bit structures are different */
for (i = 0; i < NF_BR_NUMHOOKS; i++)
repl->hook_entry[i] = compat_ptr(tmp.hook_entry[i]);
@@ -2395,6 +2399,8 @@ static int compat_update_counters(struct net *net, sockptr_t arg,
if (copy_from_sockptr(&hlp, arg, sizeof(hlp)))
return -EFAULT;
+ hlp.name[sizeof(hlp.name) - 1] = '\0';
+
/* try real handler in case userland supplied needed padding */
if (len != sizeof(hlp) + hlp.num_counters * sizeof(struct ebt_counter))
return update_counters(net, arg, len);
--
2.54.0
^ permalink raw reply related
* [PATCH net 03/17] netfilter: ebtables: zero chainstack array
From: Florian Westphal @ 2026-07-08 14:02 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260708140309.19633-1-fw@strlen.de>
sashiko reports:
looking at ebtables table
translation, could a sparse cpu_possible_mask lead to an uninitialized pointer
free?
If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible,
but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at
CPU 2, the cleanup loop will blindly decrement and call vfree() on
newinfo->chainstack[1].
Not a real-world bug, such allocation isn't expected to fail
in the first place.
Cc: stable@vger.kernel.org
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/bridge/netfilter/ebtables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 5b74ff827493..48187598cdd0 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -921,8 +921,7 @@ static int translate_table(struct net *net, const char *name,
* if an error occurs
*/
newinfo->chainstack =
- vmalloc_array(nr_cpu_ids,
- sizeof(*(newinfo->chainstack)));
+ vcalloc(nr_cpu_ids, sizeof(*(newinfo->chainstack)));
if (!newinfo->chainstack)
return -ENOMEM;
for_each_possible_cpu(i) {
--
2.54.0
^ permalink raw reply related
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