CVE-2026-98631: Linux kernel · xsk: Use a 32-bit compare in xsk_map_gen_lookup
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in c6d5c582d55a8f229d75e98d62eaa065b0deb18d : update Linux kernel when convenient.
Data as of 26 Oct 2026, 17:16 UTC
Rated Medium by Threat Radar's AI analysis · CVSS not yet scored by NVD
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 11% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in c6d5c582d55a8f229d75e98d62eaa065b0deb18d, b5c0cff0c5331582ab01c4c423731453a8381acc, 70504de0bb627848667207bec7ccfd647deb8814 +5
Exploitation evidence
Disclosed: evidence found.
CVE published 18 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
AI-suggested
A fix is available and has been applied in the Linux kernel. Users should update to a fixed kernel version containing the patches identified by the provided commit hashes. No additional mitigation is required once the kernel is updated.
Description
A vulnerability in the Linux kernel's xsk_map_gen_lookup function allows an out-of-bounds read due to improper comparison of a 32-bit key against max_entries. The issue arises because BPF_JMP_IMM sign-extends immediates to 64 bits, causing the bounds check to be bypassed for large max_entries values. This flaw has been fixed by changing the comparison to use a 32-bit unsigned check.
References
- git.kernel.org/stable/c/c6d5c582d55a8f229d75e98d62eaa065b0deb18d (opens in a new tab)
- git.kernel.org/stable/c/227ec890559e922e235eb543646e3bf0bd8269b0 (opens in a new tab)
- git.kernel.org/stable/c/11d9be35c1f4233798e99be98bc474f83a254c6c (opens in a new tab)
- git.kernel.org/stable/c/123f90f394ca404ab8796a7c8072ff7fa5b65a9c (opens in a new tab)
- git.kernel.org/stable/c/36461e58f88a1b723f86693f437ac12e60ff4363 (opens in a new tab)
- git.kernel.org/stable/c/b5c0cff0c5331582ab01c4c423731453a8381acc (opens in a new tab)
- git.kernel.org/stable/c/3c1e0a4bc156b8d5c5772dbc76b9ea74dce5ca24 (opens in a new tab)
- git.kernel.org/stable/c/70504de0bb627848667207bec7ccfd647deb8814 (opens in a new tab)