CVE-2022-0433: Linux Kernel BPF Subsystem DOS Vulnerability

CVE-2022-0433 Overview

CVE-2022-0433 is a NULL pointer dereference flaw in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. The vulnerability resides in how the kernel handles the map_get_next_key function for BPF bloom filter maps. A local, authenticated user can trigger the flaw to crash the system, producing a kernel panic and denial of service. The issue affects Linux kernel versions prior to 5.17-rc1 and was addressed in upstream commit 3ccdcee28415. The weakness is categorized under [CWE-476] (NULL Pointer Dereference) and [CWE-908] (Use of Uninitialized Resource).

Critical Impact
A local user with permission to interact with BPF maps can crash the kernel, disrupting availability on affected Linux hosts and Fedora 35 systems.

Affected Products

Linux Kernel versions prior to 5.17-rc1
Fedora 35
Distributions shipping affected upstream kernels

Discovery Timeline

2022-03-10 - CVE-2022-0433 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-0433

Vulnerability Analysis

The BPF subsystem in the Linux kernel allows user space to create and manage map data structures used by BPF programs. Linux 5.16 introduced the BPF bloom filter map type, a probabilistic set used for fast membership tests. Map operations such as lookup, update, delete, and get_next_key are exposed through the bpf() syscall and dispatched per map type.

The bloom filter map does not implement an ordered key space and therefore does not support the get_next_key operation. When user space invokes BPF_MAP_GET_NEXT_KEY against a bloom filter map, the kernel dereferences a function pointer that was never populated for this map type. The result is a NULL pointer dereference inside kernel context, producing an oops or kernel panic depending on system configuration.

The issue is local-only and does not yield code execution or information disclosure. Impact is limited to availability. Exploitability requires the ability to invoke the bpf() syscall, which on many distributions is gated by CAP_BPF or CAP_SYS_ADMIN, though unprivileged BPF may be enabled on others.

Root Cause

The root cause is a missing handler check in the bloom filter map operations table. The map_get_next_key callback was left unset, and the generic dispatch path did not validate the function pointer before invoking it. The upstream fix in commit 3ccdcee28415 rejects BPF_MAP_GET_NEXT_KEY requests for bloom filter maps at the syscall layer.

Attack Vector

A local user creates a BPF bloom filter map with bpf(BPF_MAP_CREATE, ...) specifying BPF_MAP_TYPE_BLOOM_FILTER. The attacker then issues bpf(BPF_MAP_GET_NEXT_KEY, ...) against the returned map file descriptor. The kernel dispatches to the unset callback and dereferences NULL, halting the affected CPU and typically crashing the system. See the Linux Kernel Commit Update for the corrective patch.

Detection Methods for CVE-2022-0433

Indicators of Compromise

Kernel oops or panic messages referencing map_get_next_key or bpf_map_get_next_key in dmesg and /var/log/messages
Unexpected host reboots correlated with recent bpf() syscall activity by non-root users
Audit records showing BPF_MAP_CREATE with map type 18 (BPF_MAP_TYPE_BLOOM_FILTER) followed by BPF_MAP_GET_NEXT_KEY from the same process

Detection Strategies

Enable Linux audit rules on the bpf syscall (-a always,exit -F arch=b64 -S bpf -k bpf_calls) and alert on bloom filter map creation by unprivileged users
Monitor kernel ring buffer output for NULL pointer dereference traces originating in kernel/bpf/syscall.c
Inventory running kernel versions against the 5.17-rc1 fix boundary to identify exposed hosts

Monitoring Recommendations

Forward auditd, journald, and kmsg streams to a centralized analytics platform for correlation across hosts
Track processes that hold CAP_BPF or CAP_SYS_ADMIN and baseline normal BPF usage to flag anomalies
Alert on repeated host crashes within a short window, which can indicate exploitation attempts against availability

How to Mitigate CVE-2022-0433

Immediate Actions Required

Upgrade affected systems to a Linux kernel that includes commit 3ccdcee28415 or to a vendor build that backports the fix
Apply the Fedora 35 kernel update referenced in Red Hat Bug Report #2048259
Restrict the bpf() syscall to privileged users by setting kernel.unprivileged_bpf_disabled=1 until patching is complete

Patch Information

The upstream fix landed in Linux 5.17-rc1 via commit 3ccdcee28415c4226de05438b4d89eb5514edf73, which rejects get_next_key calls against bloom filter maps. Distribution maintainers backported the change to supported stable trees. Refer to the Linux Kernel Commit Update and the BPF Mailing List Discussion for technical context.

Workarounds

Disable unprivileged BPF by setting kernel.unprivileged_bpf_disabled=1 via sysctl and persisting in /etc/sysctl.d/
Limit CAP_BPF and CAP_SYS_ADMIN to trusted service accounts and remove these capabilities from container workloads where possible
Use seccomp or Linux Security Module policies to block the bpf() syscall for processes that do not require it

bash

# Configuration example
# Disable unprivileged BPF usage until kernels are patched
echo 'kernel.unprivileged_bpf_disabled=1' | sudo tee /etc/sysctl.d/90-bpf-hardening.conf
sudo sysctl --system

# Verify the setting is active
sysctl kernel.unprivileged_bpf_disabled

# Confirm running kernel version against the 5.17-rc1 fix boundary
uname -r