{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-50082 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-50082 is a high-severity vulnerability in Linux kernel, published on 29 Oct 2024. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-50082 and fix it if it is affected.\n\nWhat it is: CVE-2024-50082 is a high-severity vulnerability in Linux kernel, published on 29 Oct 2024. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-50082 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2024-50082/ (Markdown: https://insights.sbomify.com/CVE-2024-50082/index.md)","id":"CVE-2024-50082","markdown":"https://insights.sbomify.com/CVE-2024-50082/index.md","name":"CVE-2024-50082","record":{"aliases":["AZL-51930","AZL-51954","BELL-CVE-2024-50082","DEBIAN-CVE-2024-50082","GHSA-58q9-jhx4-mj9p","UBUNTU-CVE-2024-50082"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel block layer can cause a system crash, leading to denial of service.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"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're 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's 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's 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().","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race","id":"CVE-2024-50082","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"race_condition","year":"2024"},"n_packages":0,"n_references":7,"next":{"headline":"tcp: fix mptcp DSS corruption due to large pmtu xmit","id":"CVE-2024-50083"},"packages":[],"prev":{"headline":"blk-mq: setup queue -\u003etag_set before initializing hctx","id":"CVE-2024-50081"},"products":["Linux"],"published":"2024-10-29","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"total"},"state":"PUBLISHED","updated":"2026-10-15","vendors":["Linux"]},"summary":"A race condition in the Linux kernel block layer can cause a system crash, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2024-50082/"}