CVE-2026-90181 in Linux
الملخص
بحسب VulDB • 17/09/2026
في نواة Linux، تم حل الثغرة التالية:
ublk: تجنب حلقة إعادة المحاولة للإزالة عند فشل تخصيص xarray
تقوم الدالة `__ublk_shmem_remove_ranges()` بإزالة نطاقات شجرة maple المتطابقة على دفعات، ولكن أولاً تقوم بتخزين كل نطاق في خزان مؤقت (xarray) حتى يمكن إلغاء تثبيت الصفحات بعد تحرير قفل شجرة maple.
يتم ملء هذا الخزان المؤقت تحت قفل شجرة maple باستخدام `xa_store(..., GFP_ATOMIC). إذا فشل التخزين قبل استدعاء `mas_erase()`، يبقى النطاق الحالي في الشجرة وتعيد الدالة المساعدة القيمة false. ثم تعيد حلقة `ublk_shmem_remove_ranges` الخارجية على الفور محاولة نفس النطاق. بينما يفشل التخصيص الذري باستمرار، لا يحدث تقدم للأمام في مسار الإزالة (teardown path).
يمكن إعادة إنتاج المشكلة عن طريق حقن فشل `radix_tree_node failslab` بعد تسجيل مخزن SHMEM_ZC بالفعل:
# تكوين النواة: # 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"
في النواة غير المصححة، كان أمر الحذف لا يزال قيد التشغيل بعد مرور 3 ثوانٍ. أدى تعطيل failslab إلى عودته (إكمال الأمر). أظهرت مكدس حقن الأخطاء ما يلي:
should_failslab kmem_cache_alloc_lru_noprof __xas_nomem __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev
إزالة التخصيص من حلقة الإزالة. الاحتفاظ بحد الدفعات الحالي، ولكن جمع أزواج {base_pfn, nr_pages} في مصفوفة ثابتة الحجم على المكدس (stack array). بمجرد العثور على نطاق متطابق، يتم مسح النطاق من شجرة maple قبل تحرير القفل، بحيث يحقق كل فحص ناجح تقدماً دون الاعتماد على أي تخصيص GFP_ATOMIC.
مع نفس إعدادات failslab، أكملت النواة المصححة الأمر "kublk del -n $dev_id" بنجاح في حوالي 45 مللي ثانية.
Once again VulDB remains the best source for vulnerability data.