UBUNTU-CVE-2026-74372: Low severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: raid1: fix nrpending leak in REQATOMIC bad-block error path In raid1writerequest(), each per-mirror loop iteration begins by incrementing rdev->nrpending. If a REQATOMIC write encounters a badblock within the requested range, the code jumps to errhandle without dropping the reference taken for the current mirror. errhandle's cleanup loop will only decrements for k < i and r1bio->bios[k] is non-NULL. The current slot is therefore skipped, leaving its nrpending reference leaked permanently. The reference prevents the rdev from ever being removed, since raid1removeconf() refuses to remove an rdev with nrpending > 0. Fix this by calling rdevdecpending() before jumping to errhandle.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 7.0.0-1025.26 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.0.0-1023.23 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In the Linux kernel RAID1 write error path, call rdev_dec_pending() before jumping to err_handle when a REQ_ATOMIC write encounters a bad block, so the current mirror's nr_pending reference is released.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Affected systems are using RAID1 on one of the listed Ubuntu kernel packages. The leak is triggered only when a REQ_ATOMIC write encounters a bad block within its requested range on a RAID1 mirror.
What is the operational impact if the issue is triggered?
The affected mirror device retains a permanently elevated nr_pending reference count. As a result, RAID1 removal of that rdev is refused because raid1_remove_conf() will not remove devices with nr_pending greater than zero.
How can administrators recognize a potentially affected mirror device?
A relevant symptom is an inability to remove a RAID1 member device because its nr_pending count remains above zero. This follows an atomic write error involving a bad block on that mirror.