ghsa-5j5f-9wh9-hfj9
Vulnerability from github
Published
2025-02-12 15:31
Modified
2025-02-14 18:30
Severity ?
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Details

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 ]

Show details on source website

To clipboard 

{
   affected: [],
   aliases: [
      "CVE-2024-57951",
   ],
   database_specific: {
      cwe_ids: [
         "CWE-416",
      ],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2025-02-12T14:15:31Z",
      severity: "HIGH",
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Handle CPU state correctly on hotplug\n\nConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfway\nthrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to\nCPUHP_ONLINE:\n\nSince hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set\nto 1 throughout. However, during a CPU unplug operation, the tick and the\nclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online\nstate, for instance CFS incorrectly assumes that the hrtick is already\nactive, and the chance of the clockevent device to transition to oneshot\nmode is also lost forever for the CPU, unless it goes back to a lower state\nthan CPUHP_HRTIMERS_PREPARE once.\n\nThis round-trip reveals another issue; cpu_base.online is not set to 1\nafter the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().\n\nAside of that, the bulk of the per CPU state is not reset either, which\nmeans there are dangling pointers in the worst case.\n\nAddress this by adding a corresponding startup() callback, which resets the\nstale per CPU state and sets the online flag.\n\n[ tglx: Make the new callback unconditionally available, remove the online\n  \tmodification in the prepare() callback and clear the remaining\n  \tstate in the starting callback instead of the prepare callback ]",
   id: "GHSA-5j5f-9wh9-hfj9",
   modified: "2025-02-14T18:30:48Z",
   published: "2025-02-12T15:31:59Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2024-57951",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/14984139f1f2768883332965db566ef26db609e7",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/15b453db41d36184cf0ccc21e7df624014ab6a1a",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/2f8dea1692eef2b7ba6a256246ed82c365fdc686",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/38492f6ee883c7b1d33338bf531a62cff69b4b28",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/3d41dbf82e10c44e53ea602398ab002baec27e75",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/95e4f62df23f4df1ce6ef897d44b8e23c260921a",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/a5cbbea145b400e40540c34816d16d36e0374fbc",
      },
   ],
   schema_version: "1.4.0",
   severity: [
      {
         score: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
         type: "CVSS_V3",
      },
   ],
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.