CVE-2025-38352High· 7.8▾ Abyssal⚠ Exploited in the wildPoC availableIn the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls ha…
▾ Abyssal zone — Critical with a public exploit or in-the-wild use
impact 42.9 · likelihood 0.3 · exploitation 25
A public proof-of-concept already exists for this vulnerability — see Exploit availability below.
Public exploit / PoC code seen in 1 source. Availability, not in-the-wild use.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Jul 31.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Federal remediation due Sep 25, 2025
1.3%
Last analysed / modified upstream
6 GitHub repos
1.3% → 1.3%
Added to the CISA catalog on Sep 4, 2025. Federal remediation due Sep 25, 2025. View catalog ↗
In the Linux kernel, the following vulnerability has been resolved:
posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()
If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand().
If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail.
Add the tsk->exit_state check into run_posix_cpu_timers() to fix this.
This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case.
linux_kernel >= 2.6.36, < 5.4.295linux_kernel >= 5.5, < 5.10.239linux_kernel >= 5.11, < 5.15.186linux_kernel >= 5.16, < 6.1.142linux_kernel >= 6.2, < 6.6.94linux_kernel >= 6.7, < 6.12.34linux_kernel >= 6.13, < 6.15.3linux_kernel = 6.16debian_linux = 11.0Upgrade past the affected range:
linux_kernel 6.15.3Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-64373Medium· 4.7In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path
CVE-2023-35823High· 7.0An issue was discovered in the Linux kernel before 6.3.2
CVE-2021-46925High· 7.8In the Linux kernel, the following vulnerability has been resolved: net/smc: fix kernel panic caused by race of smc_sock A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it. [ 4570.…
CVE-2023-4611High· 7.0A use-after-free flaw was found in mm/mempolicy.c in the memory management subsystem in the Linux Kernel
CVE-2026-53352Medium· 4.7In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_…
CVE-2022-0995High· 7.8An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem