---
id: CVE-2026-90181
title: |-
  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 in…
summary: |-
  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 in…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 309e02dccf64e1b7bd2067abedc270e33b0aadf3 <
    b9cc6cc74daf6fef533dbe65d8cee779fea69600
  - >-
    Linux >= 309e02dccf64e1b7bd2067abedc270e33b0aadf3 <
    4fd66a7f829f3f38f92a79081f0f2688aed644f0
  - Linux 7.1
published: '2026-09-17'
updated: '2026-09-17'
sourceUpdated: '2026-09-17T17:17:12.287'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-90181'
references:
  - url: 'https://git.kernel.org/stable/c/4fd66a7f829f3f38f92a79081f0f2688aed644f0'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/b9cc6cc74daf6fef533dbe65d8cee779fea69600'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-17T16:21:47.866Z'
epss: 0.00213
epssPercentile: 0.10405
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.