CVE-2025-38352

What it actually does

This is a Linux kernel race condition in POSIX CPU timer handling during task exit. A task that has passed exit notification but is still reachable can race between handle_posix_cpu_timers() running from interrupt context and posix_cpu_timer_del() running concurrently. In vulnerable kernels, timer state may be evaluated after the task is being reaped, causing inconsistent lifetime and locking behavior around task signal-handling state. Depending on kernel configuration and exploitation reliability, this class of bug can lead to kernel memory corruption, denial of service through kernel crashes, or local privilege escalation. The issue is addressed by adding an exit-state check in run_posix_cpu_timers().

Why it matters to the business

Successful exploitation can allow an attacker who already has local code execution on a Linux system to escalate privileges or destabilize the host. Because this vulnerability is listed in CISA KEV with active exploitation observed in the wild and a remediation due date of 2025-09-25, affected systems should be treated as high-priority even though the EPSS score is relatively low. Operational consequences include full host compromise, bypass of application-level isolation, service outages from kernel crashes, and increased risk when combined with initial-access malware, spyware, container escapes, or post-exploitation toolchains.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user or within a constrained Linux execution context. They then trigger carefully timed process-exit and POSIX CPU timer operations to win the race between kernel CPU timer handling and timer deletion while a task is exiting. If the race is won, the attacker attempts to convert the kernel state inconsistency into a controlled crash or privilege-escalation primitive. In real-world campaigns, this type of kernel vulnerability is commonly chained after phishing, web exploitation, stolen credentials, or container compromise to move from limited execution to root-level control. The KEV listing indicates observed exploitation activity; reported threat context includes advanced spyware and Linux privilege-escalation campaigns, so defenders should assume exploitation may be used as part of broader post-compromise activity rather than as an internet-facing initial access vector.

How to fix it

Upgrade affected Debian 12 Linux systems to a fixed kernel package. For Debian 12, linux is fixed in version 6.1.147-1. After installing the fixed package, reboot into the updated kernel; merely installing the package is not sufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, hardening container boundaries, enforcing least privilege, disabling unnecessary user access, and monitoring for suspicious privilege-escalation behavior. Prioritize systems that run multi-user workloads, containers, internet-facing services, security tooling, CI/CD runners, or workloads where an application compromise could provide local execution.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is at or above the fixed version. On Debian 12, verify the installed linux package version is 6.1.147-1 or later and confirm the active kernel after reboot with standard package and kernel inventory commands such as uname -r, dpkg -l, apt list --installed, or fleet vulnerability scanning. Validate that no hosts remain booted into superseded kernels. Review kernel package changelogs or vendor advisories to confirm inclusion of the POSIX CPU timer fix. For exposure validation, identify Debian 12 systems running Linux kernel builds older than the fixed package and prioritize those with local users, container workloads, or histories of suspicious process crashes or privilege changes.

Typical attack path

1. Gain local code execution on an affected Linux host through another weakness, stolen credentials, malware, or a compromised application/container.
2. Verify the running kernel is a vulnerable build with POSIX CPU timer behavior affected by the race.
3. Run exploit code that creates and exits tasks while manipulating POSIX CPU timers to trigger the vulnerable race window.
4. Repeatedly attempt the race until the kernel mismanages task/timer state.
5. Use the resulting kernel corruption or logic failure to crash the system or escalate privileges to root, depending on exploit capability.
6. Disable defenses, access sensitive data, deploy persistence, or use the host for lateral movement.

How to detect it

This vulnerability is a local kernel race condition and may not produce a unique network indicator. Detection should focus on evidence of attempted local privilege escalation, kernel instability, and post-exploitation activity. Review kernel logs from journald, syslog, dmesg, crash dumps, and centralized log collectors for oops, panic, general protection fault, use-after-free-like symptoms, or stack traces referencing POSIX CPU timer functions. Review auditd, EDR, and shell/process telemetry for untrusted users or service accounts compiling or executing short-lived binaries, repeated fork/exit behavior, abnormal use of timer-related system calls, sudden UID transitions to root, new setuid files, suspicious kernel module loading, or privilege changes shortly before or after kernel errors. Correlate kernel crashes with authentication logs, web server process execution, container runtime activity, and malware/spyware alerts. Because KEV status indicates active exploitation, absence of a known exploit signature should not be treated as proof of non-exploitation; prioritize behavioral correlation and forensic review on exposed or compromised hosts.

• posix_cpu_timer_del
• handle_posix_cpu_timers
• run_posix_cpu_timers
• cpu_timer_task_rcu
• lock_task_sighand
• task_work_add
• BUG: unable to handle kernel
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• WARNING: CPU:
• RIP: 0010:handle_posix_cpu_timers
• RIP: 0010:posix_cpu_timer_del
• RIP: 0010:run_posix_cpu_timers

What your security team should do

• Patch and reboot affected Debian 12 systems to linux 6.1.147-1 or later before the KEV due date of 2025-09-25, prioritizing externally exposed and multi-tenant systems.
• Run fleet-wide inventory to identify systems still running vulnerable kernels after package updates.
• Treat this as a post-exploitation privilege-escalation risk: review recent alerts for suspicious local execution, web-shell activity, container breakout attempts, unexpected root shells, and kernel crashes.
• Restrict local interactive access and untrusted workload execution until patching is complete.
• Increase monitoring for abnormal process-exit storms, repeated crashes, kernel oops messages, and sudden privilege changes from non-root to root.
• Correlate this vulnerability with other Linux kernel privilege-escalation activity observed in the same timeframe, especially spyware or advanced intrusion campaigns.
• Ensure EDR, auditd, and centralized logging collect process execution, privilege changes, kernel logs, and package/kernel version data.
• After remediation, remove old bootable vulnerable kernels where operationally safe to prevent rollback into an exposed state.