CVE-2026-22990
Linux Kernel 2.6.34.1 – 5.10.248
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-22990 is a high-severity Reachable Assertion (CWE-617) vulnerability in Linux Linux Kernel. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Application or System Exploitation (T1499.004); ranked at the 27th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-22990 is a vulnerability in the Linux kernel's libceph module, specifically within the osdmap_apply_incremental() function. The issue stems from an overzealous BUG_ON check that triggers a kernel panic if an osdmap—potentially maliciously corrupted such that its incremental epoch differs from the expected value—is processed. This affects Linux kernel versions with Ceph filesystem support enabled, as libceph handles OSD (object storage daemon) map updates from Ceph clusters.
A remote, unauthenticated attacker can exploit this vulnerability over the network with low complexity and no user interaction required, as indicated by its CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). By sending a crafted, corrupted incremental osdmap with a mismatched epoch to a vulnerable system acting as a Ceph client, the attacker triggers the BUG_ON, resulting in a denial-of-service condition through kernel crash or panic.
The provided kernel stable commit references detail the fix: replacing the BUG_ON with logic to simply declare the incremental osdmap invalid, preventing the crash while maintaining functionality for valid inputs. Security practitioners should apply these patches—such as commits 4b106fbb1c7b, 6348d70af847, 6afd2a421352, 6c6cec3db3b418c, and 9aa0b0c14cef—from the Linux kernel stable trees to mitigate the issue.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-4287
Vulnerability Data
In the Linux kernel, the following vulnerability has been resolved: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG.…
more
Instead, just declare the incremental osdmap to be invalid.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation finds reachable assertions during development.
Security engineering principles discourage use of assertions for handling untrusted input.
Validating untrusted inputs structurally prevents attacker data from reaching and triggering assertions.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent unsafe assertions from being coded in reachable paths.
Runtime monitoring of software can detect assertion-triggered crashes as adverse events.
Vulnerability identification processes can discover and record reachable-assertion flaws before deployment.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect reachable assertions before release, reducing the likelihood of exploitation.
Secure development lifecycle mandates defensive coding and input validation that prevent reachable assertions from being triggered by untrusted data.
Application security requirements can specify that assertions must not be reachable from attacker-controlled inputs.
Secure architecture principles discourage the use of assertions for runtime error handling that an attacker could exploit.
Secure coding standards explicitly ban the use of assert() or equivalent statements that can be triggered by external input.