CVE-2026-89490

What it actually does

On 32-bit Linux kernels, OCFS2 rebuilds the readdir cookie in ocfs2_dir_foreach_blk_el() with a bitwise mask derived from an unsigned long block size. That mask is 32-bit and zero-extended, so the high 32 bits of the 64-bit directory position are cleared. When readdir() on a non-inline directory crosses the 4 GiB boundary, the iterator silently rewinds into the first 4 GiB and the re-validation path re-emits already-returned dirents forever, hanging the calling process in kernel directory iteration. 64-bit kernels are unaffected because unsigned long is 64-bit and the mask is computed at full width.

Why it matters to the business

This is a local denial-of-service condition, not remote code execution. Exploitation maturity is none, it is not in CISA KEV, it is not associated with ransomware, and EPSS remains very low and flat (~0.0018). Impact is limited to 32-bit kernels that still run OCFS2 with directories large enough to exceed 4 GiB—an uncommon combination in modern estates. Where those conditions exist (legacy clustered storage, 32-bit appliances, or long-lived OCFS2 volumes), a hung readdir can stall backups, cluster membership tools, file-index jobs, and any application that lists the directory, potentially requiring process kill or node reboot and disrupting shared-disk cluster operations.

How an attack unfolds

An attacker who can cause a 32-bit Linux host to iterate a large non-inline OCFS2 directory—either by creating enough entries that the directory cookie exceeds 4 GiB, or by triggering readdir/getdents on an existing oversized directory they can read—forces the kernel to truncate ctx->pos. Subsequent readdir calls loop over the same early dirents indefinitely. The victim process remains blocked in the OCFS2 extent-list readdir path (ocfs2_dir_foreach_blk_el), consuming a task and, under repeated invocations, tying up CPU, file descriptors, and cluster locks. No privilege escalation or memory corruption is described; success is a hang of directory-listing workloads on 32-bit OCFS2 only. No named threat actors or campaigns are associated with this issue.

How to fix it

Apply the upstream OCFS2 fix that casts the block-size operand to loff_t before building the readdir mask: ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; ship this via your distro or vendor kernel update that includes the ocfs2 readdir position-truncation patch. Prefer running 64-bit kernels, which are not affected. Until patched, avoid growing OCFS2 directories past 4 GiB on 32-bit nodes, do not run unbounded directory walks (find, recursive backups, antivirus crawls) against known huge OCFS2 directories on 32-bit hosts, and migrate remaining 32-bit OCFS2 workloads to 64-bit kernels. No per-package version list was provided; track vendor kernel changelogs for the ocfs2_dir_foreach_blk_el loff_t mask fix.

How to confirm the fix worked

Confirm the running kernel is 64-bit, or that the 32-bit kernel build includes the ocfs2_dir_foreach_blk_el change that uses ~((loff_t)sb->s_blocksize - 1). On remaining 32-bit OCFS2 nodes, identify non-inline directories whose size or cookie can approach 4 GiB and verify that readdir/getdents across that boundary completes and does not rewind. After patching, re-run a full directory listing that previously crossed 4 GiB and confirm it terminates with a stable, monotonically advancing position. Unpatched 32-bit kernels still containing the unsigned-long mask are exposed.

Typical attack path

1. Identify a 32-bit Linux system that mounts OCFS2 (clustered or local).
2. Obtain the ability to read, or to populate, a non-inline OCFS2 directory whose cookie/position can cross 4 GiB.
3. Trigger directory iteration (readdir/getdents via ls, find, backups, file managers, or an application walk) so the position advances past the 4 GiB boundary.
4. Observe the iterator reset: the same dirents are returned repeatedly and the listing never completes.
5. Repeat or leave the hung task in place to stall the process, hold OCFS2 locks, and degrade cluster or backup operations.

How to detect it

This flaw does not drop files, open sockets, or leave classic malware artifacts; look for already-hung directory iteration on 32-bit OCFS2. Review process and kernel stacks for tasks blocked or looping in ocfs2_dir_foreach_blk_el / ocfs2_readdir / iterate_dir while issuing getdents/getdents64 against OCFS2 mounts. On 32-bit nodes, hunt for long-running ls, find, backup, or indexer processes in uninterruptible or running state over OCFS2 paths, repeated identical dirent sequences, and cluster lock contention tied to directory reads. Audit logs showing unbounded readdir after a directory grew past 4 GiB, plus vmcore/sysrq-t stacks naming ocfs2_dir_foreach_blk_el, are the primary post-incident evidence. No APT or ransomware telemetry is associated.

• ocfs2_dir_foreach_blk_el
• ocfs2_readdir
• getdents64
• D ocfs2
• iterate_dir
• ocfs2_dir_foreach

What your security team should do

• Patch 32-bit Linux kernels that include OCFS2 as a priority; 64-bit kernels can be treated as not affected by this specific truncation.
• Inventory hosts still running 32-bit Linux with OCFS2 mounted and flag any directories that may exceed 4 GiB.
• Until patched, restrict recursive listing/backup/scan jobs against large OCFS2 directories on 32-bit nodes and monitor for stuck readdir tasks.
• Do not treat this as an emergency KEV/ransomware item; EPSS is low and no in-the-wild exploitation is reported—schedule with other kernel DoS fixes.
• Prefer migrating remaining 32-bit clustered-storage nodes to 64-bit kernels to eliminate this class of loff_t/unsigned-long mask bugs.