CVE-2025-38632

What it actually does

Race condition in pinmux allows interleaving of pin_request and pin_free operations that leaves mux_usecount positive while mux_owner is set to NULL, enabling a subsequent NULL pointer dereference on the same pin.

Why it matters to the business

Systems running affected Linux kernels may experience crashes or local privilege escalation opportunities, particularly in containerized or embedded environments; the large number of downstream package listings indicates broad ecosystem exposure requiring coordinated updates.

How an attack unfolds

An attacker with local access triggers concurrent pin_request and pin_free calls from multiple processes on the same GPIO pin to reach the inconsistent mux state, then performs a follow-on pin_request to dereference the NULL owner pointer; threat actors such as VMSCAPE have been observed targeting similar Linux kernel race conditions for privilege escalation on container-optimized OS deployments.

How to fix it

Upgrade the Linux kernel to 6.6.102 or later; for Chainguard packages update openjdk-11-openj9 and related variants to 0.53.0-r0; apply the atomic lock fix for mux_usecount and mux_owner updates in stable trees at commit 9b2a3e7189028aa7c4d53a84364f2ea9fb209787.

How to confirm the fix worked

Verify running kernel version is at or above the listed fixed releases; confirm the presence of the atomic update logic under the mux lock in pinmux code; test concurrent pin_request/pin_free workloads to ensure mux_owner is never NULL while usecount remains positive.

Typical attack path

1. Obtain local code execution on a vulnerable system
2. Identify or create workloads that repeatedly call pinctrl_select_state on shared pins
3. Race pin_request against pin_free to produce mux_usecount==1 with mux_owner==NULL
4. Trigger subsequent pin_request to cause NULL pointer dereference
5. Escalate via resulting kernel panic or use-after-free primitives

How to detect it

Review kernel logs for oops or panic messages referencing pinmux, mux_owner, or mux_usecount; correlate with process activity showing concurrent pinctrl calls; examine threat actor tooling associated with VMSCAPE or Container-Optimized OS privilege escalations for matching patterns.

What your security team should do

• Apply kernel and package updates immediately on all affected hosts given the 431 days since publication
• Prioritize systems with high container density or direct GPIO/pinmux usage
• Monitor EPSS and threat actor activity for similar kernel races
• Harden access controls to limit local unprivileged process creation