{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98801 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98801 is a vulnerability in Linux, published on 18 Oct 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-98801 and fix it if it is affected.\n\nWhat it is: CVE-2026-98801 is a vulnerability in Linux, published on 18 Oct 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-98801 in the wild and no public exploit code.\n\nAffected product: Linux. 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-2026-98801/ (Markdown: https://insights.sbomify.com/CVE-2026-98801/index.md)","id":"CVE-2026-98801","markdown":"https://insights.sbomify.com/CVE-2026-98801/index.md","name":"CVE-2026-98801","record":{"aliases":["AZL-109077","BELL-CVE-2026-98801","DEBIAN-CVE-2026-98801","GHSA-4vp5-jwr6-3q9m","UBUNTU-CVE-2026-98801"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","privilege_escalation"],"network_reachable":"yes","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A local attacker can trigger integer overflows and memory corruption in the Linux kernel via SO_RESERVE_MEM, potentially causing denial of service or privilege escalation.","user_interaction":"not_required","vuln_class":"integer_overflow"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: restrict SO_RESERVE_MEM to TCP sockets and cap max value\n\nCommit 2bb2f5fb21b0 (\"net: add new socket option SO_RESERVE_MEM\") and\ncommit d00c8ee31729 (\"net: fix possible NULL deref in sock_reserve_memory\")\nonly checked sk_has_account(sk), which is true for both TCP and UDP\nsockets.\n\nHowever, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only\nsupported by TCP:\n- On UDP sockets, sk-\u003esk_forward_alloc is protected by\n  sk-\u003esk_receive_queue.lock, whereas sock_reserve_memory() and\n  sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent\n  UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt\n  sk_forward_alloc and memcg accounting.\n- udp_rmem_release() reclaims excess sk_forward_alloc without\n  accounting for sk_unused_reserved_mem(sk).\n\nRestrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now.\nSupporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and\nhonoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in\na future net-next series if needed.\n\nIn addition, reject val \u003e SZ_1G with -EINVAL in\nsk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near\nINT_MAX cause sk_mem_pages(delta) and (pages \u003c\u003c PAGE_SHIFT) to overflow\n32-bit signed int, corrupting sk-\u003esk_forward_alloc and\nsk-\u003esk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the\npage-rounded sk-\u003esk_reserved_mem reported by getsockopt(SO_RESERVE_MEM)\ncan always be passed back to setsockopt(SO_RESERVE_MEM).","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":"net: restrict SO_RESERVE_MEM to TCP sockets and cap max value","id":"CVE-2026-98801","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"integer_overflow","year":"2026"},"n_packages":0,"n_references":4,"next":{"headline":"seg6: ensure packet data is writable before modifying SRH and IPv6 DA","id":"CVE-2026-98802"},"packages":[],"prev":{"headline":"bpf: Wait for an RCU tasks grace period before freeing trampoline progs","id":"CVE-2026-98800"},"products":["Linux"],"published":"2026-10-18","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A local attacker can trigger integer overflows and memory corruption in the Linux kernel via SO_RESERVE_MEM, potentially causing denial of service or privilege escalation.","url":"https://insights.sbomify.com/CVE-2026-98801/"}