CVE-2024-36973

What it actually does

Double free of memory occurs in gp_aux_bus_probe error path because auxiliary_device_uninit already invokes gp_auxiliary_device_release which performs ida_free and kfree, after which the error handler repeats those frees.

Why it matters to the business

Kernel memory corruption or crashes on systems using the affected microchip pci1xxxx hardware can cause denial of service, data loss, or unplanned downtime until kernels are updated.

How an attack unfolds

An attacker with local access triggers the error return from auxiliary_device_add inside gp_aux_bus_probe, allowing the release callback to free the wrapper object, then the error handler executes the same frees again, enabling heap manipulation or crash for potential privilege escalation.

How to fix it

Update the Linux kernel to the commit 34ae447b138680b5ed3660f7d935ff3faf88ba1a or later stable releases that contain the fix; rebuild and deploy the updated kernel image on all affected systems.

How to confirm the fix worked

Verify the running kernel source contains commit 34ae447b138680b5ed3660f7d935ff3faf88ba1a, confirm the double-free code path has been removed from gp_aux_bus_probe error handling, and test probe failure scenarios on hardware using the pci1xxxx driver.

Typical attack path

1. Obtain local code execution on the target system
2. Cause auxiliary_device_add to fail during gp_aux_bus_probe
3. Allow gp_auxiliary_device_release to perform ida_free and kfree
4. Execute the redundant ida_free and kfree in the error handler
5. Leverage resulting memory state for further exploitation or denial of service

How to detect it

Review kernel logs for oops or panic messages referencing gp_aux_bus_probe, ida_free, or auxiliary_device_release around probe failure times; examine audit logs for unusual local process activity coinciding with driver initialization errors.

What your security team should do

• Apply the referenced kernel commit immediately on all systems exposing the microchip pci1xxxx driver
• Prioritize patching production hosts that use this hardware due to memory corruption risk
• Monitor for any local privilege-escalation attempts while rollout completes
• Remove or disable the driver on systems where the hardware is not required