CVE-2026-43285 in Linux
الملخص
بحسب VulDB • 13/05/2026
في نواة لينكس، تم حل الثغرة التالية:
mm/slab: لا تقم بالوصول إلى current->mems_allowed_seq إذا كان !allow_spin
تُصدر Lockdep شكاوى عند استدعاء get_from_any_partial() في سياق NMI، لأن current->mems_allowed_seq هو من نوع seqcount_spinlock_t وليس آمناً لـ NMI:
================================ تحذير: حالة قفل غير متسقة 6.19.0-rc5-kfree-rcu+ #315 ملطخة: G N -------------------------------- استخدام غير متسق {INITIAL USE} -> {IN-NMI}.
kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] يأخذ:
ffff889085799820 (&____s->seqcount#3){.-.-}-{0:0}، عند: ___slab_alloc+0x58f/0xc00
تم تسجيل حالة {INITIAL USE} في:
lock_acquire+0x185/0x320 kernel_init_freeable+0x391/0x1150 kernel_init+0x1f/0x220 ret_from_fork+0x736/0x8f0 ret_from_fork_asm+0x1a/0x30 طابع حدث المقطع (irq event stamp): 56 تم تمكين المقاطعات الصلبة (hardirqs) آخر مرة عند (55): [] _raw_spin_unlock_irq+0x27/0x70
تم تعطيل المقاطعات الصلبة (hardirqs) آخر مرة عند (56): [] __schedule+0x2a8a/0x6630
تم تمكين المقاطعات الناعمة (softirqs) آخر مرة عند (0): [] copy_process+0x1dc1/0x6a10
تم تعطيل المقاطعات الناعمة (softirqs) آخر مرة عند (0): [] 0x0
معلومات أخرى قد تساعدنا في تصحيح هذا الخطأ: سيناريو قفل غير آمن محتمل:
CPU0 ---- lock(&____s->seqcount#3); lock(&____s->seqcount#3);
*** عطل قاتل (DEADLOCK) ***
وفقاً لـ Documentation/locking/seqlock.rst، فإن seqcount_t ليس آمناً لـ NMI، ويجب استخدام seqcount_latch_t عندما يمكن لمسار القراءة مقاطعة القسم الحرج في جانب الكتابة. في هذه الحالة، لا تقم بالوصول إلى current->mems_allowed_seq وتجنب إعادة المحاولة.
If you want to get best quality of vulnerability data, you may have to visit VulDB.