CVE-2024-57951: linux kernel Use-After-Free — Fix

Description

In the Linux kernel, the following vulnerability has been resolved: hrtimers: Handle CPU state correctly on hotplug Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE: Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once. This round-trip reveals another issue; cpu_base.online is not set to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer(). Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case. Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag. [ tglx: Make the new callback unconditionally available, remove the online modification in the prepare() callback and clear the remaining state in the starting callback instead of the prepare callback ]

Is your site exposed to CVE-2024-57951?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

7.8

HIGH

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Weakness Type (CWE)

CWE-416 Use After Free

Affected Products

Vendor	Product	Versions
linux	linux_kernel	4.19.302 — 4.20
linux	linux_kernel	5.4.264 — 5.4.290
linux	linux_kernel	5.10.204 — 5.10.234
linux	linux_kernel	5.15.143 — 5.15.177
linux	linux_kernel	6.1.68 — 6.1.127
linux	linux_kernel	6.6.7 — 6.6.74
linux	linux_kernel	6.7 — 6.12.11
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All
linux	linux_kernel	All

References

Advisories & Patches

https://git.kernel.org/stable/c/14984139f1f2768883332965db566ef26db609e7 https://git.kernel.org/stable/c/15b453db41d36184cf0ccc21e7df624014ab6a1a https://git.kernel.org/stable/c/2f8dea1692eef2b7ba6a256246ed82c365fdc686 https://git.kernel.org/stable/c/38492f6ee883c7b1d33338bf531a62cff69b4b28 https://git.kernel.org/stable/c/3d41dbf82e10c44e53ea602398ab002baec27e75 https://git.kernel.org/stable/c/95e4f62df23f4df1ce6ef897d44b8e23c260921a https://git.kernel.org/stable/c/a5cbbea145b400e40540c34816d16d36e0374fbc

Other References

https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html https://cert-portal.siemens.com/productcert/html/ssa-265688.html https://cert-portal.siemens.com/productcert/html/ssa-355557.html

Frequently Asked Questions

What is CVE-2024-57951? +

In the Linux kernel, the following vulnerability has been resolved: hrtimers: Handle CPU state correctly on hotplug Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE: Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once. This round-trip reveals another issue; cpu_base.online is not set to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer(). Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case. Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag. [ tglx: Make the new callback unconditionally available, remove the online modification in the prepare() callback and clear the remaining state in the starting callback instead of the prepare callback ] It has a CVSS v3.1 base score of 7.8 (HIGH).

How severe is CVE-2024-57951? +

CVE-2024-57951 has a CVSS v3.1 score of 7.8 out of 10, rated HIGH. This is a high-severity vulnerability that should be prioritized for patching.

What products are affected by CVE-2024-57951? +

CVE-2024-57951 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2024-57951? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-55406

Buffa is a pure-Rust Protocol Buffers implementation with first-class protobuf editions support. Prior to 0.7.0, a soundness bug in the …

CVE-2026-6040

A heap use-after-free existed when importing the blank-width characters of an ODF number format. A position value read from the …

CVE-2025-24898

rust-openssl is a set of OpenSSL bindings for the Rust programming language. In affected versions `ssl::select_next_proto` can return a slice …

CVE-2025-31115

XZ Utils provide a general-purpose data-compression library plus command-line tools. In XZ Utils 5.3.3alpha to 5.8.0, the multithreaded .xz decoder …

CVE-2025-31498

c-ares is an asynchronous resolver library. From 1.32.3 through 1.34.4, there is a use-after-free in read_answers() when process_answer() may re-enqueue …

CVE-2025-4516

There is an issue in CPython when using `bytes.decode("unicode_escape", error="ignore|replace")`. If you are not using the "unicode_escape" encoding or an …

CVE-2024-57951