CVE-2025-68735

What it actually does

Use-after-free in the panthor DRM driver's GROUP_CREATE ioctl due to a race where a group pointer is accessed after insertion into the Xarray but before it is marked, allowing concurrent GROUP_DESTROY from another thread to free the object.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or attempt privilege escalation; organizations running untrusted workloads or multi-tenant environments face elevated risk and must apply fixes promptly despite low public exploit activity.

How an attack unfolds

An attacker with local access crafts two threads that race GROUP_CREATE and GROUP_DESTROY ioctls against the panthor driver; the destroy frees the group object while the create path still holds a reference, leading to a use-after-free that can be leveraged for memory corruption.

How to fix it

Upgrade affected packages to the fixed versions: vault-1.16 and vault-1.16-compat to 1.16.3-r15 (Chainguard) or apply the kernel commit deb8b2491f6b9882ae02d7dc2651c7bf4f3b7e05; rebuild and reboot systems after patching.

How to confirm the fix worked

Verify the running kernel contains commit deb8b2491f6b9882ae02d7dc2651c7bf4f3b7e05 or equivalent; confirm package versions match the listed fixed releases and test GROUP_CREATE/GROUP_DESTROY paths under concurrency.

Typical attack path

1. Obtain local unprivileged access on a system using the vulnerable panthor DRM driver
2. Launch concurrent threads issuing GROUP_CREATE and GROUP_DESTROY ioctls with guessed handles
3. Trigger the window where the group pointer is stored unmarked in the Xarray
4. Use the freed object for memory corruption or information disclosure
5. Escalate privileges or cause denial of service

How to detect it

Inspect kernel logs for panthor-related oops or warnings around ioctl handling; correlate with unusual concurrent calls to GROUP_CREATE and GROUP_DESTROY from the same process tree; review audit logs for unexpected drm device access patterns.

What your security team should do

• Apply the listed kernel and package updates within the next maintenance window
• Prioritize systems exposing the panthor driver to untrusted local processes
• Review and restrict access to DRM ioctls where feasible
• Monitor upstream stable kernels for any follow-on fixes