CVE-2024-50082 (GCVE-0-2024-50082)

Vulnerability from cvelistv5 – Published: 2024-10-29 00:50 – Updated: 2026-05-11 20:45
VLAI
Title
blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
Summary
In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().
Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < d04b72c9ef2b0689bfc1057d21c4aeed087c329f (git)
Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < 3bc6d0f8b70a9101456cf02ab99acb75254e1852 (git)
Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < 455a469758e57a6fe070e3e342db12e4a629e0eb (git)
Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < b5e900a3612b69423a0e1b0ab67841a1fb4af80f (git)
Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < 4c5b123ab289767afe940389dbb963c5c05e594e (git)
Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < 04f283fc16c8d5db641b6bffd2d8310aa7eccebc (git)
Affected: 38cfb5a45ee013bfab5d1ae4c4738815e744b440 , < e972b08b91ef48488bae9789f03cfedb148667fb (git)
Create a notification for this product.
Linux Linux Affected: 4.19
Unaffected: 0 , < 4.19 (semver)
Unaffected: 5.4.285 , ≤ 5.4.* (semver)
Unaffected: 5.10.228 , ≤ 5.10.* (semver)
Unaffected: 5.15.169 , ≤ 5.15.* (semver)
Unaffected: 6.1.114 , ≤ 6.1.* (semver)
Unaffected: 6.6.58 , ≤ 6.6.* (semver)
Unaffected: 6.11.5 , ≤ 6.11.* (semver)
Unaffected: 6.12 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T22:25:14.334Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
          },
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "block/blk-rq-qos.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d04b72c9ef2b0689bfc1057d21c4aeed087c329f",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            },
            {
              "lessThan": "3bc6d0f8b70a9101456cf02ab99acb75254e1852",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            },
            {
              "lessThan": "455a469758e57a6fe070e3e342db12e4a629e0eb",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            },
            {
              "lessThan": "b5e900a3612b69423a0e1b0ab67841a1fb4af80f",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            },
            {
              "lessThan": "4c5b123ab289767afe940389dbb963c5c05e594e",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            },
            {
              "lessThan": "04f283fc16c8d5db641b6bffd2d8310aa7eccebc",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            },
            {
              "lessThan": "e972b08b91ef48488bae9789f03cfedb148667fb",
              "status": "affected",
              "version": "38cfb5a45ee013bfab5d1ae4c4738815e744b440",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "block/blk-rq-qos.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.19"
            },
            {
              "lessThan": "4.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.285",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.228",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.169",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.114",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.58",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.285",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.228",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.169",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.114",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.58",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11.5",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race\n\nWe\u0027re seeing crashes from rq_qos_wake_function that look like this:\n\n  BUG: unable to handle page fault for address: ffffafe180a40084\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0\n  Oops: Oops: 0002 [#1] PREEMPT SMP PTI\n  CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40\n  Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u003cf0\u003e 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00\n  RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046\n  RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011\n  RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084\n  RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011\n  R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002\n  R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003\n  FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n   \u003cIRQ\u003e\n   try_to_wake_up+0x5a/0x6a0\n   rq_qos_wake_function+0x71/0x80\n   __wake_up_common+0x75/0xa0\n   __wake_up+0x36/0x60\n   scale_up.part.0+0x50/0x110\n   wb_timer_fn+0x227/0x450\n   ...\n\nSo rq_qos_wake_function() calls wake_up_process(data-\u003etask), which calls\ntry_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026p-\u003epi_lock).\n\np comes from data-\u003etask, and data comes from the waitqueue entry, which\nis stored on the waiter\u0027s stack in rq_qos_wait(). Analyzing the core\ndump with drgn, I found that the waiter had already woken up and moved\non to a completely unrelated code path, clobbering what was previously\ndata-\u003etask. Meanwhile, the waker was passing the clobbered garbage in\ndata-\u003etask to wake_up_process(), leading to the crash.\n\nWhat\u0027s happening is that in between rq_qos_wake_function() deleting the\nwaitqueue entry and calling wake_up_process(), rq_qos_wait() is finding\nthat it already got a token and returning. The race looks like this:\n\nrq_qos_wait()                           rq_qos_wake_function()\n==============================================================\nprepare_to_wait_exclusive()\n                                        data-\u003egot_token = true;\n                                        list_del_init(\u0026curr-\u003eentry);\nif (data.got_token)\n        break;\nfinish_wait(\u0026rqw-\u003ewait, \u0026data.wq);\n  ^- returns immediately because\n     list_empty_careful(\u0026wq_entry-\u003eentry)\n     is true\n... return, go do something else ...\n                                        wake_up_process(data-\u003etask)\n                                          (NO LONGER VALID!)-^\n\nNormally, finish_wait() is supposed to synchronize against the waker.\nBut, as noted above, it is returning immediately because the waitqueue\nentry has already been removed from the waitqueue.\n\nThe bug is that rq_qos_wake_function() is accessing the waitqueue entry\nAFTER deleting it. Note that autoremove_wake_function() wakes the waiter\nand THEN deletes the waitqueue entry, which is the proper order.\n\nFix it by swapping the order. We also need to use\nlist_del_init_careful() to match the list_empty_careful() in\nfinish_wait()."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:45:05.420Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d04b72c9ef2b0689bfc1057d21c4aeed087c329f"
        },
        {
          "url": "https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852"
        },
        {
          "url": "https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb"
        },
        {
          "url": "https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f"
        },
        {
          "url": "https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e"
        },
        {
          "url": "https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc"
        },
        {
          "url": "https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb148667fb"
        }
      ],
      "title": "blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-50082",
    "datePublished": "2024-10-29T00:50:24.667Z",
    "dateReserved": "2024-10-21T19:36:19.941Z",
    "dateUpdated": "2026-05-11T20:45:05.420Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-50082",
      "date": "2026-06-08",
      "epss": "0.00013",
      "percentile": "0.02143"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"4.19\", \"versionEndExcluding\": \"5.10.228\", \"matchCriteriaId\": \"AC13DFD5-0BA4-4713-BBB2-F08C0E282CB9\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.11\", \"versionEndExcluding\": \"5.15.169\", \"matchCriteriaId\": \"18BEDAD6-86F8-457C-952F-C35698B3D07F\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.16\", \"versionEndExcluding\": \"6.1.114\", \"matchCriteriaId\": \"10FD2B3E-C7D9-4A9C-BD64-41877EDF88EB\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.2\", \"versionEndExcluding\": \"6.6.58\", \"matchCriteriaId\": \"6B9489BC-825E-4EEE-8D93-F93C801988C8\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.7\", \"versionEndExcluding\": \"6.11.5\", \"matchCriteriaId\": \"6E62D61A-F704-44DB-A311-17B7534DA7BC\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\", \"matchCriteriaId\": \"7F361E1D-580F-4A2D-A509-7615F73167A1\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\", \"matchCriteriaId\": \"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*\", \"matchCriteriaId\": \"3C95E234-D335-4B6C-96BF-E2CEBD8654ED\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nblk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race\\n\\nWe\u0027re seeing crashes from rq_qos_wake_function that look like this:\\n\\n  BUG: unable to handle page fault for address: ffffafe180a40084\\n  #PF: supervisor write access in kernel mode\\n  #PF: error_code(0x0002) - not-present page\\n  PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0\\n  Oops: Oops: 0002 [#1] PREEMPT SMP PTI\\n  CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11\\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\\n  RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40\\n  Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u003cf0\u003e 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00\\n  RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046\\n  RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011\\n  RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084\\n  RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011\\n  R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002\\n  R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003\\n  FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000\\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\n  CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0\\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\\n  PKRU: 55555554\\n  Call Trace:\\n   \u003cIRQ\u003e\\n   try_to_wake_up+0x5a/0x6a0\\n   rq_qos_wake_function+0x71/0x80\\n   __wake_up_common+0x75/0xa0\\n   __wake_up+0x36/0x60\\n   scale_up.part.0+0x50/0x110\\n   wb_timer_fn+0x227/0x450\\n   ...\\n\\nSo rq_qos_wake_function() calls wake_up_process(data-\u003etask), which calls\\ntry_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026p-\u003epi_lock).\\n\\np comes from data-\u003etask, and data comes from the waitqueue entry, which\\nis stored on the waiter\u0027s stack in rq_qos_wait(). Analyzing the core\\ndump with drgn, I found that the waiter had already woken up and moved\\non to a completely unrelated code path, clobbering what was previously\\ndata-\u003etask. Meanwhile, the waker was passing the clobbered garbage in\\ndata-\u003etask to wake_up_process(), leading to the crash.\\n\\nWhat\u0027s happening is that in between rq_qos_wake_function() deleting the\\nwaitqueue entry and calling wake_up_process(), rq_qos_wait() is finding\\nthat it already got a token and returning. The race looks like this:\\n\\nrq_qos_wait()                           rq_qos_wake_function()\\n==============================================================\\nprepare_to_wait_exclusive()\\n                                        data-\u003egot_token = true;\\n                                        list_del_init(\u0026curr-\u003eentry);\\nif (data.got_token)\\n        break;\\nfinish_wait(\u0026rqw-\u003ewait, \u0026data.wq);\\n  ^- returns immediately because\\n     list_empty_careful(\u0026wq_entry-\u003eentry)\\n     is true\\n... return, go do something else ...\\n                                        wake_up_process(data-\u003etask)\\n                                          (NO LONGER VALID!)-^\\n\\nNormally, finish_wait() is supposed to synchronize against the waker.\\nBut, as noted above, it is returning immediately because the waitqueue\\nentry has already been removed from the waitqueue.\\n\\nThe bug is that rq_qos_wake_function() is accessing the waitqueue entry\\nAFTER deleting it. Note that autoremove_wake_function() wakes the waiter\\nand THEN deletes the waitqueue entry, which is the proper order.\\n\\nFix it by swapping the order. We also need to use\\nlist_del_init_careful() to match the list_empty_careful() in\\nfinish_wait().\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-rq-qos: se corrige el fallo en la ejecuci\\u00f3n rq_qos_wait vs. rq_qos_wake_function Estamos viendo fallos de rq_qos_wake_function que se parecen a esto: ERROR: no se puede manejar el error de p\\u00e1gina para la direcci\\u00f3n: ffffafe180a40084 #PF: acceso de escritura de supervisor en modo kernel #PF: error_code(0x0002) - p\\u00e1gina no presente PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 No contaminado 6.12.0-rc3-00013-geca631b8fe80 #11 Nombre del hardware: PC est\\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 C\\u00f3digo: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00  0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 000000000001e7240 R09: 0000000000000011 R10: 00000000000000028 R11: 00000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas:  try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... Entonces rq_qos_wake_function() llama a wake_up_process(data-\u0026gt;task), que llama a try_to_wake_up(), que falla en raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock). p viene de data-\u0026gt;task, y data viene de la entrada de la cola de espera, que se almacena en la pila del que espera en rq_qos_wait(). Al analizar el volcado de memoria con drgn, descubr\\u00ed que el que espera ya se hab\\u00eda despertado y se hab\\u00eda movido a una ruta de c\\u00f3digo completamente no relacionada, destruyendo lo que antes era data-\u0026gt;task. Mientras tanto, el waker estaba pasando la basura golpeada en data-\u0026gt;task a wake_up_process(), lo que provoc\\u00f3 el bloqueo. Lo que est\\u00e1 sucediendo es que entre rq_qos_wake_function() eliminando la entrada de la cola de espera y llamando a wake_up_process(), rq_qos_wait() descubre que ya obtuvo un token y regresa. La ejecuci\\u00f3n se ve as\\u00ed: rq_qos_wait() rq_qos_wake_function() ============================================================ prepare_to_wait_exclusive() data-\u0026gt;got_token = true; list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token) break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq); ^- retorna inmediatamente porque list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry) es verdadero... retorna, ve a hacer otra cosa... wake_up_process(data-\u0026gt;task) (\\u00a1YA NO ES V\\u00c1LIDO!)-^ Normalmente, se supone que finish_wait() se sincroniza con el activador. Pero, como se se\\u00f1al\\u00f3 anteriormente, retorna inmediatamente porque la entrada de la cola de espera ya se elimin\\u00f3 de la cola de espera. El error es que rq_qos_wake_function() est\\u00e1 accediendo a la entrada de la cola de espera DESPU\\u00c9S de eliminarla. Tenga en cuenta que autoremove_wake_function() despierta al que espera y LUEGO elimina la entrada de la cola de espera, que es el orden correcto. Arr\\u00e9glelo intercambiando el orden. Tambi\\u00e9n debemos usar list_del_init_careful() para que coincida con list_empty_careful() en finish_wait().\"}]",
      "id": "CVE-2024-50082",
      "lastModified": "2024-11-08T16:15:46.080",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"baseScore\": 4.7, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"LOCAL\", \"attackComplexity\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"HIGH\"}, \"exploitabilityScore\": 1.0, \"impactScore\": 3.6}]}",
      "published": "2024-10-29T01:15:05.147",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/d04b72c9ef2b0689bfc1057d21c4aeed087c329f\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb148667fb\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Modified",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"NVD-CWE-noinfo\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-50082\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-10-29T01:15:05.147\",\"lastModified\":\"2025-11-03T23:16:48.100\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nblk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race\\n\\nWe\u0027re seeing crashes from rq_qos_wake_function that look like this:\\n\\n  BUG: unable to handle page fault for address: ffffafe180a40084\\n  #PF: supervisor write access in kernel mode\\n  #PF: error_code(0x0002) - not-present page\\n  PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0\\n  Oops: Oops: 0002 [#1] PREEMPT SMP PTI\\n  CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11\\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\\n  RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40\\n  Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u003cf0\u003e 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00\\n  RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046\\n  RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011\\n  RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084\\n  RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011\\n  R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002\\n  R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003\\n  FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000\\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\n  CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0\\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\\n  PKRU: 55555554\\n  Call Trace:\\n   \u003cIRQ\u003e\\n   try_to_wake_up+0x5a/0x6a0\\n   rq_qos_wake_function+0x71/0x80\\n   __wake_up_common+0x75/0xa0\\n   __wake_up+0x36/0x60\\n   scale_up.part.0+0x50/0x110\\n   wb_timer_fn+0x227/0x450\\n   ...\\n\\nSo rq_qos_wake_function() calls wake_up_process(data-\u003etask), which calls\\ntry_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026p-\u003epi_lock).\\n\\np comes from data-\u003etask, and data comes from the waitqueue entry, which\\nis stored on the waiter\u0027s stack in rq_qos_wait(). Analyzing the core\\ndump with drgn, I found that the waiter had already woken up and moved\\non to a completely unrelated code path, clobbering what was previously\\ndata-\u003etask. Meanwhile, the waker was passing the clobbered garbage in\\ndata-\u003etask to wake_up_process(), leading to the crash.\\n\\nWhat\u0027s happening is that in between rq_qos_wake_function() deleting the\\nwaitqueue entry and calling wake_up_process(), rq_qos_wait() is finding\\nthat it already got a token and returning. The race looks like this:\\n\\nrq_qos_wait()                           rq_qos_wake_function()\\n==============================================================\\nprepare_to_wait_exclusive()\\n                                        data-\u003egot_token = true;\\n                                        list_del_init(\u0026curr-\u003eentry);\\nif (data.got_token)\\n        break;\\nfinish_wait(\u0026rqw-\u003ewait, \u0026data.wq);\\n  ^- returns immediately because\\n     list_empty_careful(\u0026wq_entry-\u003eentry)\\n     is true\\n... return, go do something else ...\\n                                        wake_up_process(data-\u003etask)\\n                                          (NO LONGER VALID!)-^\\n\\nNormally, finish_wait() is supposed to synchronize against the waker.\\nBut, as noted above, it is returning immediately because the waitqueue\\nentry has already been removed from the waitqueue.\\n\\nThe bug is that rq_qos_wake_function() is accessing the waitqueue entry\\nAFTER deleting it. Note that autoremove_wake_function() wakes the waiter\\nand THEN deletes the waitqueue entry, which is the proper order.\\n\\nFix it by swapping the order. We also need to use\\nlist_del_init_careful() to match the list_empty_careful() in\\nfinish_wait().\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-rq-qos: se corrige el fallo en la ejecuci\u00f3n rq_qos_wait vs. rq_qos_wake_function Estamos viendo fallos de rq_qos_wake_function que se parecen a esto: ERROR: no se puede manejar el error de p\u00e1gina para la direcci\u00f3n: ffffafe180a40084 #PF: acceso de escritura de supervisor en modo kernel #PF: error_code(0x0002) - p\u00e1gina no presente PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 No contaminado 6.12.0-rc3-00013-geca631b8fe80 #11 Nombre del hardware: PC est\u00e1ndar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 C\u00f3digo: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00  0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 000000000001e7240 R09: 0000000000000011 R10: 00000000000000028 R11: 00000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas:  try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... Entonces rq_qos_wake_function() llama a wake_up_process(data-\u0026gt;task), que llama a try_to_wake_up(), que falla en raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock). p viene de data-\u0026gt;task, y data viene de la entrada de la cola de espera, que se almacena en la pila del que espera en rq_qos_wait(). Al analizar el volcado de memoria con drgn, descubr\u00ed que el que espera ya se hab\u00eda despertado y se hab\u00eda movido a una ruta de c\u00f3digo completamente no relacionada, destruyendo lo que antes era data-\u0026gt;task. Mientras tanto, el waker estaba pasando la basura golpeada en data-\u0026gt;task a wake_up_process(), lo que provoc\u00f3 el bloqueo. Lo que est\u00e1 sucediendo es que entre rq_qos_wake_function() eliminando la entrada de la cola de espera y llamando a wake_up_process(), rq_qos_wait() descubre que ya obtuvo un token y regresa. La ejecuci\u00f3n se ve as\u00ed: rq_qos_wait() rq_qos_wake_function() ============================================================ prepare_to_wait_exclusive() data-\u0026gt;got_token = true; list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token) break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq); ^- retorna inmediatamente porque list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry) es verdadero... retorna, ve a hacer otra cosa... wake_up_process(data-\u0026gt;task) (\u00a1YA NO ES V\u00c1LIDO!)-^ Normalmente, se supone que finish_wait() se sincroniza con el activador. Pero, como se se\u00f1al\u00f3 anteriormente, retorna inmediatamente porque la entrada de la cola de espera ya se elimin\u00f3 de la cola de espera. El error es que rq_qos_wake_function() est\u00e1 accediendo a la entrada de la cola de espera DESPU\u00c9S de eliminarla. Tenga en cuenta que autoremove_wake_function() despierta al que espera y LUEGO elimina la entrada de la cola de espera, que es el orden correcto. Arr\u00e9glelo intercambiando el orden. Tambi\u00e9n debemos usar list_del_init_careful() para que coincida con list_empty_careful() en finish_wait().\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":4.7,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.19\",\"versionEndExcluding\":\"5.10.228\",\"matchCriteriaId\":\"AC13DFD5-0BA4-4713-BBB2-F08C0E282CB9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.169\",\"matchCriteriaId\":\"18BEDAD6-86F8-457C-952F-C35698B3D07F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.114\",\"matchCriteriaId\":\"10FD2B3E-C7D9-4A9C-BD64-41877EDF88EB\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.58\",\"matchCriteriaId\":\"6B9489BC-825E-4EEE-8D93-F93C801988C8\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.11.5\",\"matchCriteriaId\":\"6E62D61A-F704-44DB-A311-17B7534DA7BC\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7F361E1D-580F-4A2D-A509-7615F73167A1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"3C95E234-D335-4B6C-96BF-E2CEBD8654ED\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d04b72c9ef2b0689bfc1057d21c4aeed087c329f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb148667fb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}"
  }
}


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.