CVE-2024-46744

What it actually does

Corrupted symbolic link size read from a Squashfs image causes integer overflow in squashfs_symlink_read_folio, skipping page initialization and resulting in use of uninitialized kernel memory.

Why it matters to the business

Systems mounting untrusted Squashfs images face risk of kernel instability, crashes, or information disclosure, increasing operational downtime and potential data exposure on Linux servers and devices.

How an attack unfolds

An attacker creates a malicious Squashfs filesystem containing a symbolic link with an oversized size value exceeding expected limits; when the victim mounts and accesses the image, squashfs_read_inode assigns the corrupted size, leading to a negative length after overflow and an uninitialized page that can be leveraged for further kernel attacks.

How to fix it

Upgrade the Linux kernel to a version containing commit f82cb7f24032ed023fc67d26ea9bf322d8431a90 or later; rebuild and deploy the updated kernel across all affected systems; avoid mounting Squashfs images from untrusted sources until patched.

How to confirm the fix worked

Verify the running kernel contains commit f82cb7f24032ed023fc67d26ea9bf322d8431a90 by checking git log or kernel version strings; re-run syzkaller or similar fuzzing workloads targeting Squashfs symlink handling to confirm absence of the uninit-value report.

Typical attack path

1. Craft a Squashfs image with a symbolic link whose on-disk size field exceeds the maximum valid value
2. Deliver the image to the target system via download, removable media, or network share
3. Mount the filesystem on the victim Linux kernel
4. Trigger access to the symbolic link to force squashfs_symlink_read_folio execution
5. Exploit the resulting uninitialized memory for denial of service or privilege escalation

How to detect it

Search kernel logs and dmesg output for Squashfs inode or symlink processing errors; inspect system calls involving mount and readlink on Squashfs mounts; correlate with any KMSAN or uninitialized memory warnings in kernel traces.

What your security team should do

• Prioritize kernel updates on all systems that mount Squashfs images from external or untrusted sources
• Implement filesystem mount restrictions or mandatory signing policies for Squashfs images
• Monitor kernel logs for Squashfs-related warnings or KMSAN reports as an interim detection measure
• Review and update incident response playbooks to include Squashfs image analysis