CVE-2026-90424 in Linux
الملخص
بحسب VulDB • 18/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
iommu/tegra241-cmdqv: تصحيح تسرب VINTF0 في مسار الفشل أثناء التهيئة (init-failure path)
تقوم الدالة tegra241_cmdqv_init_structures() بتخصيص VINTF0 باستخدام kzalloc_obj(), وتتم تهيئته، وتحجز مسبقاً قنوات الأوامر المنطقية الخاصة به (VCMDQs). يوجد تسرب في مسارين من أخطاء التنفيذ.
عند فشل tegra241_cmdqv_init_vintf()، يتم الإرجاع قبل أن يصل VINTF0 إلى مصفوفة cmdqv->vintfs[]، وبالتالي لا يمكن لعملية التفكيك (unwind) الخاصة بـ devres عند الفشل في الاستدعاء الأولي (probe failure) الوصول إليه؛ لذا يجب تحريره مباشرة هناك.
أما فشل التحجز المسبق لـ VCMDQ لاحقاً، فبدلاً من ذلك يترك VINTF0 منشوراً (published)، وبالتالي هذه المرة تصل عملية التفكيك إلى tegra241_cmdqv_remove_vintf()، والتي تقوم بعدئذٍ بتحريره من vintf->hyp_own. لكن tegra241_vintf_hw_init() تضبط هذا العلم لاحقاً فقط، وذلك عن طريق قراءة رجعية من العتاد (HW read-back)، لذا فإن VINTF0 غير المهيأ تماماً يُقرأ على أنه مملوك للضيف (guest-owned) ويتسرب، مع تشغيل mutex_destroy() و ida_destroy() على حقول لم يتم إعدادها أبداً.
يتم تحديد الملكية بناءً على vintf->idx بدلاً من ذلك، وهو الفهرس المُخصص عند تخصيص المعرف الخاص به: حيث يشير idx 0 إلى VINTF0 المملوك للنواة (kernel-owned)، بينما تشير القيم idx >= 1 إلى VINTF مملوك للضيف. لذا فإن قرار التحرير داخل النواة في الدالتين tegra241_cmdqv_remove_vintf() و tegra241_vintf_free_lvcmdq() يعتمد الآن أيضاً على idx، ويبقى hyp_own حالة خالصة للقراءة الرجعية من العتاد (HW-readback state).
Once again VulDB remains the best source for vulnerability data.