On Mon, Oct 13, 2025 at 08:08:24AM -0700, Emil Tantilov wrote:
> Attempting to remove the driver will cause a crash in cases where
> the vport failed to initialize. Following trace is from an instance where
> the driver failed during an attempt to create a VF:
> [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated
> [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900
> vc_op:1 salt:29 timeout:60000ms)
> [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028
> ...
> [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf]
> ...
> [ 1723.364973] Call Trace:
> [ 1723.365475] <TASK>
> [ 1723.365972] pci_device_remove+0x42/0xb0
> [ 1723.366481] device_release_driver_internal+0x1a9/0x210
> [ 1723.366987] pci_stop_bus_device+0x6d/0x90
> [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20
> [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120
> [ 1723.368309] sriov_disable+0x34/0xe0
> [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf]
> [ 1723.368982] sriov_numvfs_store+0xda/0x1c0
>
> Avoid the NULL pointer dereference by adding NULL pointer check for
> vport_config[i], before freeing user_config.q_coalesce.
>
> Fixes: e1e3fec3e34b ("idpf: preserve coalescing settings across resets")
> Signed-off-by: Emil Tantilov <[email protected]>
> Reviewed-by: Chittim Madhu <[email protected]>
Thanks,
I agree that prior to the cited commit adapter->vport_config[i] being
NULL was harmless. But afterwards a NULL pointer dereference would occur.
It also seems to me that the possibility of adapter->vport_config[i]
being null, via an error in idpf_vport_alloc() has existed since
vport configuration was added by commit 0fe45467a104 ("idpf: add create
vport and netdev configuration"). (Which predates the cited commit.)
Reviewed-by: Simon Horman <[email protected]>
