* RE: [PATCH net v4 1/4] iavf: return EBUSY if reset in progress or not ready during MAC change
From: Loktionov, Aleksandr @ 2026-04-23 13:14 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kitszel, Przemyslaw,
Keller, Jacob E, horms@kernel.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
In-Reply-To: <20260423130405.139568-2-jtornosm@redhat.com>
> -----Original Message-----
> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Sent: Thursday, April 23, 2026 3:04 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; horms@kernel.org;
> jesse.brandeburg@intel.com; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>
> Subject: [PATCH net v4 1/4] iavf: return EBUSY if reset in progress or
> not ready during MAC change
>
> When a MAC address change is requested while the VF is resetting or
> still initializing, return -EBUSY immediately instead of attempting
> the operation.
>
> Additionally, during early initialization states (before __IAVF_DOWN),
> the PF may be slow to respond to MAC change requests, causing long
> delays. Only allow MAC changes once the VF reaches __IAVF_DOWN state
> or later, when the watchdog is running and the VF is ready for
> operations.
>
> After commit ad7c7b2172c3 ("net: hold netdev instance lock during
> sysfs operations"), MAC changes are called with the netdev lock held,
> so we should not wait with the lock held during reset or
> initialization. This allows the caller to retry or handle the busy
> state appropriately without blocking other operations.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> ---
>
> drivers/net/ethernet/intel/iavf/iavf_main.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c
> b/drivers/net/ethernet/intel/iavf/iavf_main.c
> index dad001abc908..67aa14350b1b 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> @@ -1060,6 +1060,9 @@ static int iavf_set_mac(struct net_device
> *netdev, void *p)
> struct sockaddr *addr = p;
> int ret;
>
> + if (iavf_is_reset_in_progress(adapter) || adapter->state <
> __IAVF_DOWN)
> + return -EBUSY;
> +
> if (!is_valid_ether_addr(addr->sa_data))
> return -EADDRNOTAVAIL;
>
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [PATCH net v4 2/4] i40e: skip unnecessary VF reset when setting trust
From: Loktionov, Aleksandr @ 2026-04-23 13:14 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kitszel, Przemyslaw,
Keller, Jacob E, horms@kernel.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
In-Reply-To: <20260423130405.139568-3-jtornosm@redhat.com>
> -----Original Message-----
> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Sent: Thursday, April 23, 2026 3:04 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; horms@kernel.org;
> jesse.brandeburg@intel.com; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>
> Subject: [PATCH net v4 2/4] i40e: skip unnecessary VF reset when
> setting trust
>
> The current implementation triggers a VF reset when changing the trust
> setting, causing a ~10 second delay during bonding setup.
>
> In all the cases, the reset causes a ~10 second delay during which:
> - VF must reinitialize completely
> - Any in-progress operations (like bonding enslave) fail with timeouts
> - VF is unavailable
>
> When granting trust, no reset is needed - we can just set the
> capability flag to allow privileged operations.
>
> When revoking trust, we need to:
> 1. Clear the capability flag to block privileged operations 2. Disable
> promiscuous mode if it was enabled (trusted VFs can enable it) 3. Only
> reset if ADQ is enabled (to clean up cloud filters)
>
> When we do reset (ADQ case), we reset first to clear VF_STATE_ACTIVE
> (which blocks new cloud filter additions), then delete existing cloud
> filters safely. This avoids the race condition where VF could add
> filters during deletion.
>
> When we don't reset, we manually handle capability flag and
> promiscuous mode via helper function, eliminating the delay.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> v4: Address AI review (sashiko.dev) from Simon Horman:
> - Manually set/clear capability flag when not resetting
> - Explicitly disable promiscuous mode when revoking trust
> - Fix cloud filter race: reset FIRST (clears VF_STATE_ACTIVE),
> delete filters AFTER (no race window)
> - Add helper function i40e_setup_vf_trust() for non-reset path
> v3: https://lore.kernel.org/all/20260414110006.124286-3-
> jtornosm@redhat.com/
>
> .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 42 ++++++++++++++----
> -
> 1 file changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> index a26c3d47ec15..69f68fec6809 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
> @@ -4943,6 +4943,30 @@ int i40e_ndo_set_vf_spoofchk(struct net_device
> *netdev, int vf_id, bool enable)
> return ret;
> }
>
> +/**
> + * i40e_setup_vf_trust - Enable/disable VF trust mode without reset
> + * @vf: VF to configure
> + * @setting: trust setting
> + *
> + * Manually handle capability flag and promiscuous mode when changing
> +trust
> + * without performing a VF reset.
> + * When reset is performed, this is not necessary as the reset
> +procedure
> + * already handles this.
> + **/
> +static void i40e_setup_vf_trust(struct i40e_vf *vf, bool setting) {
> + if (setting) {
> + set_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> + } else {
> + clear_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> +
> + if (test_bit(I40E_VF_STATE_UC_PROMISC, &vf->vf_states)
> ||
> + test_bit(I40E_VF_STATE_MC_PROMISC, &vf->vf_states))
> + i40e_config_vf_promiscuous_mode(vf, vf-
> >lan_vsi_idx,
> + false, false);
> + }
> +}
> +
> /**
> * i40e_ndo_set_vf_trust
> * @netdev: network interface device structure of the pf @@ -4987,19
> +5011,17 @@ int i40e_ndo_set_vf_trust(struct net_device *netdev, int
> vf_id, bool setting)
> set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state);
> pf->vsi[vf->lan_vsi_idx]->flags |=
> I40E_VSI_FLAG_FILTER_CHANGED;
>
> - i40e_vc_reset_vf(vf, true);
> + /* Reset only if revoking trust with ADQ (for cloud filter
> cleanup) */
> + if (vf->adq_enabled && !setting) {
> + i40e_vc_reset_vf(vf, true);
> + i40e_del_all_cloud_filters(vf);
> + } else {
> + i40e_setup_vf_trust(vf, setting);
> + }
> +
> dev_info(&pf->pdev->dev, "VF %u is now %strusted\n",
> vf_id, setting ? "" : "un");
>
> - if (vf->adq_enabled) {
> - if (!vf->trusted) {
> - dev_info(&pf->pdev->dev,
> - "VF %u no longer Trusted, deleting all
> cloud filters\n",
> - vf_id);
> - i40e_del_all_cloud_filters(vf);
> - }
> - }
> -
> out:
> clear_bit(__I40E_VIRTCHNL_OP_PENDING, pf->state);
> return ret;
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [PATCH net v4 3/4] iavf: send MAC change request synchronously
From: Loktionov, Aleksandr @ 2026-04-23 13:14 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kitszel, Przemyslaw,
Keller, Jacob E, horms@kernel.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, stable@vger.kernel.org
In-Reply-To: <20260423130405.139568-4-jtornosm@redhat.com>
> -----Original Message-----
> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Sent: Thursday, April 23, 2026 3:04 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; horms@kernel.org;
> jesse.brandeburg@intel.com; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>; stable@vger.kernel.org
> Subject: [PATCH net v4 3/4] iavf: send MAC change request
> synchronously
>
> After commit ad7c7b2172c3 ("net: hold netdev instance lock during
> sysfs operations"), iavf_set_mac() is called with the netdev instance
> lock already held.
>
> The function queues a MAC address change request via
> iavf_replace_primary_mac() and then waits for completion. However, in
> the current flow, the actual virtchnl message is sent by the watchdog
> task, which also needs to acquire the netdev lock to run.
> Additionally, the adminq_task which processes virtchnl responses also
> needs the netdev lock.
>
> This creates a deadlock scenario:
> 1. iavf_set_mac() holds netdev lock and waits for MAC change 2.
> Watchdog needs netdev lock to send the request -> blocked 3. Even if
> request is sent, adminq_task needs netdev lock to process
> PF response -> blocked
> 4. MAC change times out after 2.5 seconds 5. iavf_set_mac() returns -
> EAGAIN
>
> This particularly affects VFs during bonding setup when multiple VFs
> are enslaved in quick succession.
>
> Fix by implementing a synchronous MAC change operation similar to the
> approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset
> handling in callbacks").
>
> The solution:
> 1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog)
> 2. Poll the admin queue hardware directly for responses 3. Process all
> received messages (including non-MAC messages) 4. Return when MAC
> change completes or times out
>
> A new generic function iavf_poll_virtchnl_response() is introduced
> that can be reused for any future synchronous virtchnl operations. It
> takes a callback to check completion, allowing flexible condition
> checking.
>
> This allows the operation to complete synchronously while holding
> netdev_lock, without relying on watchdog or adminq_task. The function
> can sleep for up to 2.5 seconds polling hardware, but this is
> acceptable since netdev_lock is per-device and only serializes
> operations on the same interface.
>
> To support this, change iavf_add_ether_addrs() to return an error code
> instead of void, allowing callers to detect failures. Additionally,
> export iavf_mac_add_reject() to enable proper rollback on local
> failures (timeouts, send errors) - PF rejections are already handled
> automatically by iavf_virtchnl_completion().
>
> Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs
> operations")
> cc: stable@vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> v4: Complete with Przemek Kitszel comments:
> - Remove vc_waitqueue entirely (not needed any more)
> - Add named parameters to callback function pointer declaration
> for
> clarity
> - Simplify callback signature: add v_op parameter so callback
> receives the opcode from the processed message to identify which
> response was received
> - Optimize polling loop to single condition check per iteration
> instead of checking both before and after message processing
> Address AI review (sashiko.dev) from Simon Horman:
> - Complete iavf_add_ether_addrs() error handling
> - Skip non-virtchnl hardware events
> (received_op=VIRTCHNL_OP_UNKNOWN),
> these can cause false completion detection
> - Complete rollback for local failures (not PF rejection) reusing
> iavf_mac_add_reject() to restore the old primary filter
> v3: https://lore.kernel.org/netdev/20260414110006.124286-4-
> jtornosm@redhat.com/
>
> drivers/net/ethernet/intel/iavf/iavf.h | 10 +-
> drivers/net/ethernet/intel/iavf/iavf_main.c | 70 +++++++++----
> .../net/ethernet/intel/iavf/iavf_virtchnl.c | 99 +++++++++++++++++-
> -
> 3 files changed, 151 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> b/drivers/net/ethernet/intel/iavf/iavf.h
> index e9fb0a0919e3..78fa3df06e11 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf.h
> @@ -260,7 +260,6 @@ struct iavf_adapter {
> struct work_struct adminq_task;
> struct work_struct finish_config;
> wait_queue_head_t down_waitqueue;
...
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [PATCH net v4 4/4] ice: skip unnecessary VF reset when setting trust
From: Loktionov, Aleksandr @ 2026-04-23 13:17 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kitszel, Przemyslaw,
Keller, Jacob E, horms@kernel.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
In-Reply-To: <20260423130405.139568-5-jtornosm@redhat.com>
> -----Original Message-----
> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Sent: Thursday, April 23, 2026 3:04 PM
> To: netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; horms@kernel.org;
> jesse.brandeburg@intel.com; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose Ignacio
> Tornos Martinez <jtornosm@redhat.com>
> Subject: [PATCH net v4 4/4] ice: skip unnecessary VF reset when
> setting trust
>
> Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
> ice_reset_vf() when the trust setting changes. While the delay is
> smaller than i40e this reset is still unnecessary in most cases.
>
> Additionally, the original code has a race condition: it deletes MAC
> LLDP filters BEFORE resetting the VF. During this deletion, the VF is
> still ACTIVE and can add new MAC LLDP filters concurrently,
> potentially corrupting the filter list.
>
> When granting trust, no reset is needed - we can just set the
> capability flag to allow privileged operations.
>
> When revoking trust, we need to:
> 1. Clear the capability flag to block privileged operations 2. Disable
> promiscuous mode if it was enabled (trusted VFs can enable it) 3. Only
> reset if MAC LLDP filters exist (to clean them up)
>
> When we do reset (MAC LLDP case), we fix the race condition by
> resetting first to clear VF state (which blocks new MAC LLDP filter
> additions), then delete existing filters safely. During cleanup, vf-
> >trusted remains true so
> ice_vf_is_lldp_ena() works properly. Only after cleanup do we set
> vf->trusted = false.
>
> When we don't reset, we manually handle capability flag and
> promiscuous mode via helper function.
>
> The ice driver already has logic to clean up MAC LLDP filters when
> removing trust. After this cleanup, the VF reset is only necessary if
> there were actually filters to remove (num_mac_lldp was non-zero).
>
> This saves time and eliminates unnecessary service disruption when
> changing VF trust settings in most cases, while properly handling
> filter cleanup.
>
> Fixes: 2296345416b0 ("ice: receive LLDP on trusted VFs")
For me it looks like cc: stable@vger.kernel.org must be added
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
> v4:
> - Address AI review (sashiko.dev) from Simon Horman:
> vf->trusted ordering bug
> - Fix upstream race condition when comparing with i40e code
> - Apply capability flag and promiscuous mode fixes from i40e AI
> review
> - Add helper function ice_setup_vf_trust() for non-reset path
> - Export ice_vf_clear_all_promisc_modes() for code reuse
> v3: https://lore.kernel.org/all/20260414110006.124286-5-
> jtornosm@redhat.com/
>
> drivers/net/ethernet/intel/ice/ice_sriov.c | 41 +++++++++++++++++++-
> - drivers/net/ethernet/intel/ice/ice_vf_lib.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_vf_lib.h | 1 +
> 3 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 7e00e091756d..d0da7f6adc23 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> @@ -1364,6 +1364,34 @@ int ice_set_vf_mac(struct net_device *netdev,
> int vf_id, u8 *mac)
> return __ice_set_vf_mac(ice_netdev_to_pf(netdev), vf_id, mac);
> }
>
> +/**
> + * ice_setup_vf_trust - Enable/disable VF trust mode without reset
> + * @vf: VF to configure
> + * @setting: trust setting
> + *
> + * Manually handle capability flag and promiscuous mode when changing
> +trust
> + * without performing a VF reset.
> + * When reset is performed, this is not necessary as the reset
> +procedure
> + * already handles this.
> + **/
> +static void ice_setup_vf_trust(struct ice_vf *vf, bool setting) {
> + struct ice_vsi *vsi;
> +
> + if (setting) {
> + set_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> + } else {
> + clear_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> +
> + if (test_bit(ICE_VF_STATE_UC_PROMISC, vf->vf_states) ||
> + test_bit(ICE_VF_STATE_MC_PROMISC, vf->vf_states)) {
> + vsi = ice_get_vf_vsi(vf);
> + if (vsi)
> + ice_vf_clear_all_promisc_modes(vf, vsi);
You declare ice_vf_clear_all_promisc_modes() returning int, but ignore the return value.
Looks suspicious isn't it?
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> + }
> + }
> +}
> +
> /**
> * ice_set_vf_trust
> * @netdev: network interface device structure @@ -1399,11 +1427,16
> @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool
> trusted)
>
> mutex_lock(&vf->cfg_lock);
>
> - while (!trusted && vf->num_mac_lldp)
> - ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf),
> false);
> -
> + /* Reset only if revoking trust with MAC LLDP filters */
> + if (!trusted && vf->num_mac_lldp) {
> + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> + while (vf->num_mac_lldp)
> + ice_vf_update_mac_lldp_num(vf,
> ice_get_vf_vsi(vf), false);
> + } else {
> + ice_setup_vf_trust(vf, trusted);
> + }
> vf->trusted = trusted;
> - ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> +
> dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
> vf_id, trusted ? "" : "un");
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> index c8bc952f05cd..81bbf30e5c29 100644
> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> @@ -623,7 +623,7 @@ ice_vf_get_promisc_masks(struct ice_vf *vf, struct
> ice_vsi *vsi,
> *
> * Clear all promiscuous/allmulticast filters for a VF
> */
> -static int
> +int
> ice_vf_clear_all_promisc_modes(struct ice_vf *vf, struct ice_vsi
> *vsi) {
> struct ice_pf *pf = vf->pf;
> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> index 7a9c75d1d07c..a3501bd92311 100644
> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> @@ -310,6 +310,7 @@ bool ice_is_any_vf_in_unicast_promisc(struct
> ice_pf *pf); void ice_vf_get_promisc_masks(struct ice_vf *vf, struct
> ice_vsi *vsi,
> u8 *ucast_m, u8 *mcast_m);
> +int ice_vf_clear_all_promisc_modes(struct ice_vf *vf, struct ice_vsi
> +*vsi);
> int
> ice_vf_set_vsi_promisc(struct ice_vf *vf, struct ice_vsi *vsi, u8
> promisc_m); int
> --
> 2.53.0
^ permalink raw reply
* [syzbot] [hams?] WARNING: ODEBUG bug in rose_release
From: syzbot @ 2026-04-23 13:23 UTC (permalink / raw)
To: davem, edumazet, horms, kuba, linux-hams, linux-kernel, netdev,
pabeni, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2a4c0c11c019 Merge tag 's390-7.1-1' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12df3702580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3e19fa1907a3dfda
dashboard link: https://syzkaller.appspot.com/bug?extid=b091c5774423d1319a22
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-2a4c0c11.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2702dddfd186/vmlinux-2a4c0c11.xz
kernel image: https://storage.googleapis.com/syzbot-assets/51878be8732c/bzImage-2a4c0c11.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b091c5774423d1319a22@syzkaller.appspotmail.com
------------[ cut here ]------------
ODEBUG: free active (active state 0) object: ffff88803f4d2090 object type: timer_list hint: rose_t0timer_expiry+0x0/0x150 include/linux/skbuff.h:2942
WARNING: lib/debugobjects.c:629 at debug_print_object+0x18e/0x2a0 lib/debugobjects.c:629, CPU#2: syz.1.11287/7248
Modules linked in:
CPU: 2 UID: 0 PID: 7248 Comm: syz.1.11287 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:debug_print_object+0x19b/0x2a0 lib/debugobjects.c:629
Code: b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 48 8d 3d f2 18 e4 0b 41 56 48 8b 14 dd c0 33 1c 8c 4c 89 e6 <67> 48 0f b9 3a 58 83 05 0c c5 d9 0b 01 48 83 c4 18 5b 5d 41 5c 41
RSP: 0018:ffffc90005ba7808 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffffffff8c1c3300 RSI: ffffffff8c1c2f20 RDI: ffffffff90e6aac0
RBP: 0000000000000001 R08: ffff88803f4d2090 R09: ffffffff8bb2c6e0
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff8c1c2f20
R13: ffffffff8bb2c720 R14: ffffffff8a84b230 R15: ffffc90005ba7908
FS: 0000000000000000(0000) GS:ffff8880d64db000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555594c2f9e8 CR3: 0000000039419000 CR4: 0000000000352ef0
Call Trace:
<TASK>
__debug_check_no_obj_freed lib/debugobjects.c:1116 [inline]
debug_check_no_obj_freed+0x4da/0x630 lib/debugobjects.c:1146
slab_free_hook mm/slub.c:2620 [inline]
slab_free mm/slub.c:6246 [inline]
kfree+0x3d0/0x6c0 mm/slub.c:6561
rose_neigh_put include/net/rose.h:166 [inline]
rose_neigh_put include/net/rose.h:160 [inline]
rose_release+0x60b/0x740 net/rose/af_rose.c:658
__sock_release+0xb3/0x260 net/socket.c:722
sock_close+0x1c/0x30 net/socket.c:1514
__fput+0x3ff/0xb50 fs/file_table.c:510
task_work_run+0x150/0x240 kernel/task_work.c:233
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0x8d2/0x2a60 kernel/exit.c:975
do_group_exit+0xd5/0x2a0 kernel/exit.c:1117
get_signal+0x1ec7/0x21e0 kernel/signal.c:3037
arch_do_signal_or_restart+0x91/0x7a0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x86/0x4a0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x706/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: eccb:0xe4a421182f13d611
Code: Unable to access opcode bytes at 0xe4a421182f13d5e7.
RSP: 002b:00007fb92f11ff58 EFLAGS: 00000756 ORIG_RAX: d1d66dbfed01019b
RAX: 2bf9e1987c1988ee RBX: 6f67a894836fe1f3 RCX: ed0b474b2b46640f
RDX: fb381f0b5e12d2ce RSI: 401aaa756d8c34aa RDI: 30b9ec15aecde911
RBP: 532828f82bbb556c R08: dbce39d105fdbf88 R09: ae9ea378b9c9fbc7
R10: 33740f3b8630618c R11: 2450ade207355af5 R12: 0a61688f027fb1a4
R13: 339c71c774e61334 R14: 28baed4a0483d193 R15: 7c1f9cf2b758efdc
</TASK>
----------------
Code disassembly (best guess):
0: b8 00 00 00 00 mov $0x0,%eax
5: 00 fc add %bh,%ah
7: ff lcall (bad)
8: df 48 89 fisttps -0x77(%rax)
b: fa cli
c: 48 c1 ea 03 shr $0x3,%rdx
10: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1)
14: 75 4f jne 0x65
16: 48 8d 3d f2 18 e4 0b lea 0xbe418f2(%rip),%rdi # 0xbe4190f
1d: 41 56 push %r14
1f: 48 8b 14 dd c0 33 1c mov -0x73e3cc40(,%rbx,8),%rdx
26: 8c
27: 4c 89 e6 mov %r12,%rsi
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 58 pop %rax
30: 83 05 0c c5 d9 0b 01 addl $0x1,0xbd9c50c(%rip) # 0xbd9c543
37: 48 83 c4 18 add $0x18,%rsp
3b: 5b pop %rbx
3c: 5d pop %rbp
3d: 41 5c pop %r12
3f: 41 rex.B
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [syzbot] [net?] WARNING: refcount bug in sk_common_release (2)
From: syzbot @ 2026-04-23 13:23 UTC (permalink / raw)
To: davem, dsahern, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2a4c0c11c019 Merge tag 's390-7.1-1' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=142dff16580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3e19fa1907a3dfda
dashboard link: https://syzkaller.appspot.com/bug?extid=8c9eede336e3a843750e
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-2a4c0c11.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2702dddfd186/vmlinux-2a4c0c11.xz
kernel image: https://storage.googleapis.com/syzbot-assets/51878be8732c/bzImage-2a4c0c11.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8c9eede336e3a843750e@syzkaller.appspotmail.com
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x130 lib/refcount.c:28, CPU#1: syz.8.4131/20639
Modules linked in:
CPU: 1 UID: 0 PID: 20639 Comm: syz.8.4131 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:refcount_warn_saturate+0xf4/0x130 lib/refcount.c:28
Code: cc e8 60 a7 0f fd 48 8d 3d 99 d0 ec 0b 67 48 0f b9 3a e8 4f a7 0f fd 5b 5d e9 48 27 a4 06 e8 43 a7 0f fd 48 8d 3d 8c d0 ec 0b <67> 48 0f b9 3a e8 32 a7 0f fd 5b 5d c3 cc cc cc cc e8 26 a7 0f fd
RSP: 0018:ffffc90003aaf120 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8880368a2280 RCX: ffffffff84f9d30b
RDX: ffff888061e04a00 RSI: ffffffff84f9d39d RDI: ffffffff90e6a430
RBP: 0000000000000003 R08: 0000000000000005 R09: 0000000000000004
R10: 0000000000000003 R11: 0000000000000000 R12: ffff8880368a2280
R13: ffffffff8a0c6f20 R14: 0000000000000000 R15: 0000000000000018
FS: 00007fd377c686c0(0000) GS:ffff8880d63db000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b33023ffc CR3: 00000000308a1000 CR4: 0000000000352ef0
Call Trace:
<TASK>
__refcount_sub_and_test include/linux/refcount.h:400 [inline]
__refcount_dec_and_test include/linux/refcount.h:432 [inline]
refcount_dec_and_test include/linux/refcount.h:450 [inline]
sock_put include/net/sock.h:2009 [inline]
sk_common_release+0x260/0x370 net/core/sock.c:4024
inet_release+0xed/0x200 net/ipv4/af_inet.c:442
__sock_release net/socket.c:722 [inline]
sock_release+0x91/0x1c0 net/socket.c:750
rxe_release_udp_tunnel drivers/infiniband/sw/rxe/rxe_net.c:294 [inline]
rxe_sock_put+0xae/0x130 drivers/infiniband/sw/rxe/rxe_net.c:639
rxe_net_del+0x83/0x120 drivers/infiniband/sw/rxe/rxe_net.c:660
rxe_dellink+0x15/0x20 drivers/infiniband/sw/rxe/rxe.c:254
nldev_dellink+0x289/0x3c0 drivers/infiniband/core/nldev.c:1849
rdma_nl_rcv_msg+0x392/0x6f0 drivers/infiniband/core/netlink.c:195
rdma_nl_rcv_skb.constprop.0.isra.0+0x2cb/0x410 drivers/infiniband/core/netlink.c:239
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:787 [inline]
__sock_sendmsg net/socket.c:802 [inline]
____sys_sendmsg+0x9e1/0xb70 net/socket.c:2698
___sys_sendmsg+0x190/0x1e0 net/socket.c:2752
__sys_sendmsg+0x170/0x220 net/socket.c:2784
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x10b/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd376d9c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd377c68028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fd377016090 RCX: 00007fd376d9c819
RDX: 0000000000000004 RSI: 0000200000004680 RDI: 0000000000000003
RBP: 00007fd376e32c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fd377016128 R14: 00007fd377016090 R15: 00007ffe66f5e6c8
</TASK>
----------------
Code disassembly (best guess):
0: cc int3
1: e8 60 a7 0f fd call 0xfd0fa766
6: 48 8d 3d 99 d0 ec 0b lea 0xbecd099(%rip),%rdi # 0xbecd0a6
d: 67 48 0f b9 3a ud1 (%edx),%rdi
12: e8 4f a7 0f fd call 0xfd0fa766
17: 5b pop %rbx
18: 5d pop %rbp
19: e9 48 27 a4 06 jmp 0x6a42766
1e: e8 43 a7 0f fd call 0xfd0fa766
23: 48 8d 3d 8c d0 ec 0b lea 0xbecd08c(%rip),%rdi # 0xbecd0b6
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: e8 32 a7 0f fd call 0xfd0fa766
34: 5b pop %rbx
35: 5d pop %rbp
36: c3 ret
37: cc int3
38: cc int3
39: cc int3
3a: cc int3
3b: e8 26 a7 0f fd call 0xfd0fa766
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH net 4/4] gve: Make ethtool config changes synchronous
From: Paolo Abeni @ 2026-04-23 13:25 UTC (permalink / raw)
To: Harshitha Ramamurthy, netdev
Cc: joshwash, andrew+netdev, davem, edumazet, kuba, willemb, maolson,
nktgrg, jfraker, ziweixiao, jacob.e.keller, pkaligineedi,
shailend, jordanrhee, stable, linux-kernel, Pin-yen Lin
In-Reply-To: <20260420171837.455487-5-hramamurthy@google.com>
On 4/20/26 7:18 PM, Harshitha Ramamurthy wrote:
> From: Pin-yen Lin <treapking@google.com>
>
> When modifying device features via ethtool, the driver queues the
> carrier status update to its workqueue (gve_wq). This leads to a
> short link-down state after running the ethtool command.
>
> Use `gve_turnup_and_check_status()` instead of `gve_turnup()` in
> `gve_queues_start()` to update the carrier status before returning to
> the userspace.
>
> This was discovered by drivers/net/ping.py selftest. The test calls
> ping command right after an ethtool configuration, but the interface
> could be down without this fix.
>
> Cc: stable@vger.kernel.org
> Fixes: 5f08cd3d6423 ("gve: Alloc before freeing when adjusting queues")
> Reviewed-by: Joshua Washington <joshwash@google.com>
> Signed-off-by: Pin-yen Lin <treapking@google.com>
> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> ---
> drivers/net/ethernet/google/gve/gve_main.c | 56 +++++++++++-----------
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> index 8617782791e0..d3b4bec38de5 100644
> --- a/drivers/net/ethernet/google/gve/gve_main.c
> +++ b/drivers/net/ethernet/google/gve/gve_main.c
> @@ -1374,6 +1374,33 @@ static void gve_queues_mem_remove(struct gve_priv *priv)
> priv->rx = NULL;
> }
>
> +static void gve_handle_link_status(struct gve_priv *priv, bool link_status)
> +{
> + if (!gve_get_napi_enabled(priv))
> + return;
> +
> + if (link_status == netif_carrier_ok(priv->dev))
> + return;
> +
> + if (link_status) {
> + netdev_info(priv->dev, "Device link is up.\n");
> + netif_carrier_on(priv->dev);
> + } else {
> + netdev_info(priv->dev, "Device link is down.\n");
> + netif_carrier_off(priv->dev);
> + }
> +}
> +
> +static void gve_turnup_and_check_status(struct gve_priv *priv)
> +{
> + u32 status;
> +
> + gve_turnup(priv);
> + status = ioread32be(&priv->reg_bar0->device_status);
> + gve_handle_link_status(priv,
> + GVE_DEVICE_STATUS_LINK_STATUS_MASK & status);
> +}
> +
> /* The passed-in queue memory is stored into priv and the queues are made live.
> * No memory is allocated. Passed-in memory is freed on errors.
> */
> @@ -1434,8 +1461,7 @@ static int gve_queues_start(struct gve_priv *priv,
> round_jiffies(jiffies +
> msecs_to_jiffies(priv->stats_report_timer_period)));
>
> - gve_turnup(priv);
> - queue_work(priv->gve_wq, &priv->service_task);
> + gve_turnup_and_check_status(priv);
Sashiko says:
Since gve_handle_link_status() can now be called from process context
via gve_turnup_and_check_status(), while also being concurrently
executed by gve_service_task() on the workqueue, could this create a
time-of-check to time-of-use race?
If the physical link toggles rapidly, could the workqueue thread sample
the later hardware state (e.g. OFF) but see the software state is
already OFF and return early, while the process context thread sampled
the earlier state (e.g. ON), evaluated netif_carrier_ok() as OFF, and
proceeded to call netif_carrier_on()?
This might leave the software carrier state stuck ON when the most
recent hardware state is OFF, because the condition check and update are
no longer serialized by the workqueue.
Notes that there more comments:
https://sashiko.dev/#/patchset/20260420171837.455487-1-hramamurthy%40google.com
but I'm not sure if they are actual regressions introduced by this series.
/P
^ permalink raw reply
* [BUG] KASAN: slab-use-after-free Write in sk_skb_reason_drop
From: Eulgyu Kim @ 2026-04-23 13:41 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni
Cc: horms, netdev, linux-kernel, byoungyoung, jjy600901
Hello,
We encountered a "KASAN: slab-use-after-free Write in sk_skb_reason_drop"
on kernel version v7.0.
As this memory corruption bug seems to require `CAP_NET_ADMIN`,
we report this in public mailing list.
We have included the following items below:
- C reproducer (~100 lines)
- kernel delay patch
- KASAN crash log
To reliably trigger the race condition bug, we patched the kernel
to inject a delay at a specific point.
The kernel config used is the same as the syzbot configuration.
Unfortunately, we do not have a fix ready for this bug yet.
As this issue was identified via fuzzing and we have limited background,
we find it challenging to propose a correct fix or evaluate
its potential severity.
We hope this report helps address the issue. Please let us know
if any further information is needed.
Thank you.
Best Regards,
Eulgyu Kim
kernel delay patch:
==================================================================
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index c492fda6f..ba7078e18 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1891,6 +1891,10 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
!tfile->detached)
rxhash = __skb_get_hash_symmetric(skb);
+ if (strcmp(current->comm, "slowme") == 0) {
+ mdelay(2000);
+ }
+
rcu_read_lock();
if (unlikely(!(tun->dev->flags & IFF_UP))) {
err = -EIO;
==================================================================
C reproducer:
==================================================================
#define _GNU_SOURCE
#include <fcntl.h>
#include <linux/aio_abi.h>
#include <linux/if_tun.h>
#include <linux/rtnetlink.h>
#include <net/if.h>
#include <pthread.h>
#include <stdint.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/prctl.h>
#include <sys/socket.h>
#include <sys/syscall.h>
#include <unistd.h>
static int tun_fd = -1;
static int route_fd = -1;
static aio_context_t aio_ctx;
static unsigned char tap_frame[14];
static struct iocb aio_cb;
static struct iocb *aio_cbs[] = {
&aio_cb,
};
static struct {
struct nlmsghdr nlh;
struct ifinfomsg ifi;
struct rtattr attr;
char ifname[16];
} delete_link = {
.nlh = {
.nlmsg_len = sizeof(delete_link),
.nlmsg_type = RTM_DELLINK,
.nlmsg_flags = NLM_F_REQUEST,
},
.attr = {
.rta_len = sizeof(struct rtattr) + 16,
.rta_type = IFLA_IFNAME,
},
.ifname = "test1",
};
void *thread_fn(void *arg)
{
aio_cb.aio_lio_opcode = IOCB_CMD_PWRITE;
aio_cb.aio_fildes = tun_fd;
aio_cb.aio_buf = (uint64_t)(uintptr_t)tap_frame;
aio_cb.aio_nbytes = sizeof(tap_frame);
syscall(__NR_io_setup, 1, &aio_ctx);
prctl(PR_SET_NAME, "slowme", 0, 0, 0);
syscall(__NR_io_submit, aio_ctx, 1L, aio_cbs);
return NULL;
}
int main(void)
{
struct ifreq ifr = {0};
struct sockaddr_nl kernel = {
.nl_family = AF_NETLINK,
};
struct iovec iov = {
.iov_base = &delete_link,
.iov_len = sizeof(delete_link),
};
struct msghdr msg = {
.msg_name = &kernel,
.msg_namelen = sizeof(kernel),
.msg_iov = &iov,
.msg_iovlen = 1,
};
pthread_t thread;
tun_fd = open("/dev/net/tun", O_WRONLY);
strcpy(ifr.ifr_name, "test1");
ifr.ifr_flags = IFF_TAP | IFF_NAPI | IFF_NAPI_FRAGS | IFF_NO_PI;
ioctl(tun_fd, TUNSETIFF, &ifr);
pthread_create(&thread, NULL, thread_fn, NULL);
sleep(1);
route_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
sendmsg(route_fd, &msg, 0);
return 0;
}
==================================================================
KASAN crash log:
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
BUG: KASAN: slab-use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [inline]
BUG: KASAN: slab-use-after-free in __refcount_sub_and_test include/linux/refcount.h:389 [inline]
BUG: KASAN: slab-use-after-free in __refcount_dec_and_test include/linux/refcount.h:432 [inline]
BUG: KASAN: slab-use-after-free in refcount_dec_and_test include/linux/refcount.h:450 [inline]
BUG: KASAN: slab-use-after-free in skb_unref include/linux/skbuff.h:1292 [inline]
BUG: KASAN: slab-use-after-free in __sk_skb_reason_drop net/core/skbuff.c:1223 [inline]
BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x37/0x110 net/core/skbuff.c:1251
Write of size 4 at addr ffff888126d779e4 by task slowme/10161
CPU: 4 UID: 0 PID: 10161 Comm: slowme Not tainted 7.0.0-g1e0734834e71 #29 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x240 mm/kasan/report.c:482
kasan_report+0x118/0x150 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200
instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [inline]
__refcount_sub_and_test include/linux/refcount.h:389 [inline]
__refcount_dec_and_test include/linux/refcount.h:432 [inline]
refcount_dec_and_test include/linux/refcount.h:450 [inline]
skb_unref include/linux/skbuff.h:1292 [inline]
__sk_skb_reason_drop net/core/skbuff.c:1223 [inline]
sk_skb_reason_drop+0x37/0x110 net/core/skbuff.c:1251
kfree_skb_reason include/linux/skbuff.h:1322 [inline]
tun_get_user+0x17bc/0x3e70 drivers/net/tun.c:1978
tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:2003
aio_write+0x535/0x7a0 fs/aio.c:1633
__io_submit_one fs/aio.c:-1 [inline]
io_submit_one+0x775/0x1430 fs/aio.c:2052
__do_sys_io_submit fs/aio.c:2111 [inline]
__se_sys_io_submit+0x185/0x320 fs/aio.c:2081
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x415b8d
Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9af2f7b228 EFLAGS: 00000246 ORIG_RAX: 00000000000000d1
RAX: ffffffffffffffda RBX: 00007f9af2f7bcdc RCX: 0000000000415b8d
RDX: 00000000004c7158 RSI: 0000000000000001 RDI: 00007f9af277a000
RBP: 00007f9af2f7b240 R08: 00007f9af2f7b6c0 R09: 00007f9af2f7b6c0
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9af2f7b6c0
R13: ffffffffffffffb8 R14: 0000000000000000 R15: 00007ffdbdd55900
</TASK>
Allocated by task 10161:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_mempool_unpoison_object+0x9f/0x130 mm/kasan/common.c:564
kasan_mempool_unpoison_object include/linux/kasan.h:391 [inline]
napi_skb_cache_get+0x3c9/0x780 net/core/skbuff.c:306
__alloc_skb+0x146/0x7d0 net/core/skbuff.c:691
napi_alloc_skb+0x7a/0xaf0 net/core/skbuff.c:853
napi_get_frags+0x69/0x140 net/core/gro.c:681
tun_napi_alloc_frags drivers/net/tun.c:1404 [inline]
tun_get_user+0x77c/0x3e70 drivers/net/tun.c:1784
tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:2003
aio_write+0x535/0x7a0 fs/aio.c:1633
__io_submit_one fs/aio.c:-1 [inline]
io_submit_one+0x775/0x1430 fs/aio.c:2052
__do_sys_io_submit fs/aio.c:2111 [inline]
__se_sys_io_submit+0x185/0x320 fs/aio.c:2081
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 10157:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kmem_cache_free+0x189/0x640 mm/slub.c:6295
kfree_skb_reason include/linux/skbuff.h:1322 [inline]
kfree_skb include/linux/skbuff.h:1331 [inline]
napi_free_frags include/linux/netdevice.h:4262 [inline]
__netif_napi_del_locked+0x2bb/0x3c0 net/core/dev.c:7684
__netif_napi_del include/linux/netdevice.h:2910 [inline]
netif_napi_del include/linux/netdevice.h:2928 [inline]
tun_napi_del drivers/net/tun.c:293 [inline]
tun_detach_all drivers/net/tun.c:671 [inline]
tun_net_uninit+0x566/0xa70 drivers/net/tun.c:953
unregister_netdevice_many_notify+0x1ce5/0x2340 net/core/dev.c:12452
rtnl_delete_link net/core/rtnetlink.c:3550 [inline]
rtnl_dellink+0x513/0x720 net/core/rtnetlink.c:3592
rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6994
netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x981/0xa00 net/socket.c:2592
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x19b/0x260 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888126d77900
which belongs to the cache skbuff_head_cache of size 240
The buggy address is located 228 bytes inside of
freed 240-byte region [ffff888126d77900, ffff888126d779f0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888126d77400 pfn:0x126d76
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff88811a8f8e01
flags: 0x17ff00000000240(workingset|head|node=0|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 017ff00000000240 ffff888101af5900 ffffea0005b48590 ffffea0005c35610
raw: ffff888126d77400 000000080019000d 00000000f5000000 ffff88811a8f8e01
head: 017ff00000000240 ffff888101af5900 ffffea0005b48590 ffffea0005c35610
head: ffff888126d77400 000000080019000d 00000000f5000000 ffff88811a8f8e01
head: 017ff00000000001 ffffea00049b5d81 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5283, tgid 5283 (udevadm), ts 18916143409, free_ts 16721349562
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x23d/0x2a0 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24e0/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x670 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x33a/0x3d0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e8/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
kmem_cache_alloc_node_noprof+0x443/0x6a0 mm/slub.c:4918
__alloc_skb+0x1d0/0x7d0 net/core/skbuff.c:702
alloc_skb include/linux/skbuff.h:1383 [inline]
alloc_uevent_skb+0x7d/0x230 lib/kobject_uevent.c:289
uevent_net_broadcast_untagged lib/kobject_uevent.c:326 [inline]
kobject_uevent_net_broadcast+0x2fa/0x560 lib/kobject_uevent.c:410
kobject_uevent_env+0x55c/0x9f0 lib/kobject_uevent.c:611
kobject_synth_uevent+0x527/0xb00 lib/kobject_uevent.c:207
bus_uevent_store+0x115/0x170 drivers/base/bus.c:910
kernfs_fop_write_iter+0x3af/0x540 fs/kernfs/file.c:352
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x5c9/0xb30 fs/read_write.c:688
ksys_write+0x145/0x250 fs/read_write.c:740
page last free pid 5331 tgid 5331 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0xc43/0xde0 mm/page_alloc.c:2978
__slab_free+0x263/0x2b0 mm/slub.c:5573
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_noprof+0x317/0x770 mm/slub.c:5272
kmalloc_noprof include/linux/slab.h:954 [inline]
tomoyo_realpath_from_path+0xe3/0x5d0 security/tomoyo/realpath.c:251
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_path_number_perm+0x1e8/0x5a0 security/tomoyo/file.c:728
security_file_ioctl+0xcb/0x2d0 security/security.c:2436
__do_sys_ioctl fs/ioctl.c:591 [inline]
__se_sys_ioctl+0x47/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff888126d77880: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
ffff888126d77900: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888126d77980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
^
ffff888126d77a00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
ffff888126d77a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply related
* Re: [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer
From: Antonio Quartulli @ 2026-04-23 13:43 UTC (permalink / raw)
To: Jakub Kicinski, Sabrina Dubroca
Cc: netdev, Ralf Lici, Paolo Abeni, Andrew Lunn, David S. Miller,
Eric Dumazet, Hyunwoo Kim
In-Reply-To: <7481bc31-44f6-43ae-b3aa-07002644d9e6@openvpn.net>
On 23/04/2026 14:16, Antonio Quartulli wrote:
> On 23/04/2026 04:20, Jakub Kicinski wrote:
>> On Wed, 22 Apr 2026 14:32:42 +0200 Antonio Quartulli wrote:
>>> + /* Prevent adding new peers while destroying the ovpn interface.
>>> + * Failing to do so would end up holding the device reference
>>> + * endlessly hostage of the new peer object with no chance of
>>> + * release..
>>> + */
>>> + if (ovpn->dev->reg_state >= NETREG_UNREGISTERING)
>>> + return -ENODEV;
>>
>> AI review suggests wrapping reg_state read in READ_ONCE(), I think
>> that's legit. Also nit: I think > or != REGISTERED would be more
>> idiomatic than comparing >= UNREGSITERING ?
>
> Agreed on READ_ONCE. Will fix it.
>
> As for your second point, I am fine with "!= REGISTERED" as that's the
> only state we should be accepting new peers in any case.
>
>>
>> If you agree make sure Sashiko doesn't complain about anything else
>> once it's public:
>> https://sashiko.dev/#/patchset/20260422123242.530882-2-
>> antonio@openvpn.net
>
> Is there any way to get earlier access to these reviews? (at least for
> patches somehow related to me/ovpn)
>
Dang! sashiko reminded me that I should swap cancel_delayed_work_sync
with disable_delayed_work_sync. Will fix that.
As for the second remarks..It has convincing arguments, but I need some
more time to think about it.
Sabrina, do you have an opinion?
Cheers,
>
> Thanks!
> Regards,
>
--
Antonio Quartulli
OpenVPN Inc.
^ permalink raw reply
* Re: [PATCH net] ipv4: clamp MCAST_MSFILTER getsockopt to optlen, not gf_numsrc
From: Paolo Abeni @ 2026-04-23 13:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, netdev
Cc: linux-kernel, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Simon Horman, stable
In-Reply-To: <2026042054-dime-spectator-820e@gregkh>
On 4/20/26 9:26 PM, Greg Kroah-Hartman wrote:
> @@ -1486,8 +1491,12 @@ static int compat_ip_get_mcast_msfilter(struct sock *sk, sockptr_t optval,
> gf.gf_interface = gf32.gf_interface;
> gf.gf_fmode = gf32.gf_fmode;
> num = gf.gf_numsrc = gf32.gf_numsrc;
> - gf.gf_group = gf32.gf_group;
>
> + if (num > (len - size0) / sizeof(struct sockaddr_storage))
> + num = (len - size0) / sizeof(struct sockaddr_storage);
> + gf.gf_numsrc = num;
Since this is exactly the same code added above, likely a common helper
would be useful.
I guess we don't care if this would break bad application passing optval
area properly sized for gf_numsrc sockets and a small optval, right? I
don't see how to eventually save them.
/P
^ permalink raw reply
* Re: [PATCH net v2 13/15] drivers: net: 8390: pcnet: Remove this driver
From: Dominik Brodowski @ 2026-04-23 14:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Geert Uytterhoeven, Michael Fritscher, Byron Stanoszek,
Daniel Palmer, linux-kernel, netdev, linux-doc
In-Reply-To: <97a5bd32-5080-4dd7-91c6-dcb65e154481@lunn.ch>
Am Thu, Apr 23, 2026 at 02:04:10PM +0200 schrieb Andrew Lunn:
> On Thu, Apr 23, 2026 at 07:49:24AM +0200, Dominik Brodowski wrote:
> > On Wed, Apr 22, 2026 at 01:01:56PM -0500, Andrew Lunn wrote:
> > > The pcnet was written by David A. Hindsh in 1999. It is an PCMCIA
> > > device, so unlikely to be used with modern kernels.
> > >
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > > ---
> > > drivers/net/ethernet/8390/Kconfig | 11 -
> > > drivers/net/ethernet/8390/Makefile | 1 -
> > > drivers/net/ethernet/8390/pcnet_cs.c | 1717 ----------------------------------
> >
> > NACK for this one. This is the most common PCMCIA networking device, so
> > should be removed only once the rest of the PCMCIA subsystem is removed.
>
> Please submit a patch to MAINTAINERS making yourself the Maintainer of
> this driver, if you want to keep it around.
Feel free to move the MAINTAINER entry for this to the PCMCIA subsystem, as
patches will be handled then via the PCMCIA tree anyway.
Best,
Dominik
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Paolo Abeni @ 2026-04-23 14:11 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, andrew+netdev, horms, corbet, skhan,
federico.vaga, carlos.bilbao, avadhut.naik, alexs, si.yanteng,
dzm91, 2023002089, tsbogend, dsahern, jani.nikula, mchehab+huawei,
gregkh, jirislaby, tytso, herbert, ebiggers, johannes.berg, geert,
pablo, tglx, mashiro.chen, mingo, dqfext, jreuter, sdf, pkshih,
enelsonmoore, mkl, toke, kees, crossd, jlayton, wangliang74,
aha310510, takamitz, kuniyu, linux-doc, linux-mips
In-Reply-To: <20260421021824.1293976-1-kuba@kernel.org>
On 4/21/26 4:18 AM, Jakub Kicinski wrote:
> @@ -2316,9 +2316,6 @@ struct net_device {
> #if IS_ENABLED(CONFIG_ATALK)
> void *atalk_ptr;
> #endif
> -#if IS_ENABLED(CONFIG_AX25)
> - struct ax25_dev __rcu *ax25_ptr;
> -#endif
AI reviews notes that this leaves behind a stray doxygen comment. I
think we are better off with a follow-up that with a v2.
/P
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free Write in sk_skb_reason_drop
From: Eric Dumazet @ 2026-04-23 14:13 UTC (permalink / raw)
To: Eulgyu Kim
Cc: davem, kuba, pabeni, horms, netdev, linux-kernel, byoungyoung,
jjy600901
In-Reply-To: <20260423134147.1933565-1-eulgyukim@snu.ac.kr>
On Thu, Apr 23, 2026 at 6:41 AM Eulgyu Kim <eulgyukim@snu.ac.kr> wrote:
>
> Hello,
>
> We encountered a "KASAN: slab-use-after-free Write in sk_skb_reason_drop"
> on kernel version v7.0.
>
> As this memory corruption bug seems to require `CAP_NET_ADMIN`,
> we report this in public mailing list.
>
> We have included the following items below:
> - C reproducer (~100 lines)
> - kernel delay patch
> - KASAN crash log
>
> To reliably trigger the race condition bug, we patched the kernel
> to inject a delay at a specific point.
>
> The kernel config used is the same as the syzbot configuration.
>
> Unfortunately, we do not have a fix ready for this bug yet.
> As this issue was identified via fuzzing and we have limited background,
> we find it challenging to propose a correct fix or evaluate
> its potential severity.
>
> We hope this report helps address the issue. Please let us know
> if any further information is needed.
It seems we need to add a barrier on tfile->napi_mutex
to prevent tun_napi_del() messing with concurrent tun_get_user()
Something like:
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index b183189f185354051bded95f43bd77ee4f7cde24..e85f9db4afe724e25f45e9b142fa678a244a533e
100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -289,8 +289,11 @@ static void tun_napi_disable(struct tun_file *tfile)
static void tun_napi_del(struct tun_file *tfile)
{
- if (tfile->napi_enabled)
+ if (tfile->napi_enabled) {
+ mutex_lock(&tfile->napi_mutex);
netif_napi_del(&tfile->napi);
+ mutex_unlock(&tfile->napi_mutex);
+ }
}
static bool tun_napi_frags_enabled(const struct tun_file *tfile)
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Paolo Abeni @ 2026-04-23 14:17 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, andrew+netdev, horms, corbet, skhan,
federico.vaga, carlos.bilbao, avadhut.naik, alexs, si.yanteng,
dzm91, 2023002089, tsbogend, dsahern, jani.nikula, mchehab+huawei,
gregkh, jirislaby, tytso, herbert, ebiggers, johannes.berg, geert,
pablo, tglx, mashiro.chen, mingo, dqfext, jreuter, sdf, pkshih,
enelsonmoore, mkl, toke, kees, crossd, jlayton, wangliang74,
aha310510, takamitz, kuniyu, linux-doc, linux-mips
In-Reply-To: <65cf5447-9876-40f8-a802-ed21b976a91c@redhat.com>
On 4/23/26 4:11 PM, Paolo Abeni wrote:
> On 4/21/26 4:18 AM, Jakub Kicinski wrote:
>> @@ -2316,9 +2316,6 @@ struct net_device {
>> #if IS_ENABLED(CONFIG_ATALK)
>> void *atalk_ptr;
>> #endif
>> -#if IS_ENABLED(CONFIG_AX25)
>> - struct ax25_dev __rcu *ax25_ptr;
>> -#endif
>
> AI reviews notes that this leaves behind a stray doxygen comment. I
> think we are better off with a follow-up that with a v2.
Or even better, I'll clean it up while applying it.
/P
^ permalink raw reply
* Re: [PATCH net] ipv4: clamp MCAST_MSFILTER getsockopt to optlen, not gf_numsrc
From: Greg Kroah-Hartman @ 2026-04-23 14:18 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, linux-kernel, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Simon Horman, stable
In-Reply-To: <17e348e1-b551-41e4-a512-906109dded4d@redhat.com>
On Thu, Apr 23, 2026 at 03:57:55PM +0200, Paolo Abeni wrote:
> On 4/20/26 9:26 PM, Greg Kroah-Hartman wrote:
> > @@ -1486,8 +1491,12 @@ static int compat_ip_get_mcast_msfilter(struct sock *sk, sockptr_t optval,
> > gf.gf_interface = gf32.gf_interface;
> > gf.gf_fmode = gf32.gf_fmode;
> > num = gf.gf_numsrc = gf32.gf_numsrc;
> > - gf.gf_group = gf32.gf_group;
> >
> > + if (num > (len - size0) / sizeof(struct sockaddr_storage))
> > + num = (len - size0) / sizeof(struct sockaddr_storage);
> > + gf.gf_numsrc = num;
>
> Since this is exactly the same code added above, likely a common helper
> would be useful.
Useful where else?
> I guess we don't care if this would break bad application passing optval
> area properly sized for gf_numsrc sockets and a small optval, right? I
> don't see how to eventually save them.
I couldn't see how to save them either, and if an application sends bad
data we should be rejecting it, right? Especially as this overflows
things as-is :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 net 2/3] net: mlx5e: fix CWR handling in drivers to preserve ACE signal
From: Dragos Tatulea @ 2026-04-23 14:19 UTC (permalink / raw)
To: Paolo Abeni, chia-yu.chang, linyunsheng, andrew+netdev, parav,
jasowang, mst, shenjian15, salil.mehta, shaojijie, saeedm, tariqt,
mbloch, leonro, linux-rdma, netdev, davem, edumazet, kuba, horms,
ij, ncardwell, koen.de_schepper, g.white, ingemar.s.johansson,
mirja.kuehlewind, cheshire, rs.ietf, Jason_Livingood, vidhi_goel
In-Reply-To: <69750ae3-3b0f-41c7-9731-6d49f5f6d319@redhat.com>
Hi Paolo and Chia-Yu,
On 23.04.26 09:30, Paolo Abeni wrote:
[...]
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>> index 5b60aa47c75b..9b1c80079532 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
>> @@ -1180,7 +1180,7 @@ static void mlx5e_shampo_update_ipv4_tcp_hdr(struct mlx5e_rq *rq, struct iphdr *
>> skb->csum_offset = offsetof(struct tcphdr, check);
>>
>> if (tcp->cwr)
>> - skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ECN;
>> + skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ACCECN;
>
> Here there is an open question for nVidia:
>
Sorry for missing this question in v3.
> Is the above enough or will later segmentation lead to the wrong
> results? I think/guess the firmware is (still) aggregating the wire
> frames using the ECN schema, i.e. the first wire packet has CWR == 1,
> the later CWR==0.
>
For mlx5 HW-GRO a packet with the CWR flag will flush the previous GRO session
and will not start a GRO session for this packet (napi_gro_receive() will be
called on this single segment skb).
So this change won't impact the current GRO behavior from the mlx5 driver/hw side.
Thanks,
Dragos
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free Write in sk_skb_reason_drop
From: Jiayuan Chen @ 2026-04-23 14:27 UTC (permalink / raw)
To: Eulgyu Kim, davem, edumazet, kuba, pabeni
Cc: horms, netdev, linux-kernel, byoungyoung, jjy600901
In-Reply-To: <20260423134147.1933565-1-eulgyukim@snu.ac.kr>
On 4/23/26 9:41 PM, Eulgyu Kim wrote:
> Hello,
>
> We encountered a "KASAN: slab-use-after-free Write in sk_skb_reason_drop"
> on kernel version v7.0.
>
> As this memory corruption bug seems to require `CAP_NET_ADMIN`,
> we report this in public mailing list.
>
> We have included the following items below:
> - C reproducer (~100 lines)
> - kernel delay patch
> - KASAN crash log
>
> To reliably trigger the race condition bug, we patched the kernel
> to inject a delay at a specific point.
>
> The kernel config used is the same as the syzbot configuration.
>
> Unfortunately, we do not have a fix ready for this bug yet.
> As this issue was identified via fuzzing and we have limited background,
> we find it challenging to propose a correct fix or evaluate
> its potential severity.
>
> We hope this report helps address the issue. Please let us know
> if any further information is needed.
>
> Thank you.
>
> Best Regards,
> Eulgyu Kim
>
>
>
> kernel delay patch:
> ==================================================================
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index c492fda6f..ba7078e18 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1891,6 +1891,10 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> !tfile->detached)
> rxhash = __skb_get_hash_symmetric(skb);
>
> + if (strcmp(current->comm, "slowme") == 0) {
> + mdelay(2000);
> + }
> +
> rcu_read_lock();
> if (unlikely(!(tun->dev->flags & IFF_UP))) {
> err = -EIO;
> ==================================================================
>
Hi Eulgyu,
I think this is caused by the lack of napi_mutex protection, and the
queue detach path seems to have the same issue.
The fix could be this:
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index b183189f1853..6a0bbd4def76 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -289,8 +289,12 @@ static void tun_napi_disable(struct tun_file *tfile)
static void tun_napi_del(struct tun_file *tfile)
{
- if (tfile->napi_enabled)
- netif_napi_del(&tfile->napi);
+ if (!tfile->napi_enabled)
+ return;
+
+ mutex_lock(&tfile->napi_mutex);
+ netif_napi_del(&tfile->napi);
+ mutex_unlock(&tfile->napi_mutex);
}
static bool tun_napi_frags_enabled(const struct tun_file *tfile)
@@ -1783,6 +1787,12 @@ static ssize_t tun_get_user(struct tun_struct
*tun, struct tun_file *tfile,
if (frags) {
mutex_lock(&tfile->napi_mutex);
+ if (unlikely(tfile->detached ||
+ rcu_access_pointer(tfile->tun) != tun)) {
+ err = -EBUSY;
+ mutex_unlock(&tfile->napi_mutex);
+ goto out;
+ }
skb = tun_napi_alloc_frags(tfile, copylen, from);
/* tun_napi_alloc_frags() enforces a layout for
the skb.
* If zerocopy is enabled, then this layout will be
@@ -1981,6 +1991,7 @@ static ssize_t tun_get_user(struct tun_struct
*tun, struct tun_file *tfile,
mutex_unlock(&tfile->napi_mutex);
}
+out:
return err ?: total_len;
}
^ permalink raw reply related
* Re: [PATCH v1 1/2] vfio: add callback to get tph info for dma-buf
From: Jason Gunthorpe @ 2026-04-23 14:28 UTC (permalink / raw)
To: Alex Williamson
Cc: Zhiping Zhang, Stanislav Fomichev, Keith Busch, Leon Romanovsky,
Bjorn Helgaas, linux-rdma, linux-pci, netdev, dri-devel,
Yochai Cohen, Yishai Hadas
In-Reply-To: <20260422132740.5f809bf7@shazbot.org>
On Wed, Apr 22, 2026 at 01:27:40PM -0600, Alex Williamson wrote:
> I don't know how to qualify the statement in the last paragraph about
> "[t]he only requirement is that the device limit the TPH to only the
> function that is perceiving them", though. Is that implicit in being
> associated to the dma-buf for the user owned device, or is it a
> property of the suggested steering tags, that we're not validating?
It is a property of VFs and VFIO.
For instance if an insane device allows a steering tag to reach
outside the VF's memory space then it can't really be used with VFIO.
> Steering tags can induce caching abuse, as interpreted in the
> interconnect fabric, but maybe we've already conceded that as
> fundamental aspect of TPH in general.
steering tags are opaque, we don't know what a device will do when it
receives them.
The common CPU issue is indeed cache abuse, but who knows what a
device will do with them.
> So why does vfio need to be involved in any of the sequence proposed
> here? It seems like it would be a much cleaner design, avoiding
> overloading the existing vfio feature and questionable array semantics,
> if there were a set-tph ioctl on the resulting dma-buf instead of
> making some vfio specific interface bundling creation with tph
> hints.
Realistically only VFIO dmabufs will have this property that user
space can set any TPH.
Other in-kernel drivers should accept some kind of hint from userspace
when creating their dmabuf that makes sense for their device, not a
raw TPH value. Like a GPU might accept a hint that specifies which
dielet or something like that.
So I don't see a generality here from that perspective. The generality
is that exporting drivers that can use TPH now have the option to tell
the importing driver to send them.
Jason
^ permalink raw reply
* Re: [PATCH 5.10.y] rxrpc: Fix recvmsg() unconditional requeue
From: Sasha Levin @ 2026-04-23 14:28 UTC (permalink / raw)
To: Jay Wang; +Cc: Sasha Levin, stable, David Howells, Marc Dionne, linux-afs,
netdev
In-Reply-To: <20260422222432.7236-1-wanjay@amazon.com>
On Wed, Apr 22, 2026 at 10:24:32PM +0000, Jay Wang wrote:
> From: David Howells <dhowells@redhat.com>
>
> [ Upstream commit 2c28769a51deb6022d7fbd499987e237a01dd63a ]
>
> If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the
> call at the front of the recvmsg queue already has its mutex locked,
> it requeues the call - whether or not the call is already queued.
Queued for 5.10, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net] ipv4: clamp MCAST_MSFILTER getsockopt to optlen, not gf_numsrc
From: Paolo Abeni @ 2026-04-23 14:29 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, linux-kernel, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Simon Horman, stable
In-Reply-To: <2026042345-prompter-boogieman-1f5e@gregkh>
On 4/23/26 4:18 PM, Greg Kroah-Hartman wrote:
> On Thu, Apr 23, 2026 at 03:57:55PM +0200, Paolo Abeni wrote:
>> On 4/20/26 9:26 PM, Greg Kroah-Hartman wrote:
>>> @@ -1486,8 +1491,12 @@ static int compat_ip_get_mcast_msfilter(struct sock *sk, sockptr_t optval,
>>> gf.gf_interface = gf32.gf_interface;
>>> gf.gf_fmode = gf32.gf_fmode;
>>> num = gf.gf_numsrc = gf32.gf_numsrc;
>>> - gf.gf_group = gf32.gf_group;
>>>
>>> + if (num > (len - size0) / sizeof(struct sockaddr_storage))
>>> + num = (len - size0) / sizeof(struct sockaddr_storage);
>>> + gf.gf_numsrc = num;
>>
>> Since this is exactly the same code added above, likely a common helper
>> would be useful.
>
> Useful where else?
Just in these 2 functions, to avoid duplicating the logic.
Not a big deal, but it would feel nicer. Also the
gf.gf_group = gf32.gf_group;
statement is moved around but such change is not needed, right?
>> I guess we don't care if this would break bad application passing optval
>> area properly sized for gf_numsrc sockets and a small optval, right? I
>> don't see how to eventually save them.
>
> I couldn't see how to save them either, and if an application sends bad
> data we should be rejecting it, right? Especially as this overflows
> things as-is :(
Agreed.
Thanks,
Paolo
^ permalink raw reply
* Re: [BUG] rxrpc: Client connection leak and BUG() call during kernel IO thread exit
From: arjan @ 2026-04-23 14:48 UTC (permalink / raw)
To: netdev
Cc: anderson, dhowells, marc.dionne, kuba, pabeni, linux-kernel,
jaltman, horms, Arjan van de Ven
In-Reply-To: <CAPhRvkyZGKHRTBhV3P2PCCRxmRKGEvJQ0W5a9SMW3qwS2hp2Qw@mail.gmail.com>
From: Arjan van de Ven <arjan@linux.intel.com>
This email is created by automation to help kernel developers deal
with a large volume of AI generated bug reports by decoding oopses
into more actionable information.
Decoded Backtrace
--- rxrpc_destroy_client_conn_ids (inlined into rxrpc_purge_client_connections)
Source: net/rxrpc/conn_client.c
54 static void rxrpc_destroy_client_conn_ids(struct rxrpc_local *local)
55 {
56 struct rxrpc_connection *conn;
57 int id;
58
59 if (!idr_is_empty(&local->conn_ids)) {
60 idr_for_each_entry(&local->conn_ids, conn, id) {
61 pr_err("AF_RXRPC: Leaked client conn %p {%d}\n",
62 conn, refcount_read(&conn->ref));
63 }
64 BUG(); // <- crash here
65 }
66
67 idr_destroy(&local->conn_ids);
68 }
--- rxrpc_destroy_local
Source: net/rxrpc/local_object.c
420 void rxrpc_destroy_local(struct rxrpc_local *local)
421 {
422 struct socket *socket = local->socket;
423 struct rxrpc_net *rxnet = local->rxnet;
...
427 local->dead = true;
...
433 rxrpc_clean_up_local_conns(local);
434 rxrpc_service_connection_reaper(&rxnet->service_conn_reaper);
435 ASSERT(!local->service);
...
450 rxrpc_purge_queue(&local->rx_queue);
451 rxrpc_purge_client_connections(local); // <- call here
452 page_frag_cache_drain(&local->tx_alloc);
453 }
--- rxrpc_io_thread
Source: net/rxrpc/io_thread.c
554 if (!list_empty(&local->new_client_calls))
555 rxrpc_connect_client_calls(local);
...
569 if (should_stop)
570 break;
...
596 __set_current_state(TASK_RUNNING);
598 rxrpc_destroy_local(local); // <- call here
601 return 0;
Tentative Analysis
The crash fires the unconditional BUG() at net/rxrpc/conn_client.c:64
because local->conn_ids is non-empty when rxrpc_destroy_local() is
called by the krxrpcio I/O thread during socket teardown.
When a client sendmsg() queues a call, the I/O thread picks it up via
rxrpc_connect_client_calls(). That function allocates a client
connection (rxrpc_alloc_client_connection()), registers it in the
local->conn_ids IDR with refcount=1, stores it in bundle->conns[], and
moves the call from new_client_calls to bundle->waiting_calls.
Once new_client_calls is empty and kthread_should_stop() is true, the
I/O thread exits its loop and calls rxrpc_destroy_local(). Inside that
function, rxrpc_clean_up_local_conns() iterates only the
local->idle_client_conns list. A connection that is in bundle->conns[]
but has never been activated on a channel (and thus never went idle) is
completely missed. rxrpc_purge_client_connections() then finds the
connection still registered in conn_ids and fires BUG().
The coverage gap was introduced by commit 9d35d880e0e4 ("rxrpc: Move
client call connection to the I/O thread"), which created a new
"allocated in bundle, not yet idle" state for connections that the
existing idle-list cleanup does not handle.
Note: fc9de52de38f ("rxrpc: Fix missing locking causing hanging calls"),
already present in 6.18.13, fixes a related missing-lock bug in the
same code area but does not address this idle-list coverage gap.
Potential Solution
rxrpc_clean_up_local_conns() should be extended to also release
connections stored in bundle->conns[] that have not yet appeared on
idle_client_conns. After the existing idle-list loop, the function
should iterate over all entries in local->client_bundles (the RB-tree
of active bundles), call rxrpc_unbundle_conn() on each occupied
bundle->conns[] slot, and put the connection. This ensures
rxrpc_destroy_client_conn_ids() always finds an empty IDR.
More information
Oops-Analysis: http://oops.fenrus.org/reports/lkml/CAPhRvkyZGKHRTBhV3P2PCCRxmRKGEvJQ0W5a9SMW3qwS2hp2Qw/
Assisted-by: GitHub-Copilot:claude-sonnet-4.6 linux-kernel-oops-x86.
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Paolo Abeni @ 2026-04-23 14:54 UTC (permalink / raw)
To: Andy Shevchenko, Jakub Kicinski
Cc: davem, netdev, edumazet, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, rdunlap, akpm, linux-doc, linux-mips,
linuxppc-dev, bridge, dwmw2
In-Reply-To: <aeh0CV3UQw1quCXv@ashevche-desk.local>
On 4/22/26 9:08 AM, Andy Shevchenko wrote:
> On Tue, Apr 21, 2026 at 09:18:44PM -0700, Jakub Kicinski wrote:
>> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
>> that are no longer in active use.
>>
>> The ATM core protocol stack, PPPoATM, BR2684, and USB DSL modem
>> drivers (drivers/usb/atm/) are retained in-tree to maintain PPP
>> over ATM (PPPoA) and PPPoE-over-BR2684 support for DSL connections.
>>
>> Removed ATM protocol modules:
>> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
>> - net/atm/lec.c - LAN Emulation Client (LANE)
>> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>>
>> Removed PCI/SBUS ATM device drivers (drivers/atm/):
>> - adummy, atmtcp - software/testing ATM devices
>> - eni - Efficient Networks ENI155P (OC-3, ~1995)
>> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
>> - he - ForeRunner HE (OC-3/OC-12, ~2000)
>> - idt77105 - IDT 77105 25 Mbps ATM PHY
>> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
>> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
>> - lanai - Efficient Networks Speedstream 3010
>> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
>> - solos-pci - Traverse Technologies ADSL2+ PCI
>> - suni - PMC S/UNI SONET PHY library
>>
>> Also clean up references in:
>> - net/bridge/ - remove ATM LANE hook (br_fdb_test_addr_hook,
>> br_fdb_test_addr)
>> - net/core/dev.c - remove br_fdb_test_addr_hook export
>> - defconfig files - remove ATM driver config options
>>
>> The removed code is moved to an out-of-tree module package (mod-orphan).
>>
>> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>> ---
>> v2:
>> - keep BR2684
>> - correct the claim that Traverse Technologies is defunct,
>> I'm still deleting the solos driver, chances are nobody uses it.
>> Easy enough to revert back in since core is still around.
>> The guiding principle is to keep USB modems and delete
>> the rest as USB ADSL2+ CPEs were most popular historically.
A possible alternative would be moving the solos driver (and others
similarly old, possibly not used anymore drivers into the staging dir
(and let them be removed after some reasonable grace period).
/P
^ permalink raw reply
* Re: [PATCH bpf-next v3 1/9] bpf: Unify dynptr handling in the verifier
From: Mykyta Yatsenko @ 2026-04-23 14:56 UTC (permalink / raw)
To: Amery Hung, bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, kernel-team
In-Reply-To: <20260421221016.2967924-2-ameryhung@gmail.com>
On 4/21/26 11:10 PM, Amery Hung wrote:
> Simplify dynptr checking for helper and kfunc by unifying it. Remember
> the initialized dynptr (i.e.,g !(arg_type |= MEM_UNINIT)) pass to a
> dynptr kfunc during process_dynptr_func() so that we can easily
> retrieve the information for verification later. By saving it in
> meta->dynptr, there is no need to call dynptr helpers such as
> dynptr_id(), dynptr_ref_obj_id() and dynptr_type() in check_func_arg().
>
> Remove and open code the helpers in process_dynptr_func() when
> saving id, ref_obj_id, and type. It is okay to drop spi < 0 check as
> is_dynptr_reg_valid_init() has made sure the dynptr is valid.
>
> Besides, since dynptr ref_obj_id information is now pass around in
> meta->bpf_dynptr_desc, drop the check in helper_multiple_ref_obj_use.
>
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---
Acked-by: Mykyta Yatsenko <yatsenko@meta.com>
> include/linux/bpf_verifier.h | 12 ++-
> kernel/bpf/verifier.c | 178 +++++++----------------------------
> 2 files changed, 41 insertions(+), 149 deletions(-)
>
> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> index b148f816f25b..dc0cff59246d 100644
> --- a/include/linux/bpf_verifier.h
> +++ b/include/linux/bpf_verifier.h
> @@ -1319,6 +1319,12 @@ struct bpf_map_desc {
> int uid;
> };
>
> +struct bpf_dynptr_desc {
> + enum bpf_dynptr_type type;
> + u32 id;
> + u32 ref_obj_id;
> +};
> +
> struct bpf_kfunc_call_arg_meta {
> /* In parameters */
> struct btf *btf;
> @@ -1359,16 +1365,12 @@ struct bpf_kfunc_call_arg_meta {
> struct {
> struct btf_field *field;
> } arg_rbtree_root;
> - struct {
> - enum bpf_dynptr_type type;
> - u32 id;
> - u32 ref_obj_id;
> - } initialized_dynptr;
> struct {
> u8 spi;
> u8 frameno;
> } iter;
> struct bpf_map_desc map;
> + struct bpf_dynptr_desc dynptr;
> u64 mem_size;
> };
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 185210b73385..41e4ea41c72e 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -232,6 +232,7 @@ static void bpf_map_key_store(struct bpf_insn_aux_data *aux, u64 state)
>
> struct bpf_call_arg_meta {
> struct bpf_map_desc map;
> + struct bpf_dynptr_desc dynptr;
> bool raw_mode;
> bool pkt_access;
> u8 release_regno;
> @@ -240,7 +241,6 @@ struct bpf_call_arg_meta {
> int mem_size;
> u64 msize_max_value;
> int ref_obj_id;
> - int dynptr_id;
> int func_id;
> struct btf *btf;
> u32 btf_id;
> @@ -434,11 +434,6 @@ static bool is_ptr_cast_function(enum bpf_func_id func_id)
> func_id == BPF_FUNC_skc_to_tcp_request_sock;
> }
>
> -static bool is_dynptr_ref_function(enum bpf_func_id func_id)
> -{
> - return func_id == BPF_FUNC_dynptr_data;
> -}
> -
> static bool is_sync_callback_calling_kfunc(u32 btf_id);
> static bool is_async_callback_calling_kfunc(u32 btf_id);
> static bool is_callback_calling_kfunc(u32 btf_id);
> @@ -507,8 +502,6 @@ static bool helper_multiple_ref_obj_use(enum bpf_func_id func_id,
> ref_obj_uses++;
> if (is_acquire_function(func_id, map))
> ref_obj_uses++;
> - if (is_dynptr_ref_function(func_id))
> - ref_obj_uses++;
>
> return ref_obj_uses > 1;
> }
> @@ -7433,7 +7426,8 @@ static int process_kptr_func(struct bpf_verifier_env *env, int regno,
> * and checked dynamically during runtime.
> */
> static int process_dynptr_func(struct bpf_verifier_env *env, int regno, int insn_idx,
> - enum bpf_arg_type arg_type, int clone_ref_obj_id)
> + enum bpf_arg_type arg_type, int clone_ref_obj_id,
> + struct bpf_dynptr_desc *dynptr)
> {
> struct bpf_reg_state *reg = reg_state(env, regno);
> int err;
> @@ -7499,6 +7493,20 @@ static int process_dynptr_func(struct bpf_verifier_env *env, int regno, int insn
> }
>
> err = mark_dynptr_read(env, reg);
> +
> + if (dynptr) {
> + struct bpf_func_state *state = bpf_func(env, reg);
> + int spi;
> +
> + if (reg->type != CONST_PTR_TO_DYNPTR) {
> + spi = dynptr_get_spi(env, reg);
> + reg = &state->stack[spi].spilled_ptr;
> + }
> +
> + dynptr->id = reg->id;
> + dynptr->type = reg->dynptr.type;
> + dynptr->ref_obj_id = reg->ref_obj_id;
> + }
> }
> return err;
> }
> @@ -8263,72 +8271,6 @@ static int check_func_arg_reg_off(struct bpf_verifier_env *env,
> }
> }
>
> -static struct bpf_reg_state *get_dynptr_arg_reg(struct bpf_verifier_env *env,
> - const struct bpf_func_proto *fn,
> - struct bpf_reg_state *regs)
> -{
> - struct bpf_reg_state *state = NULL;
> - int i;
> -
> - for (i = 0; i < MAX_BPF_FUNC_REG_ARGS; i++)
> - if (arg_type_is_dynptr(fn->arg_type[i])) {
> - if (state) {
> - verbose(env, "verifier internal error: multiple dynptr args\n");
> - return NULL;
> - }
> - state = ®s[BPF_REG_1 + i];
> - }
> -
> - if (!state)
> - verbose(env, "verifier internal error: no dynptr arg found\n");
> -
> - return state;
> -}
> -
> -static int dynptr_id(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
> -{
> - struct bpf_func_state *state = bpf_func(env, reg);
> - int spi;
> -
> - if (reg->type == CONST_PTR_TO_DYNPTR)
> - return reg->id;
> - spi = dynptr_get_spi(env, reg);
> - if (spi < 0)
> - return spi;
> - return state->stack[spi].spilled_ptr.id;
> -}
> -
> -static int dynptr_ref_obj_id(struct bpf_verifier_env *env, struct bpf_reg_state *reg)
> -{
> - struct bpf_func_state *state = bpf_func(env, reg);
> - int spi;
> -
> - if (reg->type == CONST_PTR_TO_DYNPTR)
> - return reg->ref_obj_id;
> - spi = dynptr_get_spi(env, reg);
> - if (spi < 0)
> - return spi;
> - return state->stack[spi].spilled_ptr.ref_obj_id;
> -}
> -
> -static enum bpf_dynptr_type dynptr_get_type(struct bpf_verifier_env *env,
> - struct bpf_reg_state *reg)
> -{
> - struct bpf_func_state *state = bpf_func(env, reg);
> - int spi;
> -
> - if (reg->type == CONST_PTR_TO_DYNPTR)
> - return reg->dynptr.type;
> -
> - spi = bpf_get_spi(reg->var_off.value);
> - if (spi < 0) {
> - verbose(env, "verifier internal error: invalid spi when querying dynptr type\n");
> - return BPF_DYNPTR_TYPE_INVALID;
> - }
> -
> - return state->stack[spi].spilled_ptr.dynptr.type;
> -}
> -
> static int check_reg_const_str(struct bpf_verifier_env *env,
> struct bpf_reg_state *reg, u32 regno)
> {
> @@ -8683,7 +8625,7 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
> true, meta);
> break;
> case ARG_PTR_TO_DYNPTR:
> - err = process_dynptr_func(env, regno, insn_idx, arg_type, 0);
> + err = process_dynptr_func(env, regno, insn_idx, arg_type, 0, &meta->dynptr);
> if (err)
> return err;
> break;
> @@ -9342,7 +9284,7 @@ static int btf_check_func_arg_match(struct bpf_verifier_env *env, int subprog,
> if (ret)
> return ret;
>
> - ret = process_dynptr_func(env, regno, -1, arg->arg_type, 0);
> + ret = process_dynptr_func(env, regno, -1, arg->arg_type, 0, NULL);
> if (ret)
> return ret;
> } else if (base_type(arg->arg_type) == ARG_PTR_TO_BTF_ID) {
> @@ -10429,52 +10371,10 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
> }
> }
> break;
> - case BPF_FUNC_dynptr_data:
> - {
> - struct bpf_reg_state *reg;
> - int id, ref_obj_id;
> -
> - reg = get_dynptr_arg_reg(env, fn, regs);
> - if (!reg)
> - return -EFAULT;
> -
> -
> - if (meta.dynptr_id) {
> - verifier_bug(env, "meta.dynptr_id already set");
> - return -EFAULT;
> - }
> - if (meta.ref_obj_id) {
> - verifier_bug(env, "meta.ref_obj_id already set");
> - return -EFAULT;
> - }
> -
> - id = dynptr_id(env, reg);
> - if (id < 0) {
> - verifier_bug(env, "failed to obtain dynptr id");
> - return id;
> - }
> -
> - ref_obj_id = dynptr_ref_obj_id(env, reg);
> - if (ref_obj_id < 0) {
> - verifier_bug(env, "failed to obtain dynptr ref_obj_id");
> - return ref_obj_id;
> - }
> -
> - meta.dynptr_id = id;
> - meta.ref_obj_id = ref_obj_id;
> -
> - break;
> - }
> case BPF_FUNC_dynptr_write:
> {
> - enum bpf_dynptr_type dynptr_type;
> - struct bpf_reg_state *reg;
> + enum bpf_dynptr_type dynptr_type = meta.dynptr.type;
>
> - reg = get_dynptr_arg_reg(env, fn, regs);
> - if (!reg)
> - return -EFAULT;
> -
> - dynptr_type = dynptr_get_type(env, reg);
> if (dynptr_type == BPF_DYNPTR_TYPE_INVALID)
> return -EFAULT;
>
> @@ -10665,10 +10565,7 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
> return -EFAULT;
> }
>
> - if (is_dynptr_ref_function(func_id))
> - regs[BPF_REG_0].dynptr_id = meta.dynptr_id;
> -
> - if (is_ptr_cast_function(func_id) || is_dynptr_ref_function(func_id)) {
> + if (is_ptr_cast_function(func_id)) {
> /* For release_reference() */
> regs[BPF_REG_0].ref_obj_id = meta.ref_obj_id;
> } else if (is_acquire_function(func_id, meta.map.ptr)) {
> @@ -10682,6 +10579,11 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
> regs[BPF_REG_0].ref_obj_id = id;
> }
>
> + if (func_id == BPF_FUNC_dynptr_data) {
> + regs[BPF_REG_0].dynptr_id = meta.dynptr.id;
> + regs[BPF_REG_0].ref_obj_id = meta.dynptr.ref_obj_id;
> + }
> +
> err = do_refine_retval_range(env, regs, fn->ret_type, func_id, &meta);
> if (err)
> return err;
> @@ -12260,7 +12162,7 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> meta->release_regno = regno;
> } else if (meta->func_id == special_kfunc_list[KF_bpf_dynptr_clone] &&
> (dynptr_arg_type & MEM_UNINIT)) {
> - enum bpf_dynptr_type parent_type = meta->initialized_dynptr.type;
> + enum bpf_dynptr_type parent_type = meta->dynptr.type;
>
> if (parent_type == BPF_DYNPTR_TYPE_INVALID) {
> verifier_bug(env, "no dynptr type for parent of clone");
> @@ -12268,29 +12170,17 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> }
>
> dynptr_arg_type |= (unsigned int)get_dynptr_type_flag(parent_type);
> - clone_ref_obj_id = meta->initialized_dynptr.ref_obj_id;
> + clone_ref_obj_id = meta->dynptr.ref_obj_id;
> if (dynptr_type_refcounted(parent_type) && !clone_ref_obj_id) {
> verifier_bug(env, "missing ref obj id for parent of clone");
> return -EFAULT;
> }
> }
>
> - ret = process_dynptr_func(env, regno, insn_idx, dynptr_arg_type, clone_ref_obj_id);
> + ret = process_dynptr_func(env, regno, insn_idx, dynptr_arg_type, clone_ref_obj_id,
> + &meta->dynptr);
> if (ret < 0)
> return ret;
> -
> - if (!(dynptr_arg_type & MEM_UNINIT)) {
> - int id = dynptr_id(env, reg);
> -
> - if (id < 0) {
> - verifier_bug(env, "failed to obtain dynptr id");
> - return id;
> - }
> - meta->initialized_dynptr.id = id;
> - meta->initialized_dynptr.type = dynptr_get_type(env, reg);
> - meta->initialized_dynptr.ref_obj_id = dynptr_ref_obj_id(env, reg);
> - }
> -
> break;
> }
> case KF_ARG_PTR_TO_ITER:
> @@ -12894,7 +12784,7 @@ static int check_special_kfunc(struct bpf_verifier_env *env, struct bpf_kfunc_ca
> }
> } else if (meta->func_id == special_kfunc_list[KF_bpf_dynptr_slice] ||
> meta->func_id == special_kfunc_list[KF_bpf_dynptr_slice_rdwr]) {
> - enum bpf_type_flag type_flag = get_dynptr_type_flag(meta->initialized_dynptr.type);
> + enum bpf_type_flag type_flag = get_dynptr_type_flag(meta->dynptr.type);
>
> mark_reg_known_zero(env, regs, BPF_REG_0);
>
> @@ -12918,11 +12808,11 @@ static int check_special_kfunc(struct bpf_verifier_env *env, struct bpf_kfunc_ca
> }
> }
>
> - if (!meta->initialized_dynptr.id) {
> + if (!meta->dynptr.id) {
> verifier_bug(env, "no dynptr id");
> return -EFAULT;
> }
> - regs[BPF_REG_0].dynptr_id = meta->initialized_dynptr.id;
> + regs[BPF_REG_0].dynptr_id = meta->dynptr.id;
>
> /* we don't need to set BPF_REG_0's ref obj id
> * because packet slices are not refcounted (see
> @@ -13110,7 +13000,7 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> if (meta.release_regno) {
> struct bpf_reg_state *reg = ®s[meta.release_regno];
>
> - if (meta.initialized_dynptr.ref_obj_id) {
> + if (meta.dynptr.ref_obj_id) {
> err = unmark_stack_slots_dynptr(env, reg);
> } else {
> err = release_reference(env, reg->ref_obj_id);
^ permalink raw reply
* Re: Help with PCIe THP on ConnectX-7
From: Yishai Hadas @ 2026-04-23 14:55 UTC (permalink / raw)
To: bmerry, netdev
In-Reply-To: <aejnzWR_szvAOxkK@brucemerry.org.za>
On 22/04/2026 18:22, Bruce Merry wrote:
> Hello
>
> I'm hoping someone from NVIDIA Networking can help with this; I wasn't
> sure of the best way to get in contact with the engineers working on
> mlx5 kernel code so thought I'd try here. I'm trying to write some
> (userspace) code using ibv_reg_mr_ex to register a memory region using
> TLP Processing Hints (THP) to improve performance on an Epyc Turin
> (Zen 5) system. However, in the kernel mlx5_st_create is bailing out
> because of this check:
>
> if (!MLX5_CAP_GEN(dev, mkey_pcie_tph))
> return NULL;
>
> As far as I can tell, that is checking a capability bit returned by
> the firmware.
Right
>
> Before I spend a lot more time debugging, can you tell me whether
> ConnectX-7 supports this feature at all (I'm on the latest 28.48.1000
> firmware)? I see it mentioned in release notes for ConnectX-8
> firmware, but not in ConnectX-7 release notes.
>
It's supported only on CX8 for now.
Yishai
> If ConnectX-7 does support it, do you have any tips on what might
> cause that capability bit to be false and how to determine what the
> cause is? For example, could that happen if the motherboard BIOS
> doesn't support TPH?
>
> Thanks
> Bruce
^ permalink raw reply
* Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: Willem de Bruijn @ 2026-04-23 14:59 UTC (permalink / raw)
To: Mingyu Wang, willemdebruijn.kernel, davem, dsahern, edumazet,
kuba, pabeni
Cc: sd, horms, netdev, linux-kernel, Mingyu Wang,
syzbot+e5d6936b9f4545fd88ab
In-Reply-To: <20260423082233.514056-1-25181214217@stu.xidian.edu.cn>
Mingyu Wang wrote:
> During fuzzing with failslab enabled, a memory leak was observed in the
> IPv6 UDP send path.
>
> The root cause resides in __ip6_make_skb(). In extremely rare cases
> (such as fault injection or specific empty payload conditions),
Can you elaborate on this? Which fault injection lets
__ip6_append_data succeed without writing data?
> __ip6_append_data() may succeed but leave the socket's write queue
> empty.
>
> When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
> returns NULL. The previous logic handled this by executing a 'goto out;',
> which completely bypassed the call to ip6_cork_release(cork).
>
> Since the 'cork' structure actively holds a reference to the routing
> entry (dst_entry) and potentially other allocated options, skipping
> the release cleanly leaks these resources.
>
> Fix this by introducing an 'out_cork_release' label and jumping to it
> when skb is NULL, ensuring the cork state is always properly cleaned up.
> The now-unused 'out' label is also removed to prevent compiler warnings.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
I think this is
Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
> Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox