CVE-2022-0995: Linux Kernel watch_queue Out-of-Bounds Write and Privilege Escalation

CVE-2022-0995 is a Linux kernel memory corruption vulnerability in the watch_queue event notification subsystem that allows a locally authenticated, low-privileged user to trigger an out-of-bounds write in kernel memory. Under exploitable conditions, that corruption can be converted into local privilege escalation, potentially turning an ordinary Linux account into root access.

The vulnerability is not new. It was disclosed in March 2022, assigned a CVSS 3.1 base score of 7.8 High, and classified as CWE-787: Out-of-Bounds Write. The NVD currently describes the impact as potentially allowing a local user to overwrite kernel state, gain privileged access, or cause denial of service. Its CVSS vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H: local attack vector, low complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact. (NVD)

What makes CVE-2022-0995 especially relevant again is something that happened more than four years after the original disclosure.

על August 26, 2026, CISA added CVE-2022-0995 to its Known Exploited Vulnerabilities Catalog, stating that the new additions were based on evidence of active exploitation. The KEV remediation deadline associated with CVE-2022-0995 is September 9, 2026. (CISA)

That changes how defenders should think about the bug. CVE-2022-0995 is no longer simply an old Linux privilege-escalation CVE with public proof-of-concept code. It is now a vulnerability for which exploitation has been observed in real-world conditions.

For organizations still running old Linux kernels, forgotten appliances, long-lived cloud images, container hosts, development systems, or embedded deployments, CVE-2022-0995 deserves another inventory check.

CVE-2022-0995 at a Glance

שדה	פרטים
CVE	CVE-2022-0995
רכיב	Linux kernel watch_queue
פגיעות	Out-of-bounds kernel memory write
CWE	CWE-787
Primary function	watch_queue_set_filter()
וקטור התקפה	Local
Privileges required	נמוך
User interaction	אף אחד
CVSS 3.1	7.8 High
Potential impact	Privilege escalation, kernel memory corruption, denial of service
Introduced around	Linux 5.8 watch_queue implementation
Important upstream fixes	5.10.106, 5.15.29, 5.16.15, Linux 5.17 mainline
Public exploit code	כן
CISA KEV	כן
KEV addition	August 26, 2026
Federal remediation date	September 9, 2026

The vulnerability is particularly interesting because the underlying programming error looks trivial: two pieces of almost identical validation code calculate the maximum valid filter type differently.

One is correct.

The other is wrong by a large factor on 64-bit systems.

That difference is enough to turn attacker-controlled input into kernel heap corruption.

What Is Linux watch_queue?

Understanding CVE-2022-0995 requires understanding the subsystem it affects.

Linux watch_queue provides a general-purpose mechanism for delivering kernel notifications into user space. The mechanism is built around special pipes that act as notification queues.

The kernel documentation describes a watch queue as a buffer into which notification records are written. Userspace applications can create a notification pipe and subscribe that queue to kernel objects or event sources. The queue can additionally contain filters specifying which notification types should be accepted. (kernel.org)

Conceptually, the architecture looks like this:

Kernel object
     |
     | event
     v
Watch / subscription
     |
     v
watch_queue
     |
     | filter notification type
     v
Notification pipe
     |
     v
Userspace application

A process does not necessarily want every event associated with an object. It therefore submits filter rules that tell the kernel which notification types and subtypes should be delivered.

The internal kernel representation includes a structure similar to:

struct watch_filter {
    union {
        struct rcu_head rcu;
        DECLARE_BITMAP(type_filter, WATCH_TYPE__NR);
    };

    u32 nr_filters;
    struct watch_type_filter filters[];
};

Modern kernel source still shows the type_filter bitmap followed by a flexible filters[] array. (codebrowser.dev)

This memory layout is important.

CVE-2022-0995 allows attacker-controlled filter information to escape the intended boundaries of these structures.

The Vulnerable Function: watch_queue_set_filter

The critical code is inside:

watch_queue_set_filter()

The function processes filtering rules supplied from userspace.

A simplified flow is:

Userspace filter
      |
      v
copy / duplicate filter data
      |
      v
Validate filter entries
      |
      v
Count accepted filters
      |
      v
Allocate watch_filter
      |
      v
Copy accepted filters
      |
      v
Set corresponding bits in type_filter

The kernel must ensure that the notification סוג supplied by userspace represents a valid type before it uses that number as either a bitmap index or an indication that a filter entry should be copied.

And that is exactly where the bug occurred.

The Boundary Check That Caused CVE-2022-0995

The original implementation performed two closely related checks.

The first one effectively calculated the number of bits contained inside the type_filter bitmap as:

if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
    continue;

This expression makes sense.

sizeof() returns a value in bytes.

There are eight bits per byte.

Therefore:

bytes × 8 = number of bits

If a bitmap is 16 bytes long, for example:

16 bytes × 8 = 128 bits

so valid bit indices range from 0 through 127.

But later in the same function, a second check used:

if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
    continue;

That looks superficially similar.

It is not.

The upstream patch explicitly identifies this discrepancy and explains that it can result in both an out-of-bounds __set_bit() operation and writes beyond the number of filters[] elements that were allocated. (git.zx2c4.com)

On a typical 64-bit Linux system:

BITS_PER_LONG = 64

So instead of calculating:

bytes × 8

the second validation calculated:

bytes × 64

The permitted range could therefore become eight times larger than intended.

That is the core arithmetic mistake behind CVE-2022-0995.

Why the Error Is Worse Than a Simple Invalid Index

The problem is not merely that the kernel accepts an unusual notification type.

The inconsistent checks affect how many filters the kernel believes it needs to allocate and which entries it subsequently copies.

The patched kernel description identifies two separate out-of-bounds writes.

The first is an out-of-bounds operation involving:

__set_bit(q->type, wfilter->type_filter);

The second occurs because the kernel can write more objects into:

wfilter->filters[]

than were actually allocated. (patchew.org)

That second behavior is particularly significant.

Consider a simplified conceptual allocation:

+----------------------------+
| watch_filter header        |
+----------------------------+
| type_filter bitmap         |
+----------------------------+
| filters[0]                 |
+----------------------------+
| filters[1]                 |
+----------------------------+
| END OF ALLOCATED OBJECT    |
+----------------------------+
| neighboring heap object    |
+----------------------------+

Under normal circumstances, all writes stop before the end of the object.

With CVE-2022-0995, an attacker-controlled filter can cause a write to extend into memory following that allocation:

+----------------------------+
| watch_filter header        |
+----------------------------+
| type_filter bitmap         |
+----------------------------+
| filters[0]                 |
+----------------------------+
| END OF ALLOCATED OBJECT    |
+============================+
| attacker-induced write     |  <-- OOB
+============================+
| neighboring kernel object  |
+----------------------------+

Because this memory belongs to the kernel heap, the consequences are substantially more serious than corrupting memory inside an ordinary process.

Why Kernel Heap Corruption Can Become Privilege Escalation

The Linux kernel controls essentially every security boundary on the operating system.

Among other things, kernel memory contains data relating to:

• process credentials;
• file descriptors;
• IPC objects;
• namespace structures;
• networking;
• filesystem state;
• security modules;
• kernel object metadata.

A low-privileged process normally cannot modify any of those structures directly.

Kernel memory corruption vulnerabilities change that assumption.

The attacker does not necessarily need the original vulnerable object to contain something security-sensitive. Instead, exploitation frequently attempts to influence the state of the kernel heap so that a useful target object is placed adjacent to the corrupted allocation.

This general technique is usually described as heap grooming.

Conceptually:

1. Allocate many controllable kernel objects
2. Free selected objects
3. Trigger allocations of vulnerable watch_filter objects
4. Shape SLUB allocator behavior
5. Position a useful object near the overflow
6. Trigger the out-of-bounds write
7. Corrupt security-sensitive state
8. Convert corruption into an exploitation primitive
9. Escalate privileges

The precise exploitation strategy depends on kernel version, allocator behavior, mitigations, configuration, and target objects.

This is why a vulnerability described as an “out-of-bounds write” can ultimately become a root-level privilege escalation.

From a Low-Privileged Shell to Root

CVE-2022-0995 is classified as a מקומי vulnerability.

That means it is not normally an initial-access vulnerability.

An attacker generally needs some ability to execute code on the affected Linux system first.

A realistic attack chain could look like:

External vulnerability / stolen credentials
                |
                v
      Low-privileged shell
                |
                v
        CVE-2022-0995
                |
                v
      Kernel heap corruption
                |
                v
       Privilege escalation
                |
                v
              root
                |
                v
 persistence / credential theft /
 lateral movement / security bypass

This distinction matters operationally.

A local privilege-escalation bug may initially appear less urgent than an unauthenticated remote code execution vulnerability.

But modern intrusions frequently involve exactly this combination:

Initial access
      +
Local privilege escalation

For example, an internet-facing service vulnerability might give the attacker command execution as:

www-data

or:

nginx

or an application-specific service account.

Without a privilege-escalation primitive, that foothold may remain partially constrained.

With a reliable kernel LPE, the attacker can attempt to cross the operating-system privilege boundary.

That is what makes vulnerabilities such as CVE-2022-0995 valuable in post-exploitation chains.

Why CISA KEV Status Matters

CVE-2022-0995 was disclosed in 2022.

Public exploit research followed.

For years, security teams could reasonably classify it as an old but known Linux kernel LPE that should already have disappeared from normally maintained environments.

Then the threat picture changed.

On August 26, 2026, CISA added CVE-2022-0995 to its Known Exploited Vulnerabilities Catalog. CISA’s accompanying alert said the six newly added vulnerabilities were included based on evidence of active exploitation. (CISA)

The distinction between a vulnerability with a public PoC and a KEV vulnerability is important.

A public PoC demonstrates:

Someone knows how to trigger or exploit this bug.

KEV status indicates:

CISA has evidence that attackers have exploited the vulnerability outside a purely theoretical research context.

That does not mean every detail of the activity is public.

At the time of writing on August 27, 2026, the public CISA material surfaced for CVE-2022-0995 does not identify a specific threat actor, malware family, victim set, or ransomware campaign responsible for the observed exploitation.

Organizations should therefore avoid turning “known exploited” into unsupported claims about a particular campaign.

What can be said confidently is that CVE-2022-0995 has crossed the boundary from public exploitability into confirmed exploitation concern.

Public Exploitation Was Possible Long Before KEV

Public exploitation research on CVE-2022-0995 has existed since 2022.

NVD references public exploit material from Packet Storm, and a public GitHub implementation targeting Ubuntu 21.10 running kernel 5.13.0-37 describes a full privilege-escalation exploit rather than simply a crash reproducer. The author notes that reliability is imperfect and that kernel panic is possible. (NVD)

That fact matters because there is a substantial difference between three stages of vulnerability maturity:

Bug description
      ↓
Crash / KASAN reproducer
      ↓
Working privilege-escalation exploit
      ↓
Operational exploitation

CVE-2022-0995 moved through the first three stages years ago.

The 2026 CISA KEV addition provides the reason defenders should revisit the fourth.

The Original KASAN Evidence

Kernel Address Sanitizer, or KASAN, is commonly used by kernel developers and security researchers to detect invalid memory accesses.

The watch_queue bug produced a characteristic error resembling:

BUG: KASAN: slab-out-of-bounds
in watch_queue_set_filter

with an invalid write occurring near the end of a small SLUB allocation.

The upstream vulnerability record documents an example involving a 32-byte kmalloc-32 object and an invalid write near the end of that allocation. (NVD)

That is useful from a defensive perspective.

If an affected Linux system crashes and logs a stack containing:

watch_queue_set_filter

together with:

slab-out-of-bounds

or related memory-corruption messages, CVE-2022-0995 should be considered during investigation.

A crash alone is not evidence of successful exploitation, but on a vulnerable machine it would be highly relevant forensic context.

What the Patch Changed

The upstream developers did not attempt to repair the arithmetic by replacing one multiplier with another.

Instead, the patch removed the fragile size calculation entirely.

The vulnerable logic effectively did this:

if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
    continue;

and later:

if (tf[i].type >=
    sizeof(wfilter->type_filter) * BITS_PER_LONG)
    continue;

The corrected logic uses the actual semantic limit:

if (tf[i].type >= WATCH_TYPE__NR)
    continue;

in both places. (patchew.org)

This is a better fix for an important reason.

The question the kernel really needs to answer is not:

How many bits happen to fit inside this structure?

It is:

Is this a notification type that the kernel actually knows about?

WATCH_TYPE__NR expresses that boundary directly.

That makes the code easier to reason about and avoids coupling security validation to implementation-specific object size calculations.

Which Linux Versions Are Affected?

The vulnerable watch queue implementation dates back to Linux 5.8.

The later Linux CNA record associated with the same upstream watch_queue: Fix filter limit check defect identifies Linux 5.8 as the beginning of the affected code and records fixes in the stable trees at:

Kernel branch	Fixed release
5.10	5.10.106
5.15	5.15.29
5.16	5.16.15
Mainline	5.17

Red Hat’s tracking for the same upstream fix likewise lists 5.10.106, 5.15.29, 5.16.15, and 5.17 as fixed versions. The Linux 5.16.15 changelog specifically includes watch_queue: Fix filter limit check. (bugzilla.redhat.com)

This leads to a practical upstream rule:

Linux 5.8 introduced the vulnerable mechanism.

5.10.x:
    vulnerable before 5.10.106

5.15.x:
    vulnerable before 5.15.29

5.16.x:
    vulnerable before 5.16.15

mainline:
    fix incorporated into Linux 5.17

However, this table must not be treated as a universal distro vulnerability scanner.

Do Not Determine Exposure From uname -r Alone

Linux distribution kernels rarely map perfectly to upstream versions.

Ubuntu, Red Hat, SUSE, Debian, Amazon Linux, Google Cloud kernels, Azure kernels and appliance vendors routinely backport fixes while retaining older-looking version numbers.

Therefore:

uname -r

is useful inventory information, but it is not sufficient proof of vulnerability.

An Ubuntu kernel may look older than upstream 5.15.29 while already containing the backported fix.

Conversely, an abandoned custom 5.15 kernel may remain vulnerable indefinitely.

The correct workflow is:

Identify distribution
        ↓
Identify running kernel package
        ↓
Identify CONFIG_WATCH_QUEUE
        ↓
Consult vendor CVE status
        ↓
Verify patched package
        ↓
Verify patched kernel is actually running

Ubuntu still tracks CVE-2022-0995 as a High-priority kernel vulnerability and describes it as an out-of-bounds write discovered by Jann Horn capable of crashing the system or escalating privileges. (Ubuntu)

Check the Running Kernel

Start with:

uname -a

and:

uname -r

On Debian- or Ubuntu-derived systems:

dpkg -l | grep linux-image

On RPM-based systems:

rpm -qa | grep '^kernel'

The most important distinction is between:

installed kernel

and:

running kernel

Consider this common patching failure:

Old vulnerable kernel is running
        |
apt/yum installs patched kernel
        |
machine is not rebooted
        |
old kernel remains active

Package management may report the fixed kernel as installed even though the vulnerable kernel remains in memory until reboot.

After updating and rebooting, confirm again:

uname -r

Check CONFIG_WATCH_QUEUE

CVE-2022-0995 affects the watch_queue subsystem, which is controlled by the Linux kernel configuration option:

CONFIG_WATCH_QUEUE

Kernel source places the relevant structures behind:

#ifdef CONFIG_WATCH_QUEUE

confirming that whether this subsystem is compiled into the kernel is an important exposure factor. (codebrowser.dev)

On many distributions, you can check the active kernel configuration with:

grep CONFIG_WATCH_QUEUE /boot/config-$(uname -r)

A vulnerable-capable configuration would typically return:

CONFIG_WATCH_QUEUE=y

Some systems expose compressed kernel configuration through /proc/config.gz:

zgrep CONFIG_WATCH_QUEUE /proc/config.gz

If neither file exists, consult the kernel package configuration supplied by the distribution.

Do not assume another distribution’s configuration applies to yours.

The original vulnerability discussion specifically noted differences between distro kernel configurations, which is another reason CVE exposure should be established from the actual deployed kernel rather than generic Linux version information.

Why Multi-User Servers Are Particularly Interesting

CVE-2022-0995 requires local code execution.

On a single-user workstation where only a fully trusted administrator executes software, that requirement may significantly reduce exposure.

The threat model changes on systems such as:

• university compute servers;
• shared development environments;
• hosting infrastructure;
• CI/CD workers;
• bastion servers;
• shell hosting services;
• multi-user research clusters;
• container hosts;
• shared cloud workloads.

Here an attacker may already have intentionally limited access.

לדוגמה:

User A → UID 1001
User B → UID 1002
Build service → UID 1500
root → UID 0

The security model relies on the kernel preventing UID 1001 from crossing into UID 0.

A kernel LPE directly attacks that boundary.

CVE-2022-0995 and Containers

Containers make the discussion more nuanced.

A Docker or Kubernetes container normally shares the kernel of its host.

That means the vulnerable code is not inside the container image in the same sense as OpenSSL or an application library.

It is in the host kernel.

Conceptually:

Container A ─┐
Container B ─┼──> shared Linux kernel
Container C ─┘

Therefore, if a container can reach the vulnerable kernel interface and other security controls do not block the necessary operations, kernel vulnerabilities may become components of container escape or host privilege-escalation chains.

This does לא mean every vulnerable kernel automatically makes every container exploitable.

Container security depends on numerous controls:

• seccomp profiles;
• capabilities;
• namespaces;
• LSM policies;
• runtime configuration;
• syscall exposure;
• container privileges;
• kernel configuration.

But the key architectural fact remains:

Updating packages inside the container does not patch the host’s vulnerable Linux kernel.

The host kernel must be remediated.

Virtual Machines Have a Different Boundary

Virtual machines generally have their own guest kernels.

In that architecture:

Physical host
    |
 hypervisor
    |
+---+---+
|       |
VM A   VM B
kernel kernel

CVE-2022-0995 in VM A affects VM A’s Linux kernel.

A successful exploit would normally compromise the guest’s privileges rather than directly crossing the hypervisor boundary.

The relevant patch target is therefore the guest kernel.

This differs significantly from containers, where many workloads share one host kernel.

Detection Is Harder Than Vulnerability Scanning

Finding a vulnerable kernel is relatively straightforward.

Determining whether CVE-2022-0995 has already been exploited is much harder.

A kernel privilege escalation does not necessarily leave a convenient log message saying:

CVE-2022-0995 exploited successfully

Defenders should instead correlate several categories of evidence.

Kernel Crashes and Oops Messages

Search kernel logs:

journalctl -k

or:

dmesg

for suspicious strings such as:

watch_queue
watch_queue_set_filter
slab-out-of-bounds
general protection fault
kernel BUG
kernel panic
KASAN

A development or instrumented kernel may provide very explicit evidence.

Production kernels may provide less.

Unexpected Privilege Transitions

Look for processes that unexpectedly transition from low-privileged execution contexts to root-level activity.

Examples include suspicious ancestry like:

web service
   ↓
shell
   ↓
unknown binary
   ↓
root process

or:

ordinary user session
   ↓
temporary executable
   ↓
root shell

The absence of a conventional sudo, su, PAM, or administrative authentication event makes such transitions particularly interesting.

Post-Exploitation Indicators

Once attackers obtain root, CVE-2022-0995 becomes less important to their visible behavior than what they do afterward.

Useful evidence may include:

• new SSH keys;
• modified /etc/passwd;
• altered /etc/shadow;
• unexpected systemd units;
• kernel modules;
• cron persistence;
• suspicious SUID binaries;
• credential dumping;
• security agent termination;
• shell history tampering;
• container runtime access;
• cloud metadata credential theft.

The investigation should therefore treat kernel LPE as one possible step inside a broader attack chain.

Vulnerability Scanners Can Produce Confusing Results

There is another unusual detail surrounding this vulnerability.

Researchers and defenders may encounter a second CVE:

CVE-2022-48847

The Linux CNA published CVE-2022-48847 in 2024 for the vulnerability described as:

watch_queue: Fix filter limit check

The record points to the same affected files, the same underlying incorrect bounds validation, the same upstream fix family, and the stable fixed releases 5.10.106, 5.15.29, 5.16.15 and 5.17. (OpenCVE)

Meanwhile, the older Red Hat-assigned record remains:

CVE-2022-0995

This can produce duplicate-looking findings across security databases.

לדוגמה:

Scanner A:
CVE-2022-0995

Scanner B:
CVE-2022-48847

SBOM platform:
both

Security teams normalizing Linux kernel vulnerabilities should therefore consider the underlying commit and affected code rather than blindly treating every CVE identifier as an unrelated bug.

The important engineering object is:

watch_queue_set_filter()
        +
incorrect filter type bounds check

Why Version Databases Sometimes Disagree

CVE-2022-0995 also demonstrates a broader problem with kernel vulnerability management.

Generic vulnerability databases, distribution trackers, stable kernel records and Linux CNA data can temporarily present different version boundaries.

For this vulnerability, upstream stable records clearly show the filter-limit fix being shipped in Linux 5.16.15, while older NVD CPE history has contained inconsistent 5.16 version information. The Linux stable release announcement and Red Hat’s later kernel tracking both support 5.16.15 as the stable branch fix. (bugzilla.redhat.com)

This is why production remediation should follow this hierarchy:

1. Distribution vendor security advisory
2. Exact patched package / kernel build
3. Upstream stable commit history
4. Generic version database

Generic CVE databases are excellent discovery tools.

They should not replace vendor-specific package intelligence.

The Upstream Fix Commit

The specific upstream patch commonly associated with the erroneous filter limit is:

c993ee0f9f81caf5767a50d1faeba39a0dc82af2

with the subject:

watch_queue: Fix filter limit check

Its patch description states that the second סוג test was using the wrong calculation and could lead to the two out-of-bounds writes described earlier. (git.zx2c4.com)

Some CVE databases also reference:

93ce93587d36493f2f86921fa79921b3cba63fbb

in connection with the broader upstream watch_queue fixes. Red Hat’s original CVE tracker and the NVD continue to reference that commit for CVE-2022-0995. (NVD)

For vulnerability management, checking the vendor’s patched package is safer than trying to infer remediation from a single git hash alone because distribution maintainers frequently backport commits.

תיקון

The preferred remediation for CVE-2022-0995 is simple:

install the security-maintained kernel provided by your Linux distribution and reboot into it.

For Ubuntu:

sudo apt update
sudo apt full-upgrade
sudo reboot

For Fedora/RHEL-family distributions, the equivalent workflow typically involves:

sudo dnf upgrade
sudo reboot

or the vendor-specific supported update mechanism.

After reboot:

uname -r

and verify that the running kernel corresponds to the fixed package identified by the vendor.

Ubuntu security notices explicitly state that kernel updates require a reboot before all fixes become active. (Ubuntu)

What If You Cannot Patch Immediately?

A kernel privilege escalation vulnerability with known exploitation should not be treated as something that can safely remain unresolved indefinitely.

But operational constraints sometimes prevent an immediate reboot.

Temporary risk-reduction options include restricting:

• interactive shell access;
• untrusted local users;
• arbitrary workload execution;
• shared development environments;
• container execution by untrusted tenants.

If operationally feasible, organizations using custom kernels can also evaluate whether they require:

CONFIG_WATCH_QUEUE

at all.

Running a kernel without the vulnerable subsystem can remove the relevant attack surface, although replacing or rebuilding a production kernel is rarely a simpler remediation than deploying the vendor’s patched kernel.

Do not rely on kernel hardening as a substitute for patching.

KASLR, SMEP, SMAP, SLUB hardening and related mechanisms can raise exploit difficulty but do not remove the underlying memory corruption.

Why Local Vulnerabilities Should Not Be Automatically Deprioritized

Security programs often rank vulnerabilities primarily by whether they are internet-facing.

That approach is useful for initial access but incomplete for attack chains.

Consider two systems:

System A:
Remote RCE
No privilege escalation

System B:
Remote application bug
+
Reliable kernel LPE

System B may provide a substantially more valuable path to an attacker.

Real compromise frequently consists of composable primitives:

initial access
       ↓
execution
       ↓
privilege escalation
       ↓
credential access
       ↓
persistence
       ↓
lateral movement

CVE-2022-0995 occupies the privilege-escalation step.

CISA’s 2026 decision to place the vulnerability in KEV is therefore particularly useful evidence against the assumption that old local Linux bugs can automatically be assigned low remediation priority.

Lessons for Kernel Developers

The root cause also offers a useful secure-coding lesson.

The vulnerable code performed bounds checks based on the storage representation:

sizeof(bitmap) × something

The fixed code checks against the semantic boundary:

WATCH_TYPE__NR

Security validation should generally operate on the domain of valid values rather than infer validity from storage size whenever possible.

במילים אחרות:

Bad question:
"Will this value physically fit somewhere?"

Better question:
"Is this value one of the values the program supports?"

The two may appear equivalent during initial implementation.

They frequently diverge as code evolves.

Lessons for Vulnerability Management Teams

CVE-2022-0995 also demonstrates why vulnerability programs need more than a CVSS score.

In 2022:

CVSS 7.8
Local
Public PoC
Patch available

In 2026:

CVSS 7.8
Local
Public exploit
Patch available
CISA KEV
Observed exploitation

The CVSS score did not change.

The operational risk did.

This is why mature remediation systems incorporate factors such as:

• KEV status;
• exploitation intelligence;
• exploit maturity;
• asset exposure;
• privilege model;
• business criticality;
• compensating controls.

Static severity alone cannot capture threat evolution.

Frequently Asked Questions

What is CVE-2022-0995?

CVE-2022-0995 is an out-of-bounds write vulnerability in the Linux kernel watch_queue event notification subsystem.

An incorrect bounds check inside watch_queue_set_filter() can allow a low-privileged local process to corrupt kernel heap memory.

Successful exploitation may lead to root privilege escalation or a kernel crash. (Ubuntu)

Is CVE-2022-0995 remotely exploitable?

Not directly according to its standard vulnerability classification.

Its CVSS attack vector is:

AV:L

meaning Local.

An attacker generally requires an existing ability to execute code on the target host.

However, CVE-2022-0995 can be chained after another vulnerability that provides initial remote access.

Can an unprivileged Linux user trigger CVE-2022-0995?

Yes.

Red Hat’s original tracking states that the out-of-bounds writes can be triggered by a user and could potentially be used to gain privileged access or panic the system. The current CVSS vector requires only low privileges. (bugzilla.redhat.com)

Does CVE-2022-0995 provide root access?

The memory corruption provides a primitive that can be converted into local privilege escalation under appropriate conditions.

Public privilege-escalation implementations have existed since 2022, including code targeting Ubuntu 21.10 with kernel 5.13.0-37. (GitHub)

Exploit reliability depends on the target kernel and environment.

Is CVE-2022-0995 being actively exploited?

CISA added CVE-2022-0995 to its Known Exploited Vulnerabilities Catalog on August 26, 2026. CISA said the vulnerabilities in that update were added based on evidence of active exploitation. (CISA)

That makes CVE-2022-0995 a priority vulnerability as of August 2026.

What is the CISA remediation deadline?

The KEV record specifies:

September 9, 2026. (netvigilance.com)

This deadline directly applies to affected U.S. federal civilian agencies under the relevant CISA directive, but KEV deadlines are also frequently used by private organizations as remediation benchmarks.

Does Linux 5.15 contain CVE-2022-0995?

Early Linux 5.15 kernels can contain the vulnerable code.

The upstream stable fix appears in:

Linux 5.15.29

and later stable releases. (bugzilla.redhat.com)

Distribution kernels may backport the fix, so always consult the vendor’s package advisory.

What about Linux 5.10?

The corresponding upstream stable fix appears in:

Linux 5.10.106

and later 5.10 stable kernels. (bugzilla.redhat.com)

Again, distro backports can change the exact package-level boundary.

What about Linux 5.16?

The stable fix is associated with:

Linux 5.16.15

The official 5.16.15 release changelog includes watch_queue: Fix filter limit check. (lore.gnuweeb.org)

How can I check whether watch_queue is enabled?

Try:

grep CONFIG_WATCH_QUEUE /boot/config-$(uname -r)

or, when kernel configuration is exposed through procfs:

zgrep CONFIG_WATCH_QUEUE /proc/config.gz

The relevant Linux kernel structures and implementation are conditional on CONFIG_WATCH_QUEUE. (codebrowser.dev)

Does patching require a reboot?

Normally yes.

Updating a kernel package does not replace the kernel currently executing in memory.

Canonical explicitly instructs users to reboot after relevant kernel security updates. (Ubuntu)

Are containers vulnerable?

Containers share their host’s Linux kernel.

Therefore the relevant question is whether the host kernel contains the vulnerable watch_queue implementation and whether container restrictions permit an attacker to reach the necessary kernel functionality.

Updating packages inside an application container does not patch the host kernel.

Is CVE-2022-48847 the same vulnerability?

CVE-2022-48847 is a later Linux CNA record describing the same watch_queue: Fix filter limit check upstream defect and references the same vulnerable implementation and fixed stable releases. (OpenCVE)

Security teams may therefore encounter CVE-2022-0995 and CVE-2022-48847 when different vulnerability databases normalize the underlying kernel issue.

Why is a 2022 CVE suddenly relevant again in 2026?

Because exploitation status changed.

CVE-2022-0995 has had public technical details and exploit material for years, but CISA added it to KEV on August 26, 2026 based on evidence of active exploitation. (CISA)

Old vulnerabilities frequently return to operational relevance when attackers discover that substantial numbers of systems remain unpatched.

Final Assessment

CVE-2022-0995 is an unusually clear example of how a tiny kernel programming mistake can create an outsized security consequence.

The vulnerable watch_queue_set_filter() implementation performed two checks intended to validate essentially the same attacker-controlled notification type.

One used the correct bit calculation.

The other multiplied a byte count by BITS_PER_LONG, allowing values far beyond the intended bitmap range. The result was not merely malformed filtering behavior but two kernel out-of-bounds write conditions: one involving the type_filter bitmap and another involving entries beyond the allocated filters[] array. (patchew.org)

Because those writes occur in kernel heap memory, attackers can potentially transform the corruption into a local privilege-escalation primitive.

The vulnerability was fixed years ago. Upstream stable fixes were delivered for the major affected branches, including Linux 5.10.106, 5.15.29 and 5.16.15, with the fix incorporated into mainline Linux 5.17. (bugzilla.redhat.com)

Yet the story did not end in 2022.

On August 26, 2026, CISA placed CVE-2022-0995 in the Known Exploited Vulnerabilities Catalog based on evidence of active exploitation. (CISA)

For defenders, the practical response is therefore straightforward:

Inventory old Linux kernels
        ↓
Check CONFIG_WATCH_QUEUE
        ↓
Consult distro-specific CVE status
        ↓
Install the patched kernel
        ↓
Reboot
        ↓
Verify the running kernel
        ↓
Investigate suspicious local-to-root transitions

CVE-2022-0995 should not be viewed simply as a four-year-old kernel bug.

As of August 2026, it is an example of something security teams repeatedly encounter in real infrastructure: a long-patched vulnerability that becomes strategically important again because attackers discover that vulnerable systems are still available to exploit.