Re: [Intel-wired-lan] [PATCH net] idpf: fix double free and use-after-free in aux device error paths

From: Jacob Keller

Date: Mon Apr 13 2026 - 20:47:11 EST


On 4/11/2026 3:12 AM, Greg Kroah-Hartman wrote:
> When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or
> idpf_plug_core_aux_dev(), the err_aux_dev_add label calls
> auxiliary_device_uninit() and falls through to err_aux_dev_init. The
> uninit call will trigger put_device(), which invokes the release
> callback (idpf_vport_adev_release / idpf_core_adev_release) that frees
> iadev. The fall-through then reads adev->id from the freed iadev for
> ida_free() and double-frees iadev with kfree().
>
> Free the IDA slot and clear the back-pointer before uninit, while adev
> is still valid, then return immediately.
>
> Commit 65637c3a1811 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev
> deinitialization") fixed the same use-after-free in the matching unplug
> path in this file but missed both probe error paths.
>
> Cc: Tony Nguyen <anthony.l.nguyen@xxxxxxxxx>
> Cc: Przemek Kitszel <przemyslaw.kitszel@xxxxxxxxx>
> Cc: Andrew Lunn <andrew+netdev@xxxxxxx>
> Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
> Cc: Eric Dumazet <edumazet@xxxxxxxxxx>
> Cc: Jakub Kicinski <kuba@xxxxxxxxxx>
> Cc: Paolo Abeni <pabeni@xxxxxxxxxx>
> Cc: stable <stable@xxxxxxxxxx>
> Fixes: be91128c579c ("idpf: implement RDMA vport auxiliary dev create, init, and destroy")
> Fixes: f4312e6bfa2a ("idpf: implement core RDMA auxiliary dev create, init, and destroy")
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> ---

This is targeted at [net]. The fix seems straight forward enough.
@Jakub, I have no objections if you want to pull this directly. I am not
sure our validation team will find anything when testing since this is
an error path that is historically been difficult for us to test.

I'm also fine with taking it through iwl-net if you prefer, but just
want to avoid duplicate work if you're already considering it.

> Note, these cleanup paths are messy, but I couldn't see a simpler way
> without a lot more rework, so I choose the simple way :)
>

Yea, I didn't see a better way either.

Thanks,
Jake