CVE-2026-31670

What it actually does

This is a local denial-of-service flaw in the Linux kernel rfkill subsystem. A low-privileged local user can open an rfkill file descriptor and trigger creation of rfkill events without consuming them. On vulnerable kernels, pending rfkill events are not sufficiently bounded, allowing memory consumption to grow until the system experiences memory pressure or an out-of-memory condition. The impact is availability loss only; it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

An attacker with local access to an affected Linux system can degrade performance or crash the host by exhausting memory, potentially interrupting workloads, user sessions, or services running on that machine. The risk is highest on shared Linux servers, desktops, jump hosts, CI runners, lab systems, or multi-user environments where untrusted users can execute local code. EPSS is very low and there is no known CISA KEV listing or ransomware association, so this should be prioritized as a defense-in-depth and stability fix rather than an internet-scale emergency.

How an attack unfolds

An attacker first needs the ability to run code locally as an unprivileged user on an affected Linux system. They interact with the rfkill interface, typically through the rfkill character device, and cause rfkill events to accumulate while intentionally not reading them from the associated file descriptor. Because vulnerable kernels do not adequately cap pending rfkill events, repeated event generation can consume kernel memory. If sustained, this can trigger system-wide memory pressure, the OOM killer, service failures, severe slowdown, or a host crash. The upstream fix limits the number of queued rfkill events to a large bounded value, preventing unbounded memory growth from this abuse pattern.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the rfkill event queue bounding fix for this issue. Because no specific fixed package versions were provided, use the relevant Linux distribution or appliance vendor advisory to identify the corrected kernel package for each platform. Where immediate patching is not possible, reduce exposure by restricting local shell access, removing unnecessary users, limiting access to rfkill interfaces where operationally feasible, disabling unused wireless/rfkill-related functionality on systems that do not require it, and applying resource controls for untrusted workloads. Containers should not be relied on as a complete mitigation if they expose host devices or capabilities that allow interaction with rfkill.

How to confirm the fix worked

Confirm that installed kernel packages match vendor-fixed versions or contain the upstream change that bounds pending rfkill events. Validate with package management tools such as rpm, dpkg, apt, yum, dnf, zypper, or the distribution’s vulnerability scanner, and verify the running kernel with uname -a after reboot. Check whether /dev/rfkill exists and whether untrusted users or workloads can access it. On patched systems, attempts to accumulate excessive pending rfkill events should be bounded and should not produce unbounded memory growth. Review vendor advisories and kernel changelogs for references to limiting pending rfkill events or preventing unlimited rfkill event creation.

Typical attack path

1. Obtain local shell or code execution as a low-privileged user on an affected Linux host.
2. Open or otherwise interact with the rfkill userspace interface, such as /dev/rfkill, where accessible.
3. Generate large numbers of rfkill events while not consuming pending events from the rfkill file descriptor.
4. Continue the activity until kernel memory pressure increases and the host becomes unstable.
5. Cause service degradation, process termination by the OOM killer, or host denial of service.

How to detect it

Look for evidence of local memory-exhaustion activity and rfkill interaction. Useful sources include kernel logs, system journals, auditd logs, endpoint telemetry, process accounting, and EDR records. Search for OOM killer messages, repeated memory allocation failures, abnormal growth in kernel memory pressure, and repeated access to /dev/rfkill by the same user or process. On systems with auditd, review SYSCALL or PATH records involving /dev/rfkill, especially open/openat activity followed by high memory pressure. Correlate timestamps of rfkill access with system slowdown, process termination, service restarts, kernel OOM logs, or host reboots. Because exploitation does not require a distinctive network indicator and may leave limited artifacts beyond local device access and memory-pressure logs, absence of a clear IOC does not prove absence of exploitation.

• /dev/rfkill
• rfkill
• Out of memory
• oom-killer
• invoked oom-killer
• Killed process
• Memory allocation failure
• page allocation failure
• audit:
• type=PATH
• name="/dev/rfkill"
• openat
• kernel: rfkill

What your security team should do

• Inventory Linux systems and identify hosts running kernels that include the vulnerable rfkill behavior, prioritizing shared-user systems and systems where untrusted code can execute.
• Patch affected kernels through the operating system vendor and reboot into the fixed kernel.
• Restrict local access to systems where patching is delayed, especially access for contractors, students, CI jobs, shared shell users, or untrusted workloads.
• Review permissions and necessity of /dev/rfkill exposure, particularly on servers where wireless/rfkill functionality is not required.
• Monitor for memory exhaustion events, OOM killer activity, and unusual access to rfkill interfaces until patching is complete.
• Do not treat this as a remote-code-execution emergency, but include it in routine kernel patch cycles because it can cause real operational outages on multi-user systems.