Linux Kernel EUVD-2026-82180

Requires a system with the Intel IPU6 image processing unit / MIPI camera and the ipu6 driver loading, AND the auxiliary-device init to fail on the error path - specifically isys/psys MMU initialization failure or auxiliary_device_add() failure - which is what causes the caller's redundant kfree(pdata) to double-free the pdata already freed by ipu6_bus_release(). Limiting factors: the double free is only reachable during driver initialization error unwinding, not by ordinary attacker-controlled syscalls, and it demands local presence plus IPU6 hardware; it does not affect default successful-boot operation, sharply reducing realistic exploitability.

This is a probe/init-time double-free (effectively CWE-415, listed as CWE N/A) in the Intel IPU6 media driver's auxiliary-device setup, not an attacker-reachable memory-corruption primitive. The vendor CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk: the double free of adev->pdata only occurs along kernel init error-unwind paths (MMU initialization failure or auxiliary_device_add() failure), which are triggered by driver/hardware/enumeration conditions during ipu6 bus device bring-up - not by a local user issuing calls at will. There is no EPSS score, no CISA KEV listing, and no public PoC in the provided data; exploitation status is 'no public exploit identified at time of analysis.' The C:H/I:H labels are not justified because the described outcome is a second free of the same object (crash/corruption), not information disclosure or data tampering, so this reads as crash-primary DoS at best and is only reachable when initialization already fails. I assess real risk as LOW despite the high vendor score; treat this as routine patch hygiene rather than an urgent priority. Conflicting signal to note explicitly: the CVSS vector claims AC:L but the error-path-only trigger (init failure required) implies higher attack complexity - verify reachability with vendor.

During IPU6 camera subsystem initialization, the isys/psys MMU init or auxiliary_device_add() step fails, and the caller's leftover manual kfree(pdata) frees the pdata a second time after ipu6_bus_release() has already freed it, corrupting the slab allocator and crashing the kernel. This requires the fault to occur on the driver init path rather than being freely invoked by an attacker; no public exploit code is identified at time of analysis.