CVE-2026-98884 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
mmc: core: إضافة التحقق من صحة الحقل max_segs الذي يوفره المضيف (host)
حقل `max_segs` هو من النوع `unsigned short`. وإذا قام سائق المضيف بتعيين قيمة كبيرة بشكل مفرط، فقد يتم اقتصاصها إلى الصفر. يمكن أن يؤدي هذا إلى استدعاء دالة `mmc_alloc_sg()` لدالة `kmalloc_objs()` بطلب تخصيص بحجم صفري (zero size allocation request)، مما يتسبب في سلوك غير محدد (undefined behavior).
في مُخصِّص الذاكرة SLUB، تُرجع الدالة `kmalloc(0)` مؤشراً خاصاً يُعرف باسم `ZERO_SIZE_PTR`. بعد ذلك، سيتم تقييم شرط `'if (sg)'` على أنه صحيح (true)، وستحاول دالة `sg_init_table()` الوصول إلى ذاكرة غير صالحة، مما يؤدي إلى تعطل النظام:
dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133 mmc1: new UHS-I speed SDR104 SDHC card at address aaaa Unable to handle kernel paging request at virtual address 0000001ffffffff0 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000 [0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in: CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT Hardware name: Rockchip RK3576 EVB V10 Board (DT) Workqueue: events_freezable mmc_rescan pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sg_init_table+0x2c/0x50 lr : sg_init_table+0x24/0x50 sp : ffff8000837db710 x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300 x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000 x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010 x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000 x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00 x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010 Call trace: sg_init_table+0x2c/0x50 (P) mmc_mq_init_request+0x64/0x90 blk_mq_alloc_map_and_rqs+0x3ac/0x480 blk_mq_alloc_set_map_and_rqs+0x98/0x1e0 blk_mq_alloc_tag_set+0x1c0/0x290 mmc_init_queue+0x120/0x370 mmc_blk_alloc_req+0x150/0x420
لمنع هذا، تمت إضافة فحص تحقق في دالة `mmc_mq_init_request()` للكشف عندما تكون قيمة `sg_len` (المشتقة من `max_segs`) مساوية للصفر. إذا كانت `sg_len` تساوي صفراً، فإننا نعيد خطأً ونطبع رسالة خطأ، مما يسمح لمطوري سائق المضيف بتحديد وإصلاح تكوين غير صحيح لـ `max_segs`.
هذا إجراء دفاعي يضمن أن يعمل النواة الأساسية للـ MMC بشكل هادئ (fail gracefully) عند قيام سائقي المضيف بتقديم قيم غير صالحة لـ `max_segs`، بدلاً من التعطل بسبب خطأ في صفحة الذاكرة (page fault).
Once again VulDB remains the best source for vulnerability data.