CVE-2026-46070

What it actually does

This is a local Linux kernel memory-safety flaw in the md/raid5 journal recovery path. During RAID5 journal metadata processing, the kernel trusts on-disk payload size fields before confirming that each payload fits within the metadata block boundary. A malformed or corrupted RAID5 journal can cause out-of-bounds reads while parsing payload fields or calculating offsets. The likely impacts are kernel memory disclosure and kernel crash or panic during RAID recovery or journal analysis. Exploitation requires local access or another way to supply or modify the affected RAID journal metadata; it is not a remotely exploitable network vulnerability by itself.

Why it matters to the business

Systems using Linux software RAID5 with journaling may be exposed to local denial-of-service risk and possible leakage of sensitive kernel memory if an attacker can modify or introduce malicious RAID metadata. The main operational concern is storage host instability during recovery, rebuild, or array import, which can affect availability of applications depending on that storage. This issue is not currently listed in CISA KEV, has no known mature public exploit based on the provided data, and has low EPSS, so urgency is highest for multi-user Linux systems, storage appliances, virtualization hosts, and environments where untrusted users or media can influence block devices.

How an attack unfolds

An attacker first needs local privileges sufficient to write to a block device, alter RAID journal metadata, attach malicious storage media, or otherwise influence an md/raid5 journal. They craft a journal metadata block where a payload size field claims a length that extends past the valid metadata block boundary. When the affected kernel later assembles, imports, recovers, or verifies the RAID5 journal, the vulnerable recovery routines iterate over the malformed payloads and access memory outside the expected page-sized metadata area. Depending on memory layout and error handling, this can disclose adjacent kernel memory through crash artifacts or diagnostic output, or cause a kernel oops, panic, or storage service disruption. Because the attack path depends on local storage metadata manipulation, exploitation is most plausible by a local attacker, malicious administrator-equivalent storage actor, compromised process with block-device write access, or malicious removable/virtual disk image introduced to a host.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the md/raid5 fix validating journal payload sizes before accessing journal metadata. Because no exact fixed version was provided, use the relevant distribution or appliance advisory to identify the first patched kernel package for each platform. Where immediate patching is not possible, reduce exposure by restricting write access to raw block devices, preventing untrusted users from creating or importing md arrays, avoiding attachment of untrusted disks or disk images to vulnerable systems, limiting use of RAID5 journal features where operationally feasible, and ensuring reliable backups before any RAID recovery or rebuild activity. Reboot into the patched kernel after installation; installing a kernel package without booting it does not remediate the running system.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is patched according to the operating system vendor advisory. Validate with commands such as `uname -r` and the platform package manager, then compare against the vendor-fixed kernel build. On source-based or custom kernels, verify the md/raid5 journal recovery code includes bounds validation ensuring each payload fully fits within the metadata block before processing. Inventory systems for Linux md/raid5 usage, especially arrays using write journaling or journal recovery paths, with tools such as `cat /proc/mdstat`, `mdadm --detail`, and distribution storage inventory tooling. After remediation, reboot and confirm the patched kernel is active. For exposure validation, identify hosts that permit local users, containers, VMs, or automation to write raw block devices or attach disk images, as those conditions materially increase exploitability.

Typical attack path

1. Gain local access to a Linux system or obtain the ability to provide or modify a block device used by Linux md/raid5.
2. Identify or create an md/raid5 array that uses journaled RAID5 metadata paths.
3. Write a malformed RAID5 journal metadata block with payload size fields that extend beyond the valid metadata block size.
4. Trigger md/raid5 journal recovery, verification, array assembly, import, or rebuild so the kernel parses the corrupted journal.
5. Cause the vulnerable kernel to perform an out-of-bounds read while processing journal payloads.
6. Leverage the result as a denial of service through kernel crash/panic or, where observable, attempt to recover leaked kernel memory from diagnostics or crash artifacts.

How to detect it

Look for signs that a malformed RAID5 journal triggered kernel faults during array assembly, recovery, or checksum verification. Useful sources include kernel logs, system journal, `/var/log/kern.log`, `/var/log/messages`, crash dumps, kdump/vmcore data, storage monitoring events, and audit logs showing raw block-device writes or RAID management commands before a crash. Search for kernel stack traces referencing md/raid5 journal recovery functions, page faults, general protection faults, out-of-bounds memory access symptoms, or panics occurring near `mdadm` assemble/recovery operations. Correlate these events with recent disk attachment, loop device creation, imported disk images, RAID rebuilds, or unexpected writes to md member devices. There are no reliable network indicators because this is a local kernel/storage metadata vulnerability. In forensic review, prioritize hosts that experienced sudden kernel oops or panic while processing RAID5 journal metadata, especially if preceded by suspicious use of `mdadm`, `losetup`, `dd`, `sg_write_buffer`, `dmsetup`, or direct writes to block devices.

• r5c_recovery_analyze_meta_block
• r5l_recovery_verify_data_checksum_for_mb
• md/raid5
• raid5
• journal metadata
• BUG: unable to handle page fault
• general protection fault
• kernel panic
• Oops:
• mdadm --assemble
• mdadm --run
• /proc/mdstat
• /var/log/kern.log
• /var/log/messages
• /var/crash
• vmcore
• kdump

What your security team should do

• Prioritize patching storage servers, virtualization hosts, multi-user Linux systems, and appliances using Linux md/raid5 before lower-risk single-user systems.
• Inventory Linux hosts for md/raid5 arrays and RAID journaling exposure using `/proc/mdstat`, `mdadm --detail`, and configuration management data.
• Restrict raw block-device write access to trusted administrative roles only; review membership in storage-related privileged groups and use of sudo rules that permit `mdadm`, `losetup`, `dmsetup`, or direct disk writes.
• Do not import, assemble, or recover untrusted RAID arrays, removable media, or disk images on production systems until patched.
• Monitor for kernel oops, panic, page fault, or RAID recovery errors referencing md/raid5 journal recovery routines.
• Ensure recent backups and tested recovery procedures exist for systems relying on affected software RAID storage.
• Because this is not currently KEV-listed and has low EPSS, treat it as a targeted local/storage-path risk rather than broad internet-facing emergency, while still patching within normal kernel security maintenance windows.