> > 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. Best regards Carsten
