Microsoft Security Response Center guidance
Vendor revision: Oct 16, 2026Release Notes
Vulnerability intelligence
CVE-2025-71161 and is rated Medium severity with a CVSS score of 5.5. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.
Release Notes
This update corrects flaws in the following subsystems: - Foo-over-UDP (FOU); - ARM64 architecture; - x86 architecture; - Block layer subsystem; - Drivers core; - Null block device driver; - Bluetooth drivers; - Counter interface drivers; - DMA engine subsystem; - DPLL subsystem; - GPIO subsystem; - GPU drivers; - I2C subsystem; - IIO ADC drivers; - IIO subsystem; - InfiniBand drivers; - On-Chip Interconnect management framework; - IOMMU subsystem; - IRQ chip drivers; - Modular ISDN driver; - LED subsystem; - Multiple devices driver; - Media drivers; - UACCE accelerator framework; - MMC subsystem; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Texas Instruments network drivers; - NVME drivers; - Device tree and open firmware driver; - PHY drivers; - x86 platfor
In the Linux kernel, the following vulnerability has been resolved:
dm-verity: disable recursive forward error correction
There are two problems with the recursive correction:
1. It may cause denial-of-service.
In fec_read_bufs, there is a loop that has 253 iterations. For each iteration, we may call verity_hash_for_block recursively.
There is a limit of 4 nested recursions - that means that there may be at most 253^4 (4 billion) iterations. Red Hat QE team actually created an image that pushes dm-verity to this limit - and this image just makes the udev-worker process get stuck in the 'D' state.
2. It doesn't work.
In fec_read_bufs we store data into the variable "fio->bufs", but fio bufs is shared between recursive invocations, if "verity_hash_for_block" invoked correction recursively, it would overwrite partially filled fio->bufs.
Source: NVD