GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-8H6J-VXPR-4FF5

Vulnerability from github – Published: 2024-02-27 21:31 – Updated: 2024-04-10 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

tracing: Restructure trace_clock_global() to never block

It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case:

Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0

With the following RIP:

RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again:

ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { / lock taken / (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { / DEAD LOCK! /

Tracing should never block, as it can lead to strange lockups like the above.

Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-46939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T19:04:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Restructure trace_clock_global() to never block\n\nIt was reported that a fix to the ring buffer recursion detection would\ncause a hung machine when performing suspend / resume testing. The\nfollowing backtrace was extracted from debugging that case:\n\nCall Trace:\n trace_clock_global+0x91/0xa0\n __rb_reserve_next+0x237/0x460\n ring_buffer_lock_reserve+0x12a/0x3f0\n trace_buffer_lock_reserve+0x10/0x50\n __trace_graph_return+0x1f/0x80\n trace_graph_return+0xb7/0xf0\n ? trace_clock_global+0x91/0xa0\n ftrace_return_to_handler+0x8b/0xf0\n ? pv_hash+0xa0/0xa0\n return_to_handler+0x15/0x30\n ? ftrace_graph_caller+0xa0/0xa0\n ? trace_clock_global+0x91/0xa0\n ? __rb_reserve_next+0x237/0x460\n ? ring_buffer_lock_reserve+0x12a/0x3f0\n ? trace_event_buffer_lock_reserve+0x3c/0x120\n ? trace_event_buffer_reserve+0x6b/0xc0\n ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0\n ? dpm_run_callback+0x3b/0xc0\n ? pm_ops_is_empty+0x50/0x50\n ? platform_get_irq_byname_optional+0x90/0x90\n ? trace_device_pm_callback_start+0x82/0xd0\n ? dpm_run_callback+0x49/0xc0\n\nWith the following RIP:\n\nRIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200\n\nSince the fix to the recursion detection would allow a single recursion to\nhappen while tracing, this lead to the trace_clock_global() taking a spin\nlock and then trying to take it again:\n\nring_buffer_lock_reserve() {\n  trace_clock_global() {\n    arch_spin_lock() {\n      queued_spin_lock_slowpath() {\n        /* lock taken */\n        (something else gets traced by function graph tracer)\n          ring_buffer_lock_reserve() {\n            trace_clock_global() {\n              arch_spin_lock() {\n                queued_spin_lock_slowpath() {\n                /* DEAD LOCK! */\n\nTracing should *never* block, as it can lead to strange lockups like the\nabove.\n\nRestructure the trace_clock_global() code to instead of simply taking a\nlock to update the recorded \"prev_time\" simply use it, as two events\nhappening on two different CPUs that calls this at the same time, really\ndoesn\u0027t matter which one goes first. Use a trylock to grab the lock for\nupdating the prev_time, and if it fails, simply try again the next time.\nIf it failed to be taken, that means something else is already updating\nit.\n\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761",
  "id": "GHSA-8h6j-vxpr-4ff5",
  "modified": "2024-04-10T21:30:28Z",
  "published": "2024-02-27T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46939"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.