{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2023-53024 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2023-53024 is a high-severity vulnerability in Linux kernel, published on 27 Mar 2025. 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-2023-53024 and fix it if it is affected.\n\nWhat it is: CVE-2023-53024 is a high-severity vulnerability in Linux kernel, published on 27 Mar 2025. 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-2023-53024 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-2023-53024/ (Markdown: https://insights.sbomify.com/CVE-2023-53024/index.md)","id":"CVE-2023-53024","markdown":"https://insights.sbomify.com/CVE-2023-53024/index.md","name":"CVE-2023-53024","record":{"aliases":["BELL-CVE-2023-53024","DEBIAN-CVE-2023-53024","GHSA-mqh3-5x68-9v64","UBUNTU-CVE-2023-53024"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel BPF","requires_auth":"low_privilege","summary":"An attacker can leak kernel pointer values via speculative execution side channels in the Linux kernel BPF subsystem.","user_interaction":"not_required","vuln_class":"information_disclosure"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.1,"severity":"high","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix pointer-leak due to insufficient speculative store bypass mitigation\n\nTo mitigate Spectre v4, 2039f26f3aca (\"bpf: Fix leakage due to\ninsufficient speculative store bypass mitigation\") inserts lfence\ninstructions after 1) initializing a stack slot and 2) spilling a\npointer to the stack.\n\nHowever, this does not cover cases where a stack slot is first\ninitialized with a pointer (subject to sanitization) but then\noverwritten with a scalar (not subject to sanitization because\nthe slot was already initialized). In this case, the second write\nmay be subject to speculative store bypass (SSB) creating a\nspeculative pointer-as-scalar type confusion. This allows the\nprogram to subsequently leak the numerical pointer value using,\nfor example, a branch-based cache side channel.\n\nTo fix this, also sanitize scalars if they write a stack slot\nthat previously contained a pointer. Assuming that pointer-spills\nare only generated by LLVM on register-pressure, the performance\nimpact on most real-world BPF programs should be small.\n\nThe following unprivileged BPF bytecode drafts a minimal exploit\nand the mitigation:\n\n  [...]\n  // r6 = 0 or 1 (skalar, unknown user input)\n  // r7 = accessible ptr for side channel\n  // r10 = frame pointer (fp), to be leaked\n  //\n  r9 = r10 # fp alias to encourage ssb\n  *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked\n  // lfence added here because of pointer spill to stack.\n  //\n  // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor\n  // for no r9-r10 dependency.\n  //\n  *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr\n  // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,\n  // store may be subject to SSB\n  //\n  // fix: also add an lfence when the slot contained a ptr\n  //\n  r8 = *(u64 *)(r9 - 8)\n  // r8 = architecturally a scalar, speculatively a ptr\n  //\n  // leak ptr using branch-based cache side channel:\n  r8 \u0026= 1 // choose bit to leak\n  if r8 == 0 goto SLOW // no mispredict\n  // architecturally dead code if input r6 is 0,\n  // only executes speculatively iff ptr bit is 1\n  r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)\nSLOW:\n  [...]\n\nAfter running this, the program can time the access to *(r7 + 0) to\ndetermine whether the chosen pointer bit was 0 or 1. Repeat this 64\ntimes to recover the whole address on amd64.\n\nIn summary, sanitization can only be skipped if one scalar is\noverwritten with another scalar. Scalar-confusion due to speculative\nstore bypass can not lead to invalid accesses because the pointer\nbounds deducted during verification are enforced using branchless\nlogic. See 979d63d50c0c (\"bpf: prevent out of bounds speculation on\npointer arithmetic\") for details.\n\nDo not make the mitigation depend on !env-\u003eallow_{uninit_stack,ptr_leaks}\nbecause speculative leaks are likely unexpected if these were enabled.\nFor example, leaking the address to a protected log file may be acceptable\nwhile disabling the mitigation might unintentionally leak the address\ninto the cached-state of a map that is accessible to unprivileged\nprocesses.","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":"bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation","id":"CVE-2023-53024","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"information_disclosure","year":"2023"},"n_packages":0,"n_references":6,"next":{"headline":"This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.","id":"CVE-2023-53025"},"packages":[],"prev":{"headline":"net: nfc: Fix use-after-free in local_cleanup()","id":"CVE-2023-53023"},"products":["Linux"],"published":"2025-03-27","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":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-23","vendors":["Linux"]},"summary":"An attacker can leak kernel pointer values via speculative execution side channels in the Linux kernel BPF subsystem.","url":"https://insights.sbomify.com/CVE-2023-53024/"}