CVE-2026-46070: md/raid5: validate payload size before accessing journal metadata
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: validate payload size before accessing journal metadata
r5crecoveryanalyzemetablock() and r5lrecoveryverifydatachecksumformb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block.
A corrupted journal contains payload sizes extending beyond the PAGESIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets.
Add bounds validation for each payload type to ensure the full payload fits within metasize before processing.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.141.1-1 - Configuration
Add bounds validation for each journal payload type before processing journal metadata: ensure each on-disk payload size fits within the remaining metadata block space (meta_size) in r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb(), preventing out-of-bounds reads when accessing payload fields or computing offsets.
md/raid5 Validate journal metadata on-disk payload size fields = enabled/implemented
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
An attacker or other local actor needs low privileges and access to a RAID5 journal containing corrupted on-disk metadata. The malformed payload size must extend beyond the metadata block's PAGE_SIZE boundary during journal recovery processing.
What is the practical impact of a successful trigger?
Processing the corrupted journal metadata can cause out-of-bounds reads while accessing payload fields or calculating offsets. The supplied severity vector indicates high confidentiality impact and high availability impact, with no integrity impact.
Are systems using RAID5 journaling the relevant exposure group?
Yes. The affected code is in the Linux kernel md/raid5 journal recovery path, so exposure depends on use of that functionality and processing of a corrupted RAID5 journal rather than merely running a Linux kernel.
How can I determine whether a system has the remediation?
Check the kernel source or vendor patch status for bounds validation in r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() before payload metadata is accessed. The listed stable references identify commits containing the fix.