CVE-2026-53130

What it actually does

This is a Linux kernel memory corruption flaw in the OMFS filesystem parser. When mounting a crafted OMFS filesystem image, the kernel validates that the filesystem block size is not larger than PAGE_SIZE but fails to reject block sizes smaller than OMFS_DIR_START, which is 440 bytes. Later code subtracts OMFS_DIR_START from the attacker-controlled 32-bit block-size value and passes the result to memset(). If the block size is less than 440, the subtraction underflows and becomes a very large length, causing the kernel to overwrite memory far beyond the intended buffer. The most likely outcome is a kernel crash and denial of service; depending on kernel configuration, heap layout, and attacker control over adjacent memory, the bug may also be a building block for local privilege escalation or kernel code execution.

Why it matters to the business

Systems that allow untrusted users, removable media, disk images, VM images, container workflows, or automated services to trigger mounting or inspection of OMFS filesystem images could be crashed by a malformed image. The operational impact is primarily service disruption, host instability, and potential loss of availability. Because exploitation generally requires the vulnerable kernel to parse a crafted filesystem image, internet-scale remote exploitation is unlikely, which is consistent with the low EPSS score and absence from the CISA KEV catalog. However, exposure can still be meaningful on workstations, forensic sandboxes, file-processing services, virtualization hosts, and environments that automatically probe uploaded or attached disk images.

How an attack unfolds

An attacker prepares a malformed OMFS filesystem image whose superblock declares an s_sys_blocksize value smaller than OMFS_DIR_START. The attacker then needs to cause a vulnerable Linux kernel to mount or otherwise process that image through the OMFS filesystem driver. In many default server configurations this requires local privileges such as CAP_SYS_ADMIN, but the risk increases where desktop automounting, removable media handling, disk-image analysis, backup tooling, virtualization pipelines, or privileged helper services automatically mount or probe untrusted images. During mount and filesystem initialization, the kernel accepts the invalid small block size. When OMFS directory initialization code later calculates s_sys_blocksize - OMFS_DIR_START, the unsigned arithmetic underflows to a near-4 GiB value. The resulting memset() writes beyond the allocated block buffer into unrelated kernel memory, usually causing an immediate kernel oops, panic, reboot, or hang. With advanced exploitation work, the memory overwrite could potentially be shaped into a privilege-escalation primitive, but no public exploit maturity or known in-the-wild exploitation is indicated by the provided data.

How to fix it

Update the Linux kernel to a version that includes the OMFS fix adding a lower-bound validation check for s_sys_blocksize in omfs_fill_super(). If vendor-fixed package versions are available from the operating system or appliance vendor, apply those updates and reboot into the fixed kernel. Where immediate patching is not possible, reduce exposure by preventing untrusted users and services from mounting filesystems, disabling or restricting automount behavior for removable media and disk images, blocking OMFS filesystem support if it is not required, and ensuring image-analysis or sandboxing workflows process untrusted filesystem images in isolated, disposable environments. If OMFS is built as a loadable module and not needed, consider preventing the module from loading through standard module denylisting controls. If OMFS support is built directly into the kernel, mitigation requires kernel replacement or removing pathways that process untrusted images.

How to confirm the fix worked

Confirm remediation by verifying the running kernel is a vendor build that contains the OMFS lower-bound s_sys_blocksize validation fix, not merely that an updated package is installed. After patching, reboot and check the active kernel version. If source or build metadata is available, confirm that omfs_fill_super() rejects s_sys_blocksize values smaller than OMFS_DIR_START as well as values larger than PAGE_SIZE. Validate exposure reduction by checking whether OMFS support is present, whether the omfs module can be loaded, and whether non-administrative users or automated services can trigger filesystem mounts or disk-image probing. In controlled test environments only, a malformed OMFS image with a block size below 440 should be rejected cleanly rather than causing a kernel oops, panic, or hang.

Typical attack path

1. Create a crafted OMFS filesystem image with s_sys_blocksize set below 440 bytes.
2. Deliver the image through a path where the target system may mount, probe, or inspect it, such as removable media, an uploaded disk image, a VM image, an archive, or a forensic-analysis workflow.
3. Cause the vulnerable Linux kernel to invoke the OMFS filesystem driver against the crafted image.
4. The kernel accepts the malformed superblock because the lower-bound block-size check is missing.
5. OMFS directory initialization performs unsigned subtraction on the invalid block size, producing a very large memset() length.
6. The kernel overwrites memory outside the target buffer, resulting in a crash or potentially exploitable kernel memory corruption.

How to detect it

Look for evidence that the system mounted or attempted to mount OMFS filesystem images shortly before a kernel crash, oops, panic, reboot, or hang. Useful sources include kernel logs, system journal entries, syslog, auditd records for mount activity, endpoint telemetry showing mount or losetup commands, removable-media events, virtualization or image-processing service logs, and crash dump artifacts such as kdump or vmcore files. Search for OMFS-related kernel messages and correlate them with abnormal resets, watchdog timeouts, general protection faults, page faults, slab corruption, or memset-related crash traces. Also review user and process activity for mounting untrusted images, use of loop devices, file-identification tools, backup/restore tooling, forensic tooling, or automount services immediately before instability. Because exploitation may leave no durable file artifact after a crash, detection is mainly behavioral and timeline-based. The supplied intelligence does not indicate known public exploitation, named threat actors, ransomware use, or KEV status, so prioritize local crash correlation over network IOC hunting.

• omfs
• OMFS
• mount -t omfs
• type=omfs
• /sbin/mount.omfs
• modprobe omfs
• insmod omfs
• losetup
• /dev/loop
• loop-control
• kernel: omfs
• BUG: kernel NULL pointer dereference
• kernel panic
• Kernel panic
• Oops:
• general protection fault
• unable to handle kernel paging request
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• Out of memory and no killable processes
• memset
• omfs_fill_super
• omfs_make_empty

What your security team should do

• Prioritize kernel updates for systems that process removable media, uploaded disk images, VM images, backups, forensic evidence, or other untrusted filesystem content.
• Reboot systems after applying the fixed kernel and verify the running kernel, not just the installed package inventory.
• If OMFS is not required, disable or denylist OMFS filesystem support where feasible.
• Restrict mount privileges and audit any services that mount, probe, or auto-detect filesystems on behalf of users.
• Disable automounting of untrusted removable media and disk images on workstations, kiosks, analysis hosts, and shared systems where practical.
• Run untrusted filesystem-image analysis in isolated virtual machines or disposable sandboxes with limited blast radius.
• Monitor for kernel oops, panic, BUG, general-protection-fault, or watchdog events involving OMFS or filesystem mounting.
• Treat unexpected crashes following attachment or processing of disk images as potentially malicious, even though the vulnerability is not currently listed as KEV and has low EPSS.
• Preserve kernel logs, system journals, audit logs, and the triggering image or media when investigating suspected exploitation.