CVE-2026-23086 in Linux
الملخص
بحسب VulDB • 04/06/2026
في نواة لينكس، تم حل الثغرة التالية:
vsock/virtio: تحديد حد ائتمان الإرسال (TX credit) بحجم المخزن المؤقت المحلي
يستمد نقل virtio ائتمان الإرسال (TX credit) الخاص به مباشرةً من `peer_buf_alloc`، والذي يتم تعيينه بناءً على قيمة `SO_VM_SOCKETS_BUFFER_SIZE` من الطرف البعيد.
على جانب المضيف (Host)، يعني هذا أن كمية البيانات التي نرغب في وضعها في طابور (queue) لاتصال ما يتم تحديدها بناءً على حجم المخزن المؤقت الذي يختاره الضيف (Guest)، بدلاً من تكوين vsock الخاص بالمضيف نفسه. يمكن لضيف خبيث الإعلان عن حجم مخزن مؤقت كبير وقراءة البيانات ببطء، مما يؤدي إلى تخصيص المضيف لكمية كبيرة من ذاكرة `sk_buff` تتناسب مع ذلك. يحدث الشيء نفسه في الضيف مع مضيف خبيث، لأن نقلات virtio تشترك في قاعدة كود مشتركة.
تم تقديم مساعد صغير، `virtio_transport_tx_buf_size()`، الذي يعيد القيمة `min(peer_buf_alloc, buf_alloc)`، واستخدامه في كل مكان يتم فيه استهلاك `peer_buf_alloc`.
يضمن ذلك أن نافذة الإرسال الفعالة (TX window) تكون محدودة بكل من المخزن المؤقت المعلن من قبل الطرف الآخر و `buf_alloc` الخاص بنا (المقيد مسبقاً بـ `buffer_max_size` عبر `SO_VM_SOCKETS_BUFFER_MAX_SIZE`)، بحيث لا يمكن لطرف بعيد إجبار الطرف الآخر على وضع المزيد من البيانات في الطابور مما يسمح به إعدادات vsock الخاصة به.
على مضيف Ubuntu 22.04 غير مُرقع (~64 جيجابايت من ذاكرة الوصول العشوائي RAM)، أدى تشغيل نموذج استغلال (PoC) مع 32 اتصال vsock للضيف يعلن كل منها عن 2 جيجابايت ويقرأ ببطء إلى رفع قيمة Slab/SUnreclaim من ~0.5 جيجابايت إلى ~57 جيجابايت؛ ولم يتعافى النظام إلا بعد قتل عملية QEMU. ومع ذلك، إذا تم تحديد ذاكرة QEMU باستخدام cgroups، فسيتم تحديد الحد الأقصى للذاكرة المستخدمة.
مع تطبيق هذا التصحيح:
قبل: MemFree: ~61.6 جيجابايت Slab: ~142 ميغابايت SUnreclaim: ~117 ميغابايت
بعد 32 اتصال عالي الائتمان: MemFree: ~61.5 جيجابايت Slab: ~178 ميغابايت SUnreclaim: ~152 ميغابايت
زيادة قدرها ~35 ميغابايت فقط في Slab/SUnreclaim، ولا يوجد نفاد ذاكرة للمضيف (OOM)، ويبقى الضيف مستجيباً.
التوافق مع نقلات غير virtio:
- يستخدم VMCI مقابض مخزن vsock (AF_VSOCK buffer knobs) لتحديد أحجام أزواج الطابور لكل اتصال بناءً على القيم المحلية `vsk->buffer_*`؛ لا يمكن للطرف البعيد تكبير هذه الطوابير بما يتجاوز ما قام الطرف المحلي بتكوينه.
- يستخدم نقل vsock الخاص بـ Hyper-V مخازن مؤقتة دائرية (ring buffers) ذات حجم ثابت وحد MTU؛ لا يوجد حقل ائتمان يتحكم فيه الطرف الآخر قابل للمقارنة بـ `peer_buf_alloc`، ولا يمكن للطرف البعيد دفع ذاكرة نواة قيد التنفيذ فوق أحجام هذه الحلقات.
- يعيد مسار الحلقة (loopback) استخدام `virtio_transport_common.c`، لذا فهو يتبع بشكل طبيعي نفس الدلالات الخاصة بنقل virtio.
هذا التغيير محدود بـ `virtio_transport_common.c` وبالتالي يؤثر على virtio-vsock و vhost-vsock و loopback، مما يجعلها متوافقة مع سلوك "تقاطع النافذة البعيدة مع السياسة المحلية" الذي تمتلكه VMCI و Hyper-V فعلياً بالفعل.
[Stefano: تعديلات بسيطة بعد تغيير التصحيح السابق]
[Stefano: ضبط رسالة الالتزام (commit message)]
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.