CVE-2026-89604

What it actually does

The Linux kernel efivarfs statfs() path invoked the EFI QueryVariableInfo() runtime service on every call, with no throttling. Unprivileged local users can exercise that path on the efivarfs mount. On x86 systems whose variable store is backed by System Management Mode, each call enters SMM and rendezvouses all CPUs, producing host-wide stalls and throughput collapse (local denial of service). Confidentiality and integrity of EFI variables are not affected. The fix rate-limits QueryVariableInfo() to twice per second and returns the most recently obtained values for elided calls.

Why it matters to the business

Shared Linux servers, developer workstations, CI runners, and guests that expose efivarfs can suffer unexplained slowdowns or apparent hangs caused by any untrusted local process, including in multi-tenant and container environments. Impact is availability and performance only. The issue is not in CISA KEV, is not associated with ransomware, and has no reported exploit maturity. About 36 days have elapsed since publication, so this is a standard kernel-hardening item rather than an emergency internet-facing incident: prioritize multi-user x86 hosts with SMM-backed EFI variable storage.

How an attack unfolds

A local, unprivileged attacker (or a confined process that can still see efivarfs) repeatedly requests filesystem statistics on the EFI variable filesystem. Before the rate-limit, each request caused a QueryVariableInfo() firmware call. On SMM-backed x86 platforms that serializes every CPU into SMM, starving normal work until the flooding stops. There is no remote network vector, no authentication bypass, no privilege escalation, and no persistence. No named threat actors or campaigns are associated with this issue. After the kernel change, excess queries are coalesced and served from the last sampled firmware values.

How to fix it

Install a Linux kernel that includes the efivarfs statfs() rate-limit (QueryVariableInfo at most twice per second, cached results otherwise). Use your distribution or OEM kernel package; exact fixed versions were not supplied with this record, so confirm via vendor advisory or kernel changelog. Until patched, reduce exposure: do not mount efivarfs where EFI variable access is unnecessary; keep it out of untrusted users’ and containers’ mount namespaces; restrict access to the firmware EFI sysfs tree with mount namespaces, LSM policy, or filesystem permissions. These mitigations do not replace the kernel fix on hosts that must expose efivarfs.

How to confirm the fix worked

Confirm the running kernel changelog or vendor advisory cites the efivarfs statfs() QueryVariableInfo rate-limit. Verify efivarfs still answers ordinary statfs/statvfs queries with plausible capacity figures. After update, SMM/SMI rate and system stalls should not scale with rapid filesystem-stat activity on that mount. Review that untrusted users and containers no longer have a live efivarfs mount if it is not required.

Typical attack path

1. Obtain local unprivileged execution on a Linux host (or a container) where efivarfs is mounted and reachable
2. Locate the efivarfs mount, typically in the firmware EFI sysfs hierarchy
3. Issue a high rate of filesystem-stat operations against that mount from user space
4. On x86 SMM-backed EFI variable stores, force repeated QueryVariableInfo SMM entries and all-CPU rendezvous
5. Degrade or stall the host until the activity stops or a rate-limited kernel is deployed

How to detect it

This is local resource exhaustion without a unique implant or network payload, so compromise is inferred from symptoms rather than a signature. Hunt for windows of unexplained system-wide stalls, watchdog timeouts, or elevated SMI/SMM counts that line up with heavy access to the EFI variable filesystem. Review audit or fanotify-style records of unprivileged processes repeatedly operating on that mount; inspect kernel logs around hang intervals; note containers or jobs that bind-mount firmware sysfs. Remote logs and perimeter telemetry will not show this. Lack of those artifacts does not prove it never occurred.

• /sys/firmware/efi/efivars
• efivarfs
• QueryVariableInfo

What your security team should do

• Inventory Linux systems with efivarfs mounted; prioritize multi-tenant and x86 SMM-backed EFI hosts
• Deploy distribution/OEM kernels that include the efivarfs statfs rate-limit; verify via changelog rather than version guesswork
• Hide or unmount efivarfs from untrusted users, containers, and CI jobs that do not need EFI variable access
• Treat as an availability hardening item (not KEV, no ransomware use, no known exploits)—do not delay other internet-facing KEV work for this alone
• Watch for SMM/SMI storms and host-wide stalls correlated with activity on the EFI variable filesystem