CVE-2025-68354

What it actually does

Concurrent access to regulator_supply_alias_list without locking allows use-after-free on removal during read, duplicate alias entries on simultaneous registration, and inconsistent alias mappings visible to consumers.

Why it matters to the business

Systems running affected Linux kernel versions in containerized or orchestrated environments face elevated risk of local denial-of-service or privilege escalation through kernel memory corruption, potentially disrupting workloads and requiring urgent patching of base OS images.

How an attack unfolds

An attacker with local access triggers concurrent calls to regulator_register_supply_alias, regulator_unregister_supply_alias, and regulator_supply_alias from multiple threads or processes; the lack of mutex protection on the alias list permits a window where an entry is freed while another thread dereferences it or two registrations insert duplicates, resulting in kernel instability or exploitable memory state.

How to fix it

Upgrade all affected packages to the fixed versions listed (kubernetes-1.28 and related Chainguard images to 1.28.15-r12 or newer; Linux kernel trees to commit e1587064137028e7edcca14fb766b68d27bec94b). Rebuild and redeploy container images and nodes with the updated kernel.

How to confirm the fix worked

Verify package versions match the fixed releases, confirm the mutex protection surrounds all list traversals/insertions/deletions in the regulator core source, and test concurrent alias operations under load to ensure no races manifest.

Typical attack path

1. Obtain local execution context on an affected system (container escape, user shell, or malicious workload)
2. Identify or create conditions that invoke regulator alias registration and lookup paths
3. Race multiple threads performing register, unregister, and lookup operations on the same alias
4. Trigger use-after-free or duplicate entry state to corrupt kernel data structures
5. Leverage resulting memory corruption for denial-of-service or further privilege escalation

How to detect it

Review kernel logs for oops, use-after-free warnings, or list corruption near regulator alias functions; examine audit logs for unusual concurrent process activity involving regulator registration syscalls or device power management; correlate with container runtime events showing rapid alias registration attempts.

What your security team should do

• Prioritize patching of all 1.28-series Kubernetes node images to 1.28.15-r12 within standard change windows
• Audit workloads for any direct or indirect use of regulator interfaces and restrict untrusted local execution where possible
• Monitor kernel update pipelines to ensure future stable releases incorporate the mutex fix