ZeroDayAlert

CVE-2022-0995: Linux Kernel Out-of-Bounds Write Vulnerability

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.

Linux Kernel Added to KEV 2026-08-26 Federal due 2026-09-09 Known ransomware use

Required action — quoted from CISA

Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Where this comes from. The identifier, product, dates and required action above are copied verbatim from the CISA Known Exploited Vulnerabilities catalog. The action plan below is written by an AI agent from that record and published automatically. AssurePort has not independently tested this vulnerability and makes no claim about whether any specific system is affected.

Who is affected

This vulnerability affects systems running the Linux Kernel. The flaw permits a local user to write to memory outside intended bounds, potentially leading to privilege escalation or denial of service. The record does not specify which kernel versions are affected, nor does it enumerate particular Linux distributions; you will need to cross-reference vendor advisories to establish which of your running kernels fall into the vulnerable range.

How to check whether this touches you

  • Inventory all systems running Linux: physical servers, virtual machines, containers, and embedded devices. Note the distribution and kernel version on each.
  • Determine whether each system accepts login or code execution from untrusted local users (including unprivileged accounts, container workloads, or service daemons). Systems with no local user boundary are at lower risk from a privilege-escalation variant of this flaw.
  • Retrieve the running kernel version from each system using uname -r and cross-reference it against Linux vendor security advisories (Red Hat, Canonical, SUSE, Debian, etc.). Kernel version alone is not conclusive, as some vendors backport security fixes; check vendor patch status documentation.
  • For systems you cannot patch immediately, document the kernel release date and compare it against the vulnerability disclosure timeline to assess likelihood of prior exploitation.

What to do

  1. Obtain the canonical remediation guidance from your Linux vendor (Red Hat Security Advisories, Ubuntu Security Notices, SUSE Security Updates, or Debian Security Tracker, as applicable). Confirm patch availability and test in a non-production environment before deployment.
  2. If patching cannot be done immediately, restrict local login and code execution to trusted users only. Disable unnecessary network services and container execution on the affected system.
  3. Enable process accounting and audit logging (auditd on most distributions) to capture local process execution. Configure log retention to at least 90 days to support retrospective investigation if needed.
  4. Prioritise patching according to CISA BOD 26-04 guidance: assets directly connected to the internet or hosting internet-facing services should be patched within 15 days; internal systems should follow the 30-day timeline where risk permits.
  5. Escalate to your incident response or security team any system where patching cannot be completed within the required timeframe, or where business continuity requires continued use of an unpatched kernel.

If you find you were exposed

Exploitation of local privilege-escalation flaws typically occurs long after initial access is gained through a network compromise or supply-chain insertion. Examine system logs, container image registries, and process accounting records from at least 90 days before the vulnerability disclosure date to search for suspicious local process execution, privilege escalation attempts, or unexpected system calls. Pay particular attention to audit logs showing unprivileged processes attempting to change UID or access kernel memory. Log retention policies are often the limiting factor; if logs covering the relevant period are not available, document that gap and assume potential exposure.

Get these the morning they land.

One email, only when a vulnerability is newly confirmed as exploited — the CISA record plus our action plan. No more than one a day, and nothing on quiet days.

Knowing it exists is not the same as knowing you are exposed.

This page can tell you that CVE-2022-0995 is being exploited. It cannot tell you whether Kernel is running somewhere of yours that is reachable. That question is what a scan answers.

Check your own surface →