CVE-2024-39479

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/hwmon: Get rid of devm<br /> <br /> When both hwmon and hwmon drvdata (on which hwmon depends) are device<br /> managed resources, the expectation, on device unbind, is that hwmon will be<br /> released before drvdata. However, in i915 there are two separate code<br /> paths, which both release either drvdata or hwmon and either can be<br /> released before the other. These code paths (for device unbind) are as<br /> follows (see also the bug referenced below):<br /> <br /> Call Trace:<br /> release_nodes+0x11/0x70<br /> devres_release_group+0xb2/0x110<br /> component_unbind_all+0x8d/0xa0<br /> component_del+0xa5/0x140<br /> intel_pxp_tee_component_fini+0x29/0x40 [i915]<br /> intel_pxp_fini+0x33/0x80 [i915]<br /> i915_driver_remove+0x4c/0x120 [i915]<br /> i915_pci_remove+0x19/0x30 [i915]<br /> pci_device_remove+0x32/0xa0<br /> device_release_driver_internal+0x19c/0x200<br /> unbind_store+0x9c/0xb0<br /> <br /> and<br /> <br /> Call Trace:<br /> release_nodes+0x11/0x70<br /> devres_release_all+0x8a/0xc0<br /> device_unbind_cleanup+0x9/0x70<br /> device_release_driver_internal+0x1c1/0x200<br /> unbind_store+0x9c/0xb0<br /> <br /> This means that in i915, if use devm, we cannot gurantee that hwmon will<br /> always be released before drvdata. Which means that we have a uaf if hwmon<br /> sysfs is accessed when drvdata has been released but hwmon hasn&amp;#39;t.<br /> <br /> The only way out of this seems to be do get rid of devm_ and release/free<br /> everything explicitly during device unbind.<br /> <br /> v2: Change commit message and other minor code changes<br /> v3: Cleanup from i915_hwmon_register on error (Armin Wolf)<br /> v4: Eliminate potential static analyzer warning (Rodrigo)<br /> Eliminate fetch_and_zero (Jani)<br /> v5: Restore previous logic for ddat_gt-&gt;hwmon_dev error return (Andi)