CVE-2026-52992

What it actually does

This is a Linux kernel memory-corruption flaw in the ADFS filesystem parser. A crafted new-format ADFS disk image can set the zone count to zero; during filesystem probing or mounting, the kernel allocates a zero-sized map structure and then writes before the returned pointer, causing an out-of-bounds kernel memory write. Depending on kernel configuration and memory layout, exploitation may result in kernel crash, denial of service, or potentially local privilege escalation, though no public exploit maturity is currently reported.

Why it matters to the business

Systems that allow users, automation, or services to attach or mount untrusted filesystem images could be crashed or potentially compromised at the kernel level. The practical risk is highest on workstations, build systems, forensic-analysis hosts, file-ingestion pipelines, virtualization hosts, and any environment where disk images are processed automatically. Current exploitation signals are low: EPSS is 0.00139, the issue is not listed in CISA KEV, is not associated with ransomware use, and no mature exploit is reported; however, kernel memory-corruption flaws should still be prioritized where untrusted media or disk images are handled.

How an attack unfolds

An attacker creates a malformed ADFS filesystem image whose boot block represents a new-format disk record with nzones set to zero. The attacker then needs the target system to cause the Linux kernel to parse that image, commonly by mounting it directly, mounting it through a loop device, attaching removable media, or processing the image through software that invokes kernel filesystem probing. When the vulnerable ADFS code validates the boot block insufficiently, the zero zone count reaches the map-reading logic. The allocation routine returns a zero-size allocation sentinel, but later layout code writes to an index before the expected map buffer. That corrupts kernel memory and can trigger a kernel oops, panic, or possibly be shaped into more serious kernel-level code execution under favorable conditions.

How to fix it

Update the Linux kernel to a version that includes the ADFS fix validating and rejecting zero-zone new-format ADFS disk records in adfs_validate_bblk(). No exact fixed package versions were provided in the input, so use the kernel advisory or distribution security advisory for the affected kernel branch and install the vendor-provided fixed kernel package. Reboot into the fixed kernel after installation. As interim mitigations, prevent untrusted users and services from mounting filesystem images, disable or restrict automounting of removable media and disk images, avoid processing untrusted ADFS images on vulnerable systems, use isolated sandboxes or disposable VMs for forensic/image analysis, and restrict CAP_SYS_ADMIN or equivalent mount privileges. If ADFS support is built as a module and not required, prevent loading the adfs module using module blacklist policy; if built into the kernel, prefer patching or using a kernel build without ADFS support where feasible.

How to confirm the fix worked

Confirm the running kernel is the updated vendor-fixed build, not only that the package is installed. Verify with uname -r and distribution package metadata after reboot. If the ADFS filesystem is modular, check whether the adfs module is loaded using lsmod and whether module-blocking policy is active if ADFS is not needed. Review /proc/filesystems for adfs support where relevant. In controlled test environments only, a crafted regression image with nzones set to zero should be rejected during probe or mount without a kernel oops, panic, KASAN report, or slab corruption warning. Validate that automount policies, image-processing services, and user permissions do not allow untrusted disk images to be mounted on systems that have not yet been patched.

Typical attack path

1. Prepare a crafted ADFS filesystem image with a new-format disk record and nzones set to 0.
2. Deliver the image through removable media, a downloaded archive, a virtual disk, an email attachment, a file-sharing workflow, or another disk-image ingestion path.
3. Cause the target Linux system to probe or mount the image, often via mount, losetup, file-manager automounting, forensic tooling, virtualization tooling, or automated image processing.
4. The vulnerable kernel ADFS parser accepts the malformed boot block and proceeds into map-reading logic.
5. The kernel performs an out-of-bounds write before the allocated map buffer, corrupting kernel memory.
6. The system may crash immediately, log a kernel oops/panic, or, in a more advanced scenario, allow further exploitation of kernel memory corruption.

How to detect it

Look for evidence that vulnerable systems parsed or mounted ADFS filesystem images before patching. Useful sources include kernel logs, systemd journal, auditd logs, shell history, EDR telemetry, removable-media events, file-ingestion service logs, virtualization/forensic tooling logs, and records of losetup or mount activity. Search for ADFS filesystem mounts, loop-device setup involving unknown images, automount events for removable media, and kernel instability shortly afterward. Signs of attempted or successful triggering include kernel oops or panic messages referencing ADFS functions, KASAN or slab out-of-bounds reports involving fs/adfs code, unexpected reboots after disk-image handling, or crashes following mount attempts using type adfs. There are no known public threat actors or ransomware campaigns associated with this issue from the supplied intelligence, so detection should focus on local artifact and crash forensics rather than known campaign infrastructure.

• type adfs
• -t adfs
• mount.adfs
• /proc/filesystems: adfs
• adfs_map_layout
• adfs_read_map
• adfs_validate_bblk
• fs/adfs
• ADFS-fs
• kernel BUG
• BUG: KASAN
• out-of-bounds
• slab-out-of-bounds
• general protection fault
• kernel panic
• Oops:
• losetup
• /dev/loop

What your security team should do

• Inventory Linux systems that mount removable media, loopback disk images, virtual disks, forensic images, or user-supplied archives, and prioritize those for kernel updates.
• Apply vendor-fixed kernel updates and reboot into the fixed kernel; track completion by running kernel version, not installed package version alone.
• Where ADFS is not operationally required, disable loading of the adfs filesystem module or use kernels built without ADFS support.
• Restrict mount and loop-device operations to trusted administrators and controlled services; review CAP_SYS_ADMIN exposure in containers and service accounts.
• Disable desktop or server automounting for untrusted removable media and disk images until patched.
• Process untrusted disk images only in isolated, disposable analysis environments with patched kernels.
• Monitor kernel logs for ADFS-related oops, panic, KASAN, slab, or memory-corruption messages, especially after handling disk images or removable media.
• Because this issue is not KEV-listed, not known ransomware-used, and has low EPSS, treat it as lower external urgency than actively exploited internet-facing flaws, but still prioritize it on systems exposed to untrusted local files or media.