In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below):
Call Trace: releasenodes+0x11/0x70 devresreleasegroup+0xb2/0x110 componentunbindall+0x8d/0xa0 componentdel+0xa5/0x140 intelpxpteecomponentfini+0x29/0x40 [i915] intelpxpfini+0x33/0x80 [i915] i915driverremove+0x4c/0x120 [i915] i915pciremove+0x19/0x30 [i915] pcideviceremove+0x32/0xa0 devicereleasedriverinternal+0x19c/0x200 unbindstore+0x9c/0xb0
and
Call Trace: releasenodes+0x11/0x70 devresreleaseall+0x8a/0xc0 deviceunbindcleanup+0x9/0x70 devicereleasedriverinternal+0x1c1/0x200 unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind.
v2: Change commit message and other minor code changes v3: Cleanup from i915hwmonregister on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetchandzero (Jani) v5: Restore previous logic for ddatgt->hwmondev error return (Andi)