CVE-2022-0995 is an out-of-bounds write vulnerability in Linux Kernel. CISA added it to the Known Exploited Vulnerabilities catalogue on 26 August 2026, which means attackers have used it in real attacks. Linux Kernel contains an out-of-bounds memory write vulnerability which could allow a local user to gain privileged access or cause a denial of service on the system.
What This Vulnerability Means in the Linux Kernel
CVE-2022-0995 is an out-of-bounds write in the Linux Kernel, which means memory can be overwritten outside the intended boundary. In practice, that class of bug is dangerous because kernel code runs with high trust, so even a local flaw can become a system-level security problem.
The important takeaway is that the issue is not just a crash condition. An out-of-bounds write can corrupt data structures, alter control flow, or destabilize the kernel, which is why vulnerabilities of this type are often treated as high-priority security defects rather than ordinary reliability bugs.
For reference details, use the CVE Program as the canonical record for the identifier and the NIST National Vulnerability Database for authoritative vulnerability metadata.
How Out-of-Bounds Writes Become a Security Problem
Kernel memory corruption is especially dangerous because the kernel mediates process isolation, device access, filesystem operations, and privilege enforcement. If a local attacker can influence memory at the wrong location, the result may be privilege escalation, denial of service, or both, depending on what gets overwritten and how the kernel handles the damage.
This is why memory safety bugs in core system components are so closely watched. A flaw in user-space code may affect one application, but a flaw in the kernel can affect the whole host, including security tooling, containers, and other workloads sharing that system.
Attackers and defenders both benefit from mapping the issue to weakness patterns such as the CWE Top 25 Guide, which includes out-of-bounds write and related memory safety classes.
Exposure, Detection, and Verification
Organisations should first determine whether any deployed Linux kernels are exposed, especially on internet-facing systems, privilege-sensitive hosts, and endpoints where local access could be obtained through another weakness. Exposure assessment should combine asset inventory, kernel lineage, vendor advisories, and knowledge of where Linux is embedded in servers, appliances, containers, and virtualised platforms.
Detection is not limited to finding the CVE name in a scanner report. Teams should look for affected asset groups, confirm whether the vulnerable kernel is actually running, and review whether the system has been reachable to local users or secondary compromise paths. The Vulnerability Management Guide is useful here because this sort of issue needs prioritisation, verification, and exception handling, not just ticket creation.
Where patching is delayed, compensating controls matter. Reduce local access, tighten privileged shell access, limit untrusted code execution, and monitor for instability or suspicious kernel faults while the remediation window remains open. For high-value systems, treat the vulnerability as part of a broader exploitability review rather than a standalone scanner finding.
Remediation, Compensating Controls, and Post-Exploitation Review
The preferred remediation path is to apply the vendor’s fixed kernel release as directed by the distro maintainer or Linux vendor advisory. When immediate patching is not possible, organisations should narrow the attack surface around the host, restrict who can obtain local execution, and document the temporary exception with an expiry date and owner.
Because successful exploitation can grant privileged access, remediation should be paired with compromise review. Check for unusual privilege changes, suspicious kernel messages, unexplained crashes, new persistence mechanisms, and any evidence that an attacker used the host after gaining elevated rights. If compromise is suspected, review credentials, tokens, SSH access material, and administrative sessions associated with that machine.
Kernel flaws are often used as a stepping stone, not the end goal. A local exploit that reaches root can support lateral movement, tampering, or stealthy persistence, so post-patch validation should ask not only whether the crash is gone, but whether the host was already abused before the fix landed.
Risk and Threat Considerations
Because this is a known exploited Linux Kernel memory corruption issue, the main risk is privilege escalation from local access, with denial of service as a secondary outcome. That combination matters because attackers often chain a local kernel bug with an initial foothold to turn limited access into full host control.
Failure mechanism: An attacker or malicious local process reaches the vulnerable code path, overwrites memory outside the intended buffer boundary, and manipulates kernel state in a way that changes control or stability.
Impact: The system may crash, become unstable, or grant elevated privileges that let an attacker disable defenses, persist, or move deeper into the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Kernel CVEs require tracked remediation of exploitable software flaws. |
| SI-16 — Memory Protection | Out-of-bounds writes are memory-corruption defects addressed by memory protection controls. | |
| AC-6 — Least Privilege | Local exploitation becomes more damaging when users or services have excessive privilege. | |
| Recommendation — Prioritise SI-2 for affected Linux hosts and verify remediation against vendor guidance. Apply SI-16 protections and hardening to reduce unsafe memory access paths. Restrict local privilege and administrative access to limit exploit impact. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE needs inventory, prioritisation, remediation tracking, and verification. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Hardening and configuration discipline reduce exposure while patching is pending. | |
| Recommendation — Track exposed kernels in CIS-7 and accelerate remediation for known-exploited flaws. Harden Linux hosts under CIS-4 to reduce attack surface until patching is complete. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | The vulnerability can be used to gain privileged access from a local foothold. |
| T1069 — Permission Groups Discovery | Privilege escalation frequently follows discovery of local permissions and rights. | |
| T1499 — Endpoint Denial of Service | The vulnerability can also cause denial of service through kernel instability or crash. | |
| Recommendation — Map suspicious local kernel exploitation to T1068 and hunt for privilege escalation. Hunt for post-exploitation privilege discovery and unexpected admin capability changes. Correlate crashes and instability with T1499 when the host becomes unavailable. | ||