CVE-2026-98845 in Linux
الملخص
بحسب VulDB • 18/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
tpm: تعطيل وحدة TPM عند عدم تطابق اسم المفتاح الفارغ (null)
يوجد فحص لاسم المفتاح الفارغ لحماية النظام من هجمات إعادة تعيين وحدة TPM، وبالتالي يجب أن يؤدي أي عدم تطابق إلى إيقاف الجهاز عن معالجة الطلبات الإضافية. ومع ذلك، فإنه لا يقوم حالياً بتعطيل الشريحة عند اكتشاف عدم التطابق.
يتم تسجيل حالة عدم التطابق على النحو التالي:
tpm tpm0: null key integrity check failed
ولكن تظل الشريحة تقوم بمعالجة الأوامر:
/ # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ...
تقوم الدالة `tpm2_load_null()`، حيث يتم تشغيل فحص اسم المفتاح الفارغ، بتعيين حالة الشريحة على أنها معطلة فقط إذا كان رمز الخطأ (rc) غير صفري. وعند رصد عدم التطابق، يكون قيمة rc هي صفر في تلك اللحظة وتعود بالدالة بنتيجة نجاح. المشكلة الأخرى هي أن المتصل يتوقع أن يتم تعبئة مقبض المفتاح الفارغ عند عودة الدالة بقيمة 0، وهو ما تفعله هنا دون كتابة المقبض وتتابع العمل بافتراض أن مقبض المفتاح الفارغ صالح.
أثناء الاختبار، لاحظت أن `tpm2_start_auth_session()` تستخدم قيمة المكدس غير المُهيَّأة كمقبض للمفتاح، نظرًا لأن `tpم2_load_null()` تعيد 0 على الرغم من فشل السلامة (integrity) وتتابع العمل مع الأمر TPM2_CC_START_AUTH_SESS مستخدمة هذه القيمة كمقبض لمفتاح الملح.
تم تعيين rc إلى -ENODEV في حالة عدم التطابق. يؤدي مسار الخطأ بعد ذلك إلى تعطيل الشريحة وإرجاع الرمز الصحيح للمتصل.
تم الاختبار باستخدام QEMU و swtpm ومع تفعيل CONFIG_TCG_TPM2_HMAC=y عن طريق جعل TPM2_CC_CONTEXT_LOAD يفشل بـ TPM2_RC_INTEGRITY وتغيير اسم المفتاح الفارغ المعاد إنشائه. أصبحت الشريحة معطلة الآن عند رصد عدم التطابق.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.