ghsa-gvrc-62gf-cx56
Vulnerability from github
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.
{
"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-\u003e__lock ]\n -\u003e task_tick_mm_cid()\n -\u003e task_work_add()\n -\u003e __kasan_record_aux_stack()\n -\u003e kasan_save_stack()\n -\u003e stack_depot_save_flags()\n -\u003e alloc_pages_mpol_noprof()\n -\u003e __alloc_pages_noprof()\n\t -\u003e get_page_from_freelist()\n\t -\u003e rmqueue()\n\t -\u003e rmqueue_pcplist()\n\t -\u003e __rmqueue_pcplist()\n\t -\u003e rmqueue_bulk()\n\t -\u003e rt_spin_lock()\n\nThe rq lock is a raw_spinlock_t. We can\u0027t sleep while holding\nit. IOW, we can\u0027t 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"
}
]
}
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.