On 26.8.2019 11.09, Schmid, Carsten wrote:
Upstream version of driver is identical in the affected code. Fix was tested successfully on 4.14.129. Provided patch applies and compiles on v5.2.8 stable. As this is also a bugfix, please consider it to go to stable trees too.How far back should it go, just 4.14? Was this caused by a specific commit that you happened to notice?To me it looks like the causing commit was added to 4.17: fa31b3c xhci: Add Intel extended cap / otg phy mux handling Carsten, was the issue reproduced on upstream linux stable 4.14.129, or on some custom tree with backports? -MathiasThe issue was reproduced on a custom kernel. The commit you give "xhci: Add Intel extended cap / otg phy mux handling" is part of a merge from 4.14/usb to 4.14/yocto in this custom kernel. Hard to tell exactly where it came in. Anyway, you are right, looks like upstream 4.14 doesn't have it. So 4.19 seems to be the oldest one, indeed. For me, i am fine to know that the patch will go upstream and avoid curious crashes through this use-after-free in the future. I'm pretty sure that this could be reproduced with the upstream kernel as the mechanism is deterministic. In our project, due to a crash that happened short before SOP and i did not have time to figure out where the problem originally came from, i did a really dirty hack setting the num_resource=0 of the platform device prior to platform removal code. Helps but is really, really dirty. And now as you accept the patch for upstream i can replace the dirty hack by the official patch for next SOP.
Thanks for fixing this, it solves a real upstream xhci related issue since 4.19.
Fix is outside xhci so accepting this is no longer up to me, but for Greg:
Reviewed-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Fixes: fa31b3cb2ae1 ("xhci: Add Intel extended cap / otg phy mux handling")
Cc: <stable@xxxxxxxxxxxxxxx> # v4.19+
