CVE-2025-37754

In the Linux kernel, the following vulnerability has been resolved:

drm/i915/huc: Fix fence not released on early probe errors

HuC delayed loading fence, introduced with commit 27536e03271da ("drm/i915/huc: track delayed HuC load with a fence"), is registered with object tracker early on driver probe but unregistered only from driver remove, which is not called on early probe errors. Since its memory is allocated under devres, then released anyway, it may happen to be allocated again to the fence and reused on future driver probes, resulting in kernel warnings that taint the kernel:

<4> [309.731371] ------------[ cut here ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915swfence hint: swfencedummynotify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debugprintobject+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915moduleloa Tainted: G U 6.14.0-CIDRM16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debugprintobject+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] <TASK> ... <4> [309.731949] _debugobjectinit+0x17b/0x1c0 <4> [309.731957] debugobjectinit+0x34/0x50 <4> [309.732126] _i915swfenceinit+0x34/0x60 [i915] <4> [309.732256] intelhucinitearly+0x4b/0x1d0 [i915] <4> [309.732468] intelucinitearly+0x61/0x680 [i915] <4> [309.732667] intelgtcommoninitearly+0x105/0x130 [i915] <4> [309.732804] intelrootgtinitearly+0x63/0x80 [i915] <4> [309.732938] i915driverprobe+0x1fa/0xeb0 [i915] <4> [309.733075] i915pciprobe+0xe6/0x220 [i915] <4> [309.733198] localpciprobe+0x44/0xb0 <4> [309.733203] pcideviceprobe+0xf4/0x270 <4> [309.733209] reallyprobe+0xee/0x3c0 <4> [309.733215] _driverprobedevice+0x8c/0x180 <4> [309.733219] driverprobedevice+0x24/0xd0 <4> [309.733223] _driverattach+0x10f/0x220 <4> [309.733230] busforeachdev+0x7d/0xe0 <4> [309.733236] driverattach+0x1e/0x30 <4> [309.733239] busadddriver+0x151/0x290 <4> [309.733244] driverregister+0x5e/0x130 <4> [309.733247] _pciregisterdriver+0x7d/0x90 <4> [309.733251] i915pciregisterdriver+0x23/0x30 [i915] <4> [309.733413] i915init+0x34/0x120 [i915] <4> [309.733655] dooneinitcall+0x62/0x3f0 <4> [309.733667] doinitmodule+0x97/0x2a0 <4> [309.733671] loadmodule+0x25ff/0x2890 <4> [309.733688] initmodulefromfile+0x97/0xe0 <4> [309.733701] idempotentinitmodule+0x118/0x330 <4> [309.733711] _x64sysfinitmodule+0x77/0x100 <4> [309.733715] x64syscall+0x1f37/0x2650 <4> [309.733719] dosyscall64+0x91/0x180 <4> [309.733763] entrySYSCALL64afterhwframe+0x76/0x7e <4> [309.733792] </TASK> ... <4> [309.733806] ---[ end trace 0000000000000000 ]---

That scenario is most easily reproducible with igt@i915moduleload@reload-with-fault-injection.

Fix the issue by moving the cleanup step to driver release path.

(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)