CVE-2026-46130

What it actually does

This is a local Linux kernel memory-safety flaw in dm-verity forward error correction handling. Under specific dm-verity FEC configurations, fec_decode_bufs() can incorrectly assume Reed-Solomon parity bytes are contained within a single parity block when they may span a block boundary. When memory pressure causes a reduced number of FEC buffers to be allocated, certain fec_roots and buffer-count combinations can lead the kernel to read past the end of a parity block buffer. The likely technical outcomes are kernel memory disclosure and/or kernel crash, reflected by the CVSS impact of high confidentiality impact and high availability impact, with no direct integrity impact described.

Why it matters to the business

Successful exploitation could allow a local user or process to crash affected Linux systems or potentially expose sensitive kernel memory. For organizations relying on dm-verity for verified boot, appliance integrity, Android-like verified partitions, embedded systems, immutable infrastructure, or tamper-resistant storage, the operational risk is service disruption and possible leakage of privileged data. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no public exploit maturity indicated, so broad internet-scale exploitation is unlikely; however, systems using dm-verity FEC with non-default parameters should still be prioritized because kernel crashes can affect availability of critical workloads.

How an attack unfolds

An attacker first needs local code execution with low privileges on a Linux system using dm-verity with FEC enabled. The vulnerable path is reachable when reads from a dm-verity protected device require FEC decoding and the FEC configuration uses affected parameter combinations, such as specific fec_roots values, block sizes, and reduced nbufs caused by allocation constraints. The attacker would attempt to cause or influence reads that trigger FEC decoding across parity block boundaries, potentially under memory pressure so the maximum number of FEC buffers is not available. When fec_decode_bufs() processes parity data split across blocks, it can read beyond the parity block buffer. Depending on kernel build options, memory layout, and runtime conditions, this may produce a kernel oops/panic, denial of service, or exposure of adjacent kernel memory through the FEC decoding path.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream fix for dm-verity-fec parity-byte handling. No exact fixed package versions were provided in the input, so use the latest stable kernel from the relevant Linux distribution or vendor advisory once available. Prioritize systems that use dm-verity with FEC enabled, especially embedded, appliance, kiosk, mobile, secure-boot, container host, or immutable OS deployments. If immediate patching is not possible, reduce exposure by disabling dm-verity FEC where operationally acceptable, avoiding non-default affected FEC parameter combinations, limiting local shell or workload execution to trusted users, and reducing opportunities for untrusted users to create memory pressure or repeatedly access dm-verity protected devices. Kernel hardening features such as KASLR, hardened usercopy, panic-on-oops policy review, and least-privilege controls can reduce exploitability or blast radius but do not replace patching.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the dm-verity-fec fix, not merely that an updated package is installed. Check the booted kernel with uname -r and compare it against the distribution or vendor advisory for this vulnerability. Review kernel changelogs or source patches for the dm-verity FEC fix that refactors parity block reading in fec_decode_bufs(). Inventory systems for dm-verity usage by checking device-mapper tables and boot configuration for verity/FEC parameters. Validate that vulnerable configurations are no longer present or that the kernel has been updated. Where feasible in a test environment, exercise dm-verity FEC reads under memory pressure and confirm no KASAN, UBSAN, oops, or panic messages occur in kernel logs.

Typical attack path

1. Gain local, low-privileged execution on an affected Linux system.
2. Determine whether dm-verity with FEC is enabled and whether the system uses vulnerable FEC parameters.
3. Create or wait for conditions that force FEC decoding of protected data blocks, potentially involving corrupted or unreadable data that requires correction.
4. Apply memory pressure so dm-verity FEC allocates fewer buffers than the maximum expected count.
5. Trigger reads that cause parity bytes for a Reed-Solomon codeword to span a parity block boundary.
6. Abuse the resulting out-of-bounds kernel read to crash the system or attempt to infer adjacent kernel memory.

How to detect it

Because exploitation is local and kernel-level, detection should focus on host telemetry rather than network indicators. Review kernel logs from journald, dmesg, syslog, audit logs, crash dump systems, and EDR telemetry for dm-verity FEC errors, kernel oops/panic events, KASAN or UBSAN reports, and stack traces referencing fec_decode_bufs or dm-verity-fec. Look for repeated crashes or oops events correlated with local users, containers, untrusted workloads, memory pressure events, or heavy reads from dm-verity protected block devices. Inspect device-mapper configuration using dmsetup table or equivalent inventory data to identify verity devices with FEC parameters. If crash dumps are available, analyze whether faults occurred during dm-verity FEC decoding and whether they involved out-of-bounds reads near parity block boundaries. There are no known public exploit indicators, no KEV listing, and no named threat actors provided, so absence of these artifacts does not prove safety; it only reduces evidence of observed exploitation.

• fec_decode_bufs
• dm-verity-fec
• dm_verity_fec
• verity_fec
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: KASAN
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• device-mapper: verity-fec
• dm-verity:
• out-of-bounds read
• general protection fault
• Unable to handle kernel paging request

What your security team should do

• Inventory Linux systems using dm-verity with FEC enabled; prioritize these over systems that do not use dm-verity FEC.
• Patch affected systems to a vendor kernel containing the dm-verity-fec fix as soon as practical, especially for appliances, embedded devices, and systems with untrusted local users or workloads.
• If patching is delayed, disable FEC or avoid vulnerable non-default fec_roots and buffer configurations where supported and operationally safe.
• Restrict local access and untrusted workload execution on potentially affected systems until patched.
• Monitor kernel logs for dm-verity, FEC, KASAN, out-of-bounds read, oops, panic, or fec_decode_bufs-related messages.
• Review crash dumps from affected systems for evidence of repeated dm-verity-fec faults, which may indicate attempted exploitation or reliability exposure.
• Track distribution advisories because fixed versions are vendor-specific and were not provided in the input.