On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resorce of
the xhci-ext-caps driver in the platform removal
because the parent of the resource was freed earlier.
Fix this by reordering of the removal sequence.
Signed-off-by: Carsten Schmid <carsten_schmid@xxxxxxxxxx>
Assuming this has been tested, overal this looks good to me.
Tested on 4.14.129, ported to v5.2.7, compiled there.
But there are 2 things to fix:
1) Maybe pick a more descriptive struct member name then pdev.
pdev with pci-devices often points to a pci_device ...
How about: role_switch_pdev ?
Ok, good point. Had platform dev pdev in mind ...
2) xhci_ext_cap_init() is not the last call which can fail in
xhci_pci_probe(), since you now no longer use
devm_add_action_or_reset
for auto-cleanup, you must now manually cleanup by calling
xhci_ext_cap_remove() when later steps of xhci_pci_probe() fail.
it looks like you will need a new ext_cap_remove error-exit label
for this put above the put_usb3_hcd label and goto this new label
instead of to put_usb3_hcd in all error paths after a successful call
to xhci_ext_cap_init()
Right. Will review this path and correct accordingly.
Maybe an additional label isn't required because pdev is only set when
xhci_ext_cap_init created the platform device, and xhci_ext_cap_remove
checks for pdev being set.
So a call to xhci_ext_cap_remove doesn't harm if pdev is not set up yet.
But for readability it might be better to create a label.