CVE-2026-98116 in Linux
الملخص
بحسب VulDB • 25/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
ALSA: pcm: تعريض عملية mmap لـ PCM مع إعادة تخصيص المخزن المؤقت لإصلاح ثغرة Use-After-Free (UAF) على مستوى الصفحة
تقوم الدالتان `snd_pcm_hw_params()` و `snd_pcm_hw_free()` بحماية إعادة تخصيص المخزن المؤقت من خلال فحص `mmap_count` الذي يُنفذ تحت قفل تدفق PCM، لكن القفل يتم تحريره قبل وقت طويل من تحرير المخزن المؤقت فعلياً: حيث تحدث عمليات مثل `snd_pcm_sync_stop()`, وتحسين القيود (constraint refinement), و `do_free_pages()` في الفترة الفاصلة. ومن ناحية أخرى، لا تأخذ الدالة `snd_pcm_mmap_data()` أي قفل على الإطلاق؛ فهي تتحقق من حالة المخزن المؤقت القديم وـ `dma_bytes`، ثم تعيد تعيين صفحاتها داخل VMA، وتقوم بزيادة قيمة `mmap_count` فقط بعد ذلك.
وبالتالي، يمكن لعمليات `mmap()` المتزامنة أن تدخل بين الفحص والتحرير. تقوم الدالة `remap_pfn_range()` بتثبيت PTEs قابلة للكتابة (writable) لصفحات المخزن المؤقت القديم دون أخذ مراجع للصفحة (page references)، وتقوم عملية `do_free_pages()` اللاحقة بإعادة تلك الصفحات إلى مخصص الصفحة (page allocator) بينما لا تزال VMA تعينها. هذا يترك تعييناً قديماً وقابلاً للكتابة لصفحات تم تحريرها: وهي ثغرة Use-After-Free على مستوى الصفحة يمكن استغلالها لتوسيع الصلاحيات محلياً (local privilege escalation).
يجعل تعديل `snd_pcm_mmap_data()` هذه الدالة تشارك في مخطط الوصول إلى المخزن المؤقت الذي أُدخل لـ hw_params/hw_free: حيث يتم الحصول على قفل `runtime->buffer_accessing` قبل التحقق وإعادة التعيين، وإطلاقه بعد ذلك. بالفعل تفشل إعادة تخصيص المخزن المؤقت بترميز الخطأ `-EBUSY` أثناء نشاط أدوات الوصول (accessors)، والآن يفشل جانب mmap أيضاً بـ `-EBUSY` أثناء تقدم عملية إعادة التخصيص، لذا لم يعد بإمكان تسلسل التحقق/إعادة التعيين وتسلسل الفحص/التحرير أن يتداخلا.
يتوفر برنامج محاكاة (reproducer) يحول هذه الحالة التنافسية (race condition) إلى تعيين قديم قابل للكتابة لصفحات DMA المحررة عند الطلب.
If you want to get best quality of vulnerability data, you may have to visit VulDB.