CVE-2026-89602

What it actually does

A logic bug in the Linux kernel EROFS global decompression-buffer resize path can overflow a kernel heap pointer array. z_erofs_gbuf_nrpages is advanced only after every global buffer has grown; if a resize fails after some buffers were already enlarged, a retry revisits those buffers. Retrying the same size is mis-treated as -ENOMEM because alloc_pages_bulk() has nothing to add. Retrying an intermediate size allocates a temporary page-pointer array smaller than gbuf->nrpages and copies more existing pointers than the array can hold, corrupting adjacent kernel heap. The result is kernel memory corruption with high impact on confidentiality, integrity, and availability (panic, information leak, or local privilege escalation).

Why it matters to the business

Any Linux system that mounts or reads EROFS volumes—including Android devices, embedded and IoT Linux, and some container or cloud images—can kernel-panic or, in a worst case, allow a local attacker to take control of the machine. The issue has been public for about 36 days, is not on the CISA KEV list, has no reported ransomware use, and has no known public exploit, but the CVSS 7.8 kernel-memory-corruption rating still warrants prompt patching wherever EROFS is in use.

How an attack unfolds

An attacker with local access, and some user interaction such as mounting or opening content on an EROFS filesystem, causes global decompression buffers to grow. If memory pressure produces a partial grow followed by a retry at a smaller size, the kernel allocates an undersized temporary pointer array and copies existing page pointers past its end. The resulting heap overflow can crash the kernel or, depending on allocator layout, be abused to overwrite nearby kernel objects and escalate privileges. No named threat actors or in-the-wild campaigns are associated with this CVE, and exploit maturity is none.

How to fix it

Install a vendor or distro kernel update that includes the EROFS fix described as “erofs: skip sufficiently large global buffers when resizing” (skip buffers that already meet the requested size; advance z_erofs_gbuf_nrpages only once the whole pool has caught up). Reboot into the patched kernel. If a patch is not yet available, avoid mounting untrusted EROFS images, restrict who can mount filesystems, and disable EROFS where it is not required (kernel config or module blacklist). No per-package fixed versions were supplied with this record; follow your kernel vendor’s advisory.

How to confirm the fix worked

Confirm the running kernel changelog or git history contains the EROFS gbuf-resize fix; verify uname -r matches a patched build. Check that EROFS is present (CONFIG_EROFS_FS / erofs module, /proc/filesystems). After patching, mount a known-good EROFS volume and read compressed files to confirm decompression still works. On unpatched hosts, treat any EROFS-capable kernel as exposed until upgraded.

Typical attack path

1. Obtain local access or induce a user to mount or open an EROFS image or volume
2. Trigger EROFS compressed-file I/O that requires growing the global decompression buffer pool
3. Cause a partial buffer grow to succeed and then fail (for example under memory pressure)
4. Force a retry at an intermediate size so an undersized page-pointer array is allocated and overflowed
5. Leverage the resulting kernel heap corruption for denial of service or, if conditions allow, privilege escalation

How to detect it

There are no public exploits or named campaigns, so look for post-crash forensics rather than a unique implant. Review kernel logs (dmesg, journalctl -k, pstore/console-ramoops, crash dumps) around EROFS I/O for Oops/BUG, KASAN/slab-out-of-bounds, or general protection faults with EROFS decompression or gbuf resize on the stack. Correlate with recent mounts of EROFS images, compressed-file reads, and memory-pressure events. Persistent compromise after a successful overflow would look like generic kernel-level persistence, not a CVE-specific artifact.

• Oops or BUG call trace containing z_erofs
• Oops or BUG call trace containing erofs_gbuf
• kernel log: slab-out-of-bounds or KASAN with erofs on the stack
• kernel log: Unable to handle kernel paging request with erofs in the backtrace
• dmesg/journal: erofs: combined with BUG: or general protection fault
• process or mount activity involving type erofs immediately before a kernel panic

What your security team should do

• Prioritize kernel updates on Android, embedded, and any fleet that mounts EROFS, then reboot
• Inventory EROFS usage (modules, fstab, container/base images) and disable it where unused
• Block or tightly control mounting of untrusted EROFS images until patches are in place
• Watch kernel logs for EROFS-related oops/panic even though no in-the-wild exploitation is reported
• Track distro advisories for the exact stable-kernel backport; this CVE is not in KEV and has no public exploit, so patch on the normal emergency kernel cadence rather than a CISA-driven deadline