Cloudanix VulnDB

CVE-2026-80892

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in handling certain compressed file systems can make computers with many processors use far more memory than expected, potentially slowing them down or causing crashes.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

EROFS LZMA decompressor sizes its global stream pool from num_possible_cpus() and preallocates up to 8 MiB of vmalloc-backed dictionary state per stream, allowing a mounted image to retain hundreds of MiB until module unload.

Why it matters to the business

High-CPU systems may experience rapid memory exhaustion and degraded stability when any LZMA-compressed EROFS image is mounted, increasing operational risk and potential downtime on servers or appliances twenty-five days after the fix was published.

How an attack unfolds

An attacker supplies or tricks the system into mounting an EROFS filesystem image that uses LZMA compression; the kernel allocates one large dictionary per CPU-derived stream with no upper bound, pinning vmalloc memory that remains allocated for the life of the module.

How to fix it

Apply the upstream kernel commit that introduces CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS (default 16) and rebuild; alternatively set the lzma_streams module parameter explicitly before loading erofs.

How to confirm the fix worked

Confirm the new configuration option exists and defaults to 16 streams, verify that mounting a test LZMA EROFS image no longer exceeds 128 MiB of vmalloc memory on systems with 16 or more CPUs, and check module load parameters.

Typical attack path

  1. Identify or create an EROFS image using LZMA compression
  2. Cause the target to mount the image (via auto-mount, user action, or supply-chain vector)
  3. Kernel initializes lzma_streams pool sized from num_possible_cpus()
  4. Each stream preallocates an 8 MiB dictionary, exhausting vmalloc memory

How to detect it

Review kernel logs and vmstat / proc/meminfo for sudden spikes in vmalloc usage immediately after an EROFS mount; correlate with erofs module load events and any user or service activity that mounts external filesystems.

What your security team should do

  • Prioritize kernel updates on high-CPU systems that may mount EROFS images
  • Audit workloads for use of LZMA-compressed EROFS filesystems
  • Consider setting lzma_streams explicitly where pool sizing must remain large
  • Monitor vmalloc usage after EROFS mounts until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: erofs: cap LZMA stream pool size fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream pool from num_possible_cpus() when the lzma_streams module parameter is unset, then z_erofs_load_lzma_config() preallocates one image-supplied dictionary per stream, accepting dictionaries up to 8 MiB. On high-CPU systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed decoder state until the erofs module is unloaded. Impact: An EROFS image mounted by the system can pin up to 8 MiB of vmalloc memory per LZMA stream, either as intended or unexpectedly. Bound the default stream count by a new CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the worst-case default preallocation is 128 MiB if the number of CPUs is no less than 16 while preserving the existing per-image dictionary limit. An explicit lzma_streams module parameter is still honoured as-is, so administrators who deliberately size the pool are not affected.

Affected packages

Ecosystem Package Introduced Fixed