ghsa-gvrc-62gf-cx56
Vulnerability from github
Published
2024-11-07 12:30
Modified
2024-11-22 21:32
Details

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

sched/core: Disable page allocation in task_tick_mm_cid()

With KASAN and PREEMPT_RT enabled, calling task_work_add() in task_tick_mm_cid() may cause the following splat.

[ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1

This problem is caused by the following call trace.

sched_tick() [ acquire rq->__lock ] -> task_tick_mm_cid() -> task_work_add() -> __kasan_record_aux_stack() -> kasan_save_stack() -> stack_depot_save_flags() -> alloc_pages_mpol_noprof() -> __alloc_pages_noprof() -> get_page_from_freelist() -> rmqueue() -> rmqueue_pcplist() -> __rmqueue_pcplist() -> rmqueue_bulk() -> rt_spin_lock()

The rq lock is a raw_spinlock_t. We can't sleep while holding it. IOW, we can't call alloc_pages() in stack_depot_save_flags().

The task_tick_mm_cid() function with its task_work_add() call was introduced by commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") in v6.4 kernel.

Fortunately, there is a kasan_record_aux_stack_noalloc() variant that calls stack_depot_save_flags() while not allowing it to allocate new pages. To allow task_tick_mm_cid() to use task_work without page allocation, a new TWAF_NO_ALLOC flag is added to enable calling kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack() if set. The task_tick_mm_cid() function is modified to add this new flag.

The possible downside is the missing stack trace in a KASAN report due to new page allocation required when task_work_add_noallloc() is called which should be rare.

Show details on source website


{
   affected: [],
   aliases: [
      "CVE-2024-50140",
   ],
   database_specific: {
      cwe_ids: [],
      github_reviewed: false,
      github_reviewed_at: null,
      nvd_published_at: "2024-11-07T10:15:05Z",
      severity: "MODERATE",
   },
   details: "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Disable page allocation in task_tick_mm_cid()\n\nWith KASAN and PREEMPT_RT enabled, calling task_work_add() in\ntask_tick_mm_cid() may cause the following splat.\n\n[   63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[   63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe\n[   63.696416] preempt_count: 10001, expected: 0\n[   63.696416] RCU nest depth: 1, expected: 1\n\nThis problem is caused by the following call trace.\n\n  sched_tick() [ acquire rq->__lock ]\n   -> task_tick_mm_cid()\n    -> task_work_add()\n     -> __kasan_record_aux_stack()\n      -> kasan_save_stack()\n       -> stack_depot_save_flags()\n        -> alloc_pages_mpol_noprof()\n         -> __alloc_pages_noprof()\n\t  -> get_page_from_freelist()\n\t   -> rmqueue()\n\t    -> rmqueue_pcplist()\n\t     -> __rmqueue_pcplist()\n\t      -> rmqueue_bulk()\n\t       -> rt_spin_lock()\n\nThe rq lock is a raw_spinlock_t. We can't sleep while holding\nit. IOW, we can't call alloc_pages() in stack_depot_save_flags().\n\nThe task_tick_mm_cid() function with its task_work_add() call was\nintroduced by commit 223baf9d17f2 (\"sched: Fix performance regression\nintroduced by mm_cid\") in v6.4 kernel.\n\nFortunately, there is a kasan_record_aux_stack_noalloc() variant that\ncalls stack_depot_save_flags() while not allowing it to allocate\nnew pages.  To allow task_tick_mm_cid() to use task_work without\npage allocation, a new TWAF_NO_ALLOC flag is added to enable calling\nkasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()\nif set. The task_tick_mm_cid() function is modified to add this new flag.\n\nThe possible downside is the missing stack trace in a KASAN report due\nto new page allocation required when task_work_add_noallloc() is called\nwhich should be rare.",
   id: "GHSA-gvrc-62gf-cx56",
   modified: "2024-11-22T21:32:12Z",
   published: "2024-11-07T12:30:34Z",
   references: [
      {
         type: "ADVISORY",
         url: "https://nvd.nist.gov/vuln/detail/CVE-2024-50140",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/509c29d0d26f68a6f6d0a05cb1a89725237e2b87",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/73ab05aa46b02d96509cb029a8d04fca7bbde8c7",
      },
      {
         type: "WEB",
         url: "https://git.kernel.org/stable/c/ce0241ef83eed55f675376e8a3605d23de53d875",
      },
   ],
   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.

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.


Loading…

Loading…

Loading…

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.