CVE-2026-90181

What the bug is

__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 lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

drivers/block/ublk_drv.c

What this is

UBLK USERSPACE BLOCK DRIVERMAINTAINERS section matched on drivers/block/ublk_drv.c · linux-block@vger.kernel.org · Maintained

Kernel module

ublk_drv

Check it on the machine

grep -w CONFIG_BLK_DEV_UBLK /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w ublk_drv

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.

• bookwormn
• trixie, forky, sidm

n

not enabled on any flavour - this release does not build the code

m

a loadable module on every flavour - check lsmod, can be blacklisted

Build switch

CONFIG_BLK_DEV_UBLK

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-17 (31 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.21%, higher than 10.8% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

unimportantsource

Subsystem

drivers/block

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
7.1	7.2.6	b9cc6cc74daf
7.1	7.3	4fd66a7f829f