# CVE-2026-90181: linux: In the Linux kernel, the following vulnerability has been resolved:  ublk: avoid teardown retry loop on xarray alloca...

CVE-2026-90181 is fixed in linux on 1 platform by DEBIAN-CVE-2026-90181 (version 7.2.6-1), released September 23, 2026. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2026-90181
- Priority: Routine
- CVSS: n/a
- EPSS: 0.0021
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Sep 17, 2026

## Description

In the Linux kernel, the following vulnerability has been resolved:  ublk: avoid teardown retry loop on xarray allocation failure  __ublk_shmem_remove_ranges() removes matching maple tree ranges in batches, but first stores each range into a temporary xarray so that the pages can be unpinned after dropping the maple tree lock.  That temporary xarray is filled under the maple tree lock with xa_store(..., GFP_ATOMIC). If the store fails before mas_erase(), the current range is left in the tree and the helper returns false. The outer ublk_shmem_remove_ranges() loop then immediately retries the same range. While the atomic allocation keeps failing, the teardown path has no forward progress.  The issue can be reproduced with radix_tree_node failslab injection after a SHMEM_ZC buffer has already been registered:    # Kernel config:   #   CONFIG_BLK_DEV_UBLK=y   #   CONFIG_DEBUG_FS=y   #   CONFIG_FAULT_INJECTION=y   #   CONFIG_FAULT_INJECTION_DEBUG_FS=y   #   CONFIG_FAILSLAB=y    echo 10 > /proc/sys/vm/nr_hugepages   mkdir -p /tmp/htlb   mount -t hugetlbfs none /tmp/htlb   fallocate -l 4M /tmp/htlb/ublk_buf    dev_id=$(kublk add -t null --shmem_zc \ 		--htlb /tmp/htlb/ublk_buf | 	   awk -F '[ :]' '/dev id/ {print $3}')    echo 1 > /sys/kernel/slab/radix_tree_node/failslab   echo Y > /sys/kernel/debug/failslab/cache-filter   echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait   echo 1 > /sys/kernel/debug/failslab/interval   echo -1 > /sys/kernel/debug/failslab/times   echo 100 > /sys/kernel/debug/failslab/probability    kublk del -n "$dev_id"  On the unfixed kernel the delete command was still running after 3 seconds. Disabling failslab made it return. The fault-injection stack showed:    should_failslab   kmem_cache_alloc_lru_noprof   __xas_nomem   __xa_store   xa_store   __ublk_shmem_remove_ranges   ublk_cdev_rel   ublk_ctrl_del_dev  Remove the allocation from the teardown loop. Keep the existing batch limit, but collect {base_pfn, nr_pages} pairs in a fixed-size stack array. Once a matching range is found, the range is erased from the maple tree before dropping the lock, so each successful scan makes progress without depending on any GFP_ATOMIC allocation.  With the same failslab settings, the fixed kernel completed "kublk del -n $dev_id" successfully in about 45 ms.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 14 | 7.2.6-1 | [DEBIAN-CVE-2026-90181](https://patchblox.com/security/data/fix/linux/debian-cve-2026-90181.md) | Sep 23, 2026 |

---

Data as of 2026-11-09T01:18:40Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.