[PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

[PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

[David Carlier]

idpf_idc_vport_dev_ctrl(adapter, false) clears vport->vdev_info->adev
to NULL but keeps vport->vdev_info itself. An MTU change after that
calls idpf_idc_vdev_mtu_event(), which dereferences vdev_info->adev for
device_lock() before reaching the (!adev || ...) check.

Cache vdev_info->adev once with READ_ONCE() and bail out if NULL before
locking. Use the cached pointer on both the lock and unlock paths so
the unlock matches the device actually acquired and cannot re-fetch a
NULL slot.

Fixes: ed6e1c8796a4 ("idpf: implement IDC vport aux driver MTU change handler")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
v2: cache vdev_info->adev with READ_ONCE() to avoid double-fetch and
    use the cached pointer on the unlock path (Alok Tiwari)
---
 drivers/net/ethernet/intel/idpf/idpf_idc.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c
index b7d6b08fc89e..9f764135507c 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
@@ -162,9 +162,12 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
 
 	set_bit(event_type, event.type);
 
-	device_lock(&vdev_info->adev->dev);
-	adev = vdev_info->adev;
-	if (!adev || !adev->dev.driver)
+	adev = READ_ONCE(vdev_info->adev);
+	if (!adev)
+		return;
+
+	device_lock(&adev->dev);
+	if (!adev->dev.driver)
 		goto unlock;
 	iadrv = container_of(adev->dev.driver,
 			     struct iidc_rdma_vport_auxiliary_drv,
@@ -172,7 +175,7 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
 	if (iadrv->event_handler)
 		iadrv->event_handler(vdev_info, &event);
 unlock:
-	device_unlock(&vdev_info->adev->dev);
+	device_unlock(&adev->dev);
 }
 
 /**
-- 
2.53.0

RE: [Intel-wired-lan] [PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of David Carlier
> Sent: Thursday, May 14, 2026 8:30 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; horms@kernel.org; intel-wired-
> lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; David Carlier
> <devnexen@gmail.com>
> Subject: [Intel-wired-lan] [PATCH net v2] idpf: handle NULL adev in
> idpf_idc_vdev_mtu_event
> 
> idpf_idc_vport_dev_ctrl(adapter, false) clears vport->vdev_info->adev
> to NULL but keeps vport->vdev_info itself. An MTU change after that
> calls idpf_idc_vdev_mtu_event(), which dereferences vdev_info->adev
> for
> device_lock() before reaching the (!adev || ...) check.
> 
> Cache vdev_info->adev once with READ_ONCE() and bail out if NULL
> before locking. Use the cached pointer on both the lock and unlock
> paths so the unlock matches the device actually acquired and cannot
> re-fetch a NULL slot.
> 
> Fixes: ed6e1c8796a4 ("idpf: implement IDC vport aux driver MTU change
> handler")
> Cc: stable@vger.kernel.org
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
> v2: cache vdev_info->adev with READ_ONCE() to avoid double-fetch and
>     use the cached pointer on the unlock path (Alok Tiwari)
> ---
>  drivers/net/ethernet/intel/idpf/idpf_idc.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c
> b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> index b7d6b08fc89e..9f764135507c 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> @@ -162,9 +162,12 @@ void idpf_idc_vdev_mtu_event(struct
> iidc_rdma_vport_dev_info *vdev_info,
> 
>  	set_bit(event_type, event.type);
> 
> -	device_lock(&vdev_info->adev->dev);
> -	adev = vdev_info->adev;
> -	if (!adev || !adev->dev.driver)
> +	adev = READ_ONCE(vdev_info->adev);
> +	if (!adev)
> +		return;
> +
> +	device_lock(&adev->dev);
> +	if (!adev->dev.driver)
>  		goto unlock;
>  	iadrv = container_of(adev->dev.driver,
>  			     struct iidc_rdma_vport_auxiliary_drv, @@ -
> 172,7 +175,7 @@ void idpf_idc_vdev_mtu_event(struct
> iidc_rdma_vport_dev_info *vdev_info,
>  	if (iadrv->event_handler)
>  		iadrv->event_handler(vdev_info, &event);
>  unlock:
> -	device_unlock(&vdev_info->adev->dev);
> +	device_unlock(&adev->dev);
>  }
> 
>  /**
> --
> 2.53.0

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Re: [PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

[Simon Horman]

From: 'Simon Horman' <horms@kernel.org>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
idpf: handle NULL adev in idpf_idc_vdev_mtu_event

This commit attempts to fix a NULL pointer dereference in the MTU event
handler by caching the auxiliary device pointer using READ_ONCE(). It avoids
dereferencing a NULL pointer if the device is cleared concurrently by
idpf_idc_vport_dev_ctrl().

> diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> index b7d6b08fc89e8..9f764135507c2 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> @@ -162,9 +162,12 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
>  
>  	set_bit(event_type, event.type);
>  
> -	device_lock(&vdev_info->adev->dev);
> -	adev = vdev_info->adev;
> -	if (!adev || !adev->dev.driver)
> +	adev = READ_ONCE(vdev_info->adev);
> +	if (!adev)
> +		return;
> +
> +	device_lock(&adev->dev);

The commit message indicates that idpf_idc_vport_dev_ctrl() and MTU changes
can run concurrently. Does caching the adev pointer with READ_ONCE() provide
enough protection against the device memory being freed?

If idpf_idc_vport_dev_ctrl() unregisters and frees the auxiliary device
immediately after READ_ONCE() reads a non-NULL pointer, could
device_lock(&adev->dev) then operate on a freed device?

Would it be necessary to increment the device's reference count, perhaps
using get_device() or holding a broader lock, before accessing adev->dev to
prevent a use-after-free regression?

Re: [PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

[David CARLIER]

> This is an AI-generated review of your patch. The human sending this
  > email has considered the AI review valid, or at least plausible.

  Thanks for relaying this, Simon.

  The scenario this patch fixes is sequential, not concurrent:
  idpf_idc_vport_dev_ctrl(adapter, false) has already returned and
  vdev_info->adev is NULL by the time ndo_change_mtu reaches
  idpf_idc_vdev_mtu_event(). The original code dereferenced
  vdev_info->adev in device_lock() before the NULL check and oopses
  deterministically; READ_ONCE() + early-return resolves that.

  A truly concurrent idpf_idc_vport_dev_ctrl(_, false) racing an
  in-flight MTU event is a separate, pre-existing window: the original
  code took no reference between reading vdev_info->adev and
  dereferencing it either, so this patch neither introduces nor widens
  it. I haven't constructed a concrete interleaving against auxiliary-bus
  teardown and have no report of it triggering.

  Happy to post a follow-up bracketing the handler with
  get_device()/put_device() if you'd prefer, but I'd rather keep this
  one scoped to the Fixes: target.

Cheers.

Re: [PATCH net v2] idpf: handle NULL adev in idpf_idc_vdev_mtu_event

[Simon Horman]

On Tue, May 19, 2026 at 09:19:23PM +0100, David CARLIER wrote:
> > This is an AI-generated review of your patch. The human sending this
>   > email has considered the AI review valid, or at least plausible.
> 
>   Thanks for relaying this, Simon.
> 
>   The scenario this patch fixes is sequential, not concurrent:
>   idpf_idc_vport_dev_ctrl(adapter, false) has already returned and
>   vdev_info->adev is NULL by the time ndo_change_mtu reaches
>   idpf_idc_vdev_mtu_event(). The original code dereferenced
>   vdev_info->adev in device_lock() before the NULL check and oopses
>   deterministically; READ_ONCE() + early-return resolves that.
> 
>   A truly concurrent idpf_idc_vport_dev_ctrl(_, false) racing an
>   in-flight MTU event is a separate, pre-existing window: the original
>   code took no reference between reading vdev_info->adev and
>   dereferencing it either, so this patch neither introduces nor widens
>   it. I haven't constructed a concrete interleaving against auxiliary-bus
>   teardown and have no report of it triggering.
> 
>   Happy to post a follow-up bracketing the handler with
>   get_device()/put_device() if you'd prefer, but I'd rather keep this
>   one scoped to the Fixes: target.

Hi David,

Thanks for the clarification.
I agree we can treat concurrency as a separate issue.