{
  "cveId": "CVE-2026-90181",
  "url": "https://patchblox.com/security/cve/CVE-2026-90181",
  "summary": "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.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  ublk: avoid teardown retry loop on xarray alloca...",
  "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 \u003E /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 \\ \t\t--htlb /tmp/htlb/ublk_buf | \t   awk -F \u0027[ :]\u0027 \u0027/dev id/ {print $3}\u0027)    echo 1 \u003E /sys/kernel/slab/radix_tree_node/failslab   echo Y \u003E /sys/kernel/debug/failslab/cache-filter   echo Y \u003E /sys/kernel/debug/failslab/ignore-gfp-wait   echo 1 \u003E /sys/kernel/debug/failslab/interval   echo -1 \u003E /sys/kernel/debug/failslab/times   echo 100 \u003E /sys/kernel/debug/failslab/probability    kublk del -n \u0022$dev_id\u0022  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 \u0022kublk del -n $dev_id\u0022 successfully in about 45 ms.",
  "published": "2026-09-17T17:17:12Z",
  "severity": "",
  "epss": 0.00213,
  "epssPercentile": 0.11623,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.6-1",
      "fix": "DEBIAN-CVE-2026-90181",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-90181",
      "released": "2026-09-23T19:19:02Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-09T01:18:40Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}