CVE-2026-46094

What it actually does

This is a Linux kernel memory-safety flaw in the ext4 extended-attribute validation path. A malformed ext4 xattr entry can cause the kernel to read 4 bytes starting too close to the end of the valid xattr region, producing an out-of-bounds read. In practical terms, successful triggering may disclose adjacent kernel memory or crash the kernel, resulting in denial of service. The vulnerability is local: an attacker needs some local execution path or the ability to cause the system to process a crafted ext4 filesystem or malformed ext4 metadata.

Why it matters to the business

Because ext4 is widely used across Linux systems, the exposure can be broad in server, workstation, appliance, container-host, and embedded Linux fleets. The risk is highest on systems that allow users, automation, removable media, disk images, or virtual-machine images to introduce or mount ext4 filesystems. Exploitation is not currently known to be in CISA KEV, is not flagged as ransomware-used, and has a low EPSS score, but kernel memory bugs can still cause outages or sensitive memory exposure when reachable by local users or untrusted storage workflows.

How an attack unfolds

An attacker first obtains local access or a path to make the target kernel parse attacker-controlled ext4 metadata, such as through a crafted disk image, removable media, VM image, loopback mount, or other storage-processing workflow. The attacker prepares malformed ext4 extended attributes so that the calculated next xattr entry lands within the final few bytes of the valid xattr region. The vulnerable bounds check incorrectly accepts this position because the pointer is still before the end of the region. On the next iteration, the ext4 xattr parser evaluates whether the entry is the last entry by reading a 32-bit value, which crosses beyond the valid xattr boundary. Depending on memory layout and kernel hardening, this can result in a kernel fault, panic, KASAN report, or unintended disclosure of adjacent kernel memory. There is no public exploit maturity indicated, and exploitation would generally require local privileges or a storage-ingestion path rather than direct remote network access.

How to fix it

Apply the Linux kernel update from the relevant operating-system or appliance vendor that includes the ext4 check_xattrs() bounds-check fix. The corrected logic ensures there is room for a 4-byte read by checking that the next xattr entry plus sizeof(u32) does not exceed the valid xattr region. No exact fixed package versions were provided in the input, so remediation should be tracked through vendor advisories for the running distribution kernel, including enterprise backports. Where immediate patching is not possible, reduce exposure by preventing untrusted users from mounting filesystems, restricting loop-device and removable-media workflows, disabling or tightly controlling automount of external media, limiting user namespaces where they could facilitate filesystem mounting, and treating untrusted ext4 disk images as hostile until scanned or processed in a patched, isolated environment.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the ext4 xattr bounds-check fix. Validate with uname -r and the distribution package manager, then compare against the vendor security advisory or changelog for CVE-2026-46094 or the ext4 check_xattrs() fix. For source-based kernels, verify fs/ext4/xattr.c includes a bounds check equivalent to ensuring (void *)next + sizeof(u32) is not greater than the end of the valid xattr region. After patching, reboot into the updated kernel and confirm the old vulnerable kernel is not still running. Also validate that systems do not permit untrusted ext4 images, loop mounts, removable media, or user-controlled storage artifacts to be mounted by low-privileged users unless isolation controls are in place.

Typical attack path

1. Gain local code execution or access to a workflow that causes the target to mount or inspect ext4 filesystems.
2. Create or supply a malformed ext4 filesystem, disk image, or metadata structure containing crafted extended attributes.
3. Cause the vulnerable Linux kernel to parse the crafted ext4 xattr entries.
4. Trigger the incorrect bounds check so the next xattr pointer is accepted even though a subsequent 4-byte read crosses the valid boundary.
5. Use the resulting out-of-bounds read to crash the kernel or potentially expose adjacent kernel memory, depending on system configuration and exploit reliability.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs and crash artifacts for ext4 xattr-related faults. Useful sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, systemd-journald archives, kernel crash dumps, kdump/vmcore files, KASAN reports, auditd logs for mount and loop-device activity, EDR telemetry for losetup/mount usage, and storage-ingestion service logs. Look for kernel oops, panic, general protection fault, page fault, or KASAN out-of-bounds reports with stack traces containing ext4 xattr functions, especially check_xattrs. Correlate those events with recent mounting of ext4 disk images, removable drives, VM images, forensic images, or loop devices. Because no public exploit indicators or attacker-specific artifacts are provided, detection should focus on behavioral evidence: unexpected local mounts, failed mounts of malformed ext4 media, kernel crashes during ext4 processing, and repeated attempts to process suspicious disk images.

• check_xattrs
• ext4_xattr
• IS_LAST_ENTRY
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• general protection fault
• kernel BUG at fs/ext4/xattr.c
• RIP: check_xattrs
• Call Trace: check_xattrs
• EXT4-fs error
• EXT4-fs warning
• Buffer I/O error on dev loop
• losetup
• mount -t ext4
• /var/crash
• /proc/vmcore
• vmcore
• kdump

What your security team should do

• Prioritize patching Linux systems that mount untrusted or semi-trusted storage, including virtualization hosts, build systems, forensic workstations, file-ingestion services, removable-media processing systems, and developer workstations.
• Inventory Linux kernel versions across the fleet and map them to vendor advisories or backported fixes for the ext4 check_xattrs() issue.
• Restrict local users and services from mounting loopback images, removable media, or arbitrary ext4 filesystems unless explicitly required.
• Review automount, udev, desktop removable-media, container, and VM-image processing workflows for exposure to attacker-supplied ext4 metadata.
• Monitor kernel logs for ext4 xattr parsing crashes, KASAN out-of-bounds reports, general protection faults, and unexpected reboots or panics.
• If suspicious crashes are observed, preserve kernel logs, crash dumps, mounted image artifacts, loop-device history, and audit logs before remediation actions destroy evidence.