CVE-2025-68732

What it actually does

Race condition between host1x_syncpt_alloc() and host1x_syncpt_put() allowing a syncpoint to be allocated while still being released, due to non-atomic refcount and mutex handling.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel instability or memory corruption in graphics/syncpoint paths, leading to crashes, degraded GPU functionality, or potential privilege escalation in embedded, container, or accelerated workloads.

How an attack unfolds

An attacker with local code execution triggers concurrent allocation and release operations on host1x syncpoints; the window between refcount drop and mutex acquisition permits reuse of a syncpoint still undergoing cleanup, resulting in invalid kernel state.

How to fix it

Upgrade spegel to 0.0.30-r2 or apply Linux kernel commit ca9388fba50dac2eb71c13702b7022a801bef90e; rebuild and reboot systems using the fixed host1x syncpoint code.

How to confirm the fix worked

Confirm package or kernel source matches listed fixed versions; inspect host1x_syncpt.c for replacement of kref_put() + manual locking with kref_put_mutex() in alloc/free paths.

Typical attack path

1. Gain local user access on target system
2. Execute concurrent threads performing syncpt alloc/put operations
3. Trigger race window to obtain use-after-release syncpoint handle
4. Leverage resulting kernel object misuse for memory corruption or denial of service

How to detect it

Review kernel ring buffer and dmesg for host1x syncpoint allocation or release errors, oops/panics referencing syncpt_release or syncpt_mutex around the time of suspected activity.

What your security team should do

• Apply the listed kernel and spegel updates on all affected hosts within the next maintenance window
• Limit untrusted local code execution on systems exposing host1x hardware
• Monitor kernel logs for host1x syncpoint warnings or oops after patching