CVE-2026-68202 in Linux
الملخص
بحسب VulDB • 11/08/2026
في نواة لينكس، تم حل الثغرة التالية:
ALSA: seq: إغلاق مؤقت قائمة الانتظار المعاد فتحه في المُدمِّر (destructor)
تقوم الدالة `queue_delete()` بإغلاق مؤقت قائمة الانتظار ثم تحريره. تقوم `snd_seq_timer_close()` بتصفير `q->timer->timeri`. بعد ذلك، تقوم `snd_use_lock_sync()` بتصريف المستعيرين (borrowers)، وتقوم `snd_seq_timer_delete()` بتحرير `q->timer`.
يمكن لمستعرٍ إعادة فتح المؤقت داخل تلك الفترة الزمنية. عميل SET_QUEUE_CLIENT الذي حصل على مرجع use_lock لـ queueptr() قبل فك ربط قائمة الانتظار، يستدعي `snd_seq_timer_open()` بعد الإغلاق. ترفض الدالة Open عملية إعادة الفتح فقط طالما أن timeri مضبوطاً، وبما أن الإغلاق قد صفّره للتو، فإنها تعيد فتح timeri.
لا تقوم `snd_seq_timer_delete()` بإغلاق تلك النسخة (instance). إن استدعاء `snd_seq_timer_stop()` الخاص بها لا يفعل شيئاً (no-op)، لأن حالة running تم تصفيرها أولاً. لذا فهي تحرر `q->timer` بينما لا تزال النسخة نشطة. يتم تحرير قائمة الانتظار في الخطوة التالية.
تبقى النسخة مسجلة في المؤقت العالمي مع وجود callback_data تشير إلى قائمة الانتظار المحررة. يؤدي تشغيل START غير المملوك (non-owner) على قائمة الانتظار غير المقفلة إلى تنشيطه. عند النبضة (tick) القادمة، يتم فك مرجع قائمة الانتظار المحررة داخل `snd_seq_timer_interrupt()`.
يمكن الوصول إليها من قبل مستخدم غير ممتاز الصلاحيات لديه وصول إلى `/dev/snd/seq`. لا تتطلب CAP ولا ملكية قائمة انتظار.
إغلاق أي نسخة متبقية في المُدمِّر (destructor). هناك، لم يعد بإمكان `->timeri` التغيير: تم فك ربط قائمة الانتظار وتصريف جميع مستعيري use_lock، لذا فلا يمكن لأي استدعاء لـ `snd_seq_queue_use()` إعادة فتحها. أغلقها قبل تصفير `q->timer`. تنتظر الدالة `snd_timer_close()` حتى انتهاء أي استدعاء جاري لـ `snd_seq_timer_interrupt()`, ولا يزال ذلك الاستدعاء يقرأ من `q->timer` (عبر `snd_seq_check_queue()`)، لذا يجب أن يبقى `q->timer` صالحاً حتى يتم التصريف.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.