Linux Kernel EUVD-2026-32889

Exploitation requires a dm-verity device with FEC enabled that was configured with a non-default fec_roots value - specifically roots of 17, 19, 21, or 23 (with block_size=4096) - AND a low-memory condition in which the maximum FEC buffers cannot be allocated, forcing the small nbufs counts enumerated in the commit (e.g. roots=17 with nbufs in {1,3,5,15}). Limiting factors that sharply constrain real-world risk: the attack vector is local (AV:L) and requires some privilege (PR:L) to access the verity/FEC code path; default fec_roots configurations are NOT affected; and the bug 'doesn't normally happen' because both the non-default roots count and the memory-pressure-induced buffer shortfall must coincide. There is no remote or network exploitation path.

Signals are consistent and point to low real-world priority despite a 7.1 'High' base score. The CVSS vector (AV:L/AC:L/PR:L/UI:N/C:H/I:N/A:H) requires local access and some privilege, and the EPSS of 0.02% (5th percentile) reflects negligible expected exploitation. There is no CISA KEV listing and no public PoC, so exploitation status is 'no public exploit identified at time of analysis.' Critically, the kernel commit itself states the bug 'doesn't normally happen' - it requires BOTH a non-default fec_roots value (e.g. 17, 19, 21, 23) AND a specific small nbufs count that only occurs under memory pressure when maximum buffers cannot be allocated. The NVD vector reports AC:L, but the narrow enumerated trigger conditions argue for higher real-world attack complexity (AC:H) - a discrepancy defenders should note: the raw CVSS understates how rarely the preconditions are met. This is a correctness/hardening fix far more than an attacker priority.

A local user (or a process able to attach/mount a crafted dm-verity FEC device) configures or accesses a verity device built with a non-default fec_roots value while the host is under memory pressure, causing FEC decode to run with the minimal buffer count. During Reed-Solomon recovery, fec_decode_bufs() reads beyond the parity block buffer, potentially disclosing adjacent kernel memory or crashing the kernel. No public exploit code exists, and the narrow, partly memory-dependent preconditions make reliable triggering difficult.