{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-50099 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-50099 is a high-severity denial of service vulnerability in Linux kernel, published on 5 Nov 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-50099 and fix it if it is affected.\n\nWhat it is: CVE-2024-50099 is a high-severity denial of service vulnerability in Linux kernel, published on 5 Nov 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-50099 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-50099/ (Markdown: https://insights.sbomify.com/CVE-2024-50099/index.md)","id":"CVE-2024-50099","markdown":"https://insights.sbomify.com/CVE-2024-50099/index.md","name":"CVE-2024-50099","record":{"aliases":["AZL-52555","AZL-52578","BELL-CVE-2024-50099","DEBIAN-CVE-2024-50099","GHSA-pj67-hxcx-g74v","UBUNTU-CVE-2024-50099"],"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 flaw in Linux kernel arm64 uprobes allows local attackers to trigger a kernel panic or lockup by exploiting unsafe memory access patterns in literal load simulations.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.3,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Remove broken LDR (literal) uprobe support\n\nThe simulate_ldr_literal() and simulate_ldrsw_literal() functions are\nunsafe to use for uprobes. Both functions were originally written for\nuse with kprobes, and access memory with plain C accesses. When uprobes\nwas added, these were reused unmodified even though they cannot safely\naccess user memory.\n\nThere are three key problems:\n\n1) The plain C accesses do not have corresponding extable entries, and\n   thus if they encounter a fault the kernel will treat these as\n   unintentional accesses to user memory, resulting in a BUG() which\n   will kill the kernel thread, and likely lead to further issues (e.g.\n   lockup or panic()).\n\n2) The plain C accesses are subject to HW PAN and SW PAN, and so when\n   either is in use, any attempt to simulate an access to user memory\n   will fault. Thus neither simulate_ldr_literal() nor\n   simulate_ldrsw_literal() can do anything useful when simulating a\n   user instruction on any system with HW PAN or SW PAN.\n\n3) The plain C accesses are privileged, as they run in kernel context,\n   and in practice can access a small range of kernel virtual addresses.\n   The instructions they simulate have a range of +/-1MiB, and since the\n   simulated instructions must itself be a user instructions in the\n   TTBR0 address range, these can address the final 1MiB of the TTBR1\n   acddress range by wrapping downwards from an address in the first\n   1MiB of the TTBR0 address range.\n\n   In contemporary kernels the last 8MiB of TTBR1 address range is\n   reserved, and accesses to this will always fault, meaning this is no\n   worse than (1).\n\n   Historically, it was theoretically possible for the linear map or\n   vmemmap to spill into the final 8MiB of the TTBR1 address range, but\n   in practice this is extremely unlikely to occur as this would\n   require either:\n\n   * Having enough physical memory to fill the entire linear map all the\n     way to the final 1MiB of the TTBR1 address range.\n\n   * Getting unlucky with KASLR randomization of the linear map such\n     that the populated region happens to overlap with the last 1MiB of\n     the TTBR address range.\n\n   ... and in either case if we were to spill into the final page there\n   would be larger problems as the final page would alias with error\n   pointers.\n\nPractically speaking, (1) and (2) are the big issues. Given there have\nbeen no reports of problems since the broken code was introduced, it\nappears that no-one is relying on probing these instructions with\nuprobes.\n\nAvoid these issues by not allowing uprobes on LDR (literal) and LDRSW\n(literal), limiting the use of simulate_ldr_literal() and\nsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR\n(literal) and LDRSW (literal) will be rejected as\narm_probe_decode_insn() will return INSN_REJECTED. In future we can\nconsider introducing working uprobes support for these instructions, but\nthis will require more significant work.","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":"arm64: probes: Remove broken LDR (literal) uprobe support","id":"CVE-2024-50099","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"denial_of_service","year":"2024"},"n_packages":0,"n_references":8,"next":{"headline":"USB: gadget: dummy-hcd: Fix \"task hung\" problem","id":"CVE-2024-50100"},"packages":[],"prev":{"headline":"scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down","id":"CVE-2024-50098"},"products":["Linux"],"published":"2024-11-05","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":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A flaw in Linux kernel arm64 uprobes allows local attackers to trigger a kernel panic or lockup by exploiting unsafe memory access patterns in literal load simulations.","url":"https://insights.sbomify.com/CVE-2024-50099/"}