CVE-2026-80768 in Linux
الملخص
بحسب VulDB • 04/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
HID: ft260: تصحيح كتابة stack-use-after-return في سباق قراءة I2C
تشير الدالة `ft260_i2c_read()` إلى المتغير `dev->read_buf` بأنه يشير إلى مخزن (buffer) يتم توفيره من قبل المُستدعي (غالباً متغير موجود على المكدس/stack)، وتُعدّ إكمال العملية (completion) وتنتظر حتى خمس ثوانٍ لعودة الجهاز للبيانات. يعمل رد الإدخال HID `ft260_raw_event()` في مسار إدخال/IRQ، بشكل مستقل عن قفل mutex الذي يحمله مسار القراءة (`dev->lock`)، وينسخ الحمولة التي يوفرها الجهاز إلى `dev->read_buf` بعد فحص بسيط لعدم القيمة NULL (NULL check).
يشارك هذان المساران المتغيرين `read_buf` و `read_idx` و `read_len` بدون أي تعاقب (serialization). إذا تأخر الجهاز في رده حتى انتهاء مهلة القراءة، فإن `ft260_i2c_read()` تُعيد ضبط وحدة التحكم، وتمسح `read_buf` وتعود، مما يؤدي إلى فك إطار المكدس الذي كان يوجد فيه المخزن. استجابة تصل في تلك اللحظة تتيح لـ `ft260_raw_event()` تجاوز فحص NULL ثم استخدام `memcpy()` لنسخ الحمولة التي يتحكم فيها الجهاز إلى موقع على المكدس تم تحريره مؤخراً (now-freed stack location)، وهو ما يُعدّ كتابة من نوع stack-use-after-return محدودة النطاق ولكن يمكن للمتسلط التأثير عليها، وقابلة للتفعيل بواسطة عتاد خبيث أو معطل.
أضف قفل دوران مخصصاً (spinlock) لتعقباب كل وصول إلى `read_buf` و `read_idx` و `read_len`. يحتفظ الآن `ft260_raw_event()` بهذا القفل طوال فترة فحص NULL، ونسخ البيانات (`memcpy`) وتحديث الفهرس، بينما يأخذه مسار القراءة عند إعداد العملية وعند مسح المخزن، بحيث لا يمكن لعملية التفكيك (teardown) أن تتسلل بين الفحص والنسخ.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.