In the Linux kernel, the following vulnerability has been resolved:
dm-verity: fix buffer overflow in FEC calculation
There's a buffer overflow in dm-verity-fec:
if (neras && neras <= v->fec->roots)
fio->erasures[(neras)++] = i;
This allows *neras to reach roots + 1 (the post-increment pushes it past
roots). This value is then passed as no_eras to decode_rs8(). Inside the
RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator
polynomial loop writes lambda[j] where j can reach nroots + 1 — one
element past the end of lambda[] (which is sized nroots + 1, valid
indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting
the syndrome buffer.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - In cloud/network-boot deployments where dm-verity data, hash, or FEC backing devices are served over NBD/iSCSI/TCP, a remote block provider can supply crafted blocks that drive the FEC erasure-correction path during ordinary read I/O through verity_map without local code execution.
AC:L - A crafted backing image or malicious network-block responses can deterministically produce at least fec_roots+1 hash-mismatched or failed message blocks in one RS group, reliably reaching the off-by-one no_eras path on the second FEC decode attempt after verification failure.
PR:N - Triggering requires only read I/O against an active dm-verity+FEC mapping; a remote NBD/iSCSI peer needs no account or privileges on the victim host, and unprivileged local processes with read access to the mapped device or filesystem can also reach the vulnerable FEC path.
UI:N - Exploitation is driven by automatic boot-time reads, udev probing, or ordinary filesystem I/O on the dm-verity device; no specific victim action beyond normal system operation is required once corruption is present.
S:U - The overflow corrupts kernel heap Reed-Solomon scratch buffers during dm-verity verification within the same kernel security authority; it does not by itself cross VM, IOMMU, or sandbox boundaries.
C:H - The inflated no_eras value causes decode_rs8 to XOR-write one uint16 past lambda[] into syn[0], corrupting adjacent kernel decoder state; such heap out-of-bounds writes can be leveraged for arbitrary memory disclosure.
I:H - The same out-of-bounds write in the erasure-locator loop corrupts syndrome buffers later used to modify decoded message bytes, providing a heap memory-corruption primitive that can enable arbitrary kernel writes or control-flow hijacking.
A:H - Corrupting Reed-Solomon decoder state during dm-verity verification can cause kernel oops, panics, or hung I/O on critical read-only partitions (notably Android/embedded systems with FEC enabled), denying availability of the device or entire system.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - In cloud/network-boot deployments where dm-verity data, hash, or FEC backing devices are served over NBD/iSCSI/TCP, a remote block provider can supply crafted blocks that drive the FEC erasure-correction path during ordinary read I/O through verity_map without local code execution.
AC:L - A crafted backing image or malicious network-block responses can deterministically produce at least fec_roots+1 hash-mismatched or failed message blocks in one RS group, reliably reaching the off-by-one no_eras path on the second FEC decode attempt after verification failure.
PR:N - Triggering requires only read I/O against an active dm-verity+FEC mapping; a remote NBD/iSCSI peer needs no account or privileges on the victim host, and unprivileged local processes with read access to the mapped device or filesystem can also reach the vulnerable FEC path.
UI:N - Exploitation is driven by automatic boot-time reads, udev probing, or ordinary filesystem I/O on the dm-verity device; no specific victim action beyond normal system operation is required once corruption is present.
S:U - The overflow corrupts kernel heap Reed-Solomon scratch buffers during dm-verity verification within the same kernel security authority; it does not by itself cross VM, IOMMU, or sandbox boundaries.
C:H - The inflated no_eras value causes decode_rs8 to XOR-write one uint16 past lambda[] into syn[0], corrupting adjacent kernel decoder state; such heap out-of-bounds writes can be leveraged for arbitrary memory disclosure.
I:H - The same out-of-bounds write in the erasure-locator loop corrupts syndrome buffers later used to modify decoded message bytes, providing a heap memory-corruption primitive that can enable arbitrary kernel writes or control-flow hijacking.
A:H - Corrupting Reed-Solomon decoder state during dm-verity verification can cause kernel oops, panics, or hung I/O on critical read-only partitions (notably Android/embedded systems with FEC enabled), denying availability of the device or entire system.
CVSS 3.1