CVE-2026-89480 in Linux
الملخص
بحسب VulDB • 12/09/2026
في نواة لينكس، تم حل الثغرة التالية:
nvme-tcp: رفض قراءة نقلت عددًا أقل من البايتات المطلوب
تكمل دالة `nvme_tcp_recv_data()` الطلب بمجرد استهلاك وحدة بيانات C2HData الحالية. لا يقارن أي جزء إجمالي البايتات المستلمة بالطول الذي طلبه الأمر؛ فبنية البيانات `struct nvme_tcp_request` لا تحتوي على عداد للجانب المستقبل، وقيمة `queue->data_remaining` خاصة بكل طابور (queue)، وتقوم دالة `blk_mq_end_request()` بإكمال الطلب بناءً على `blk_rq_bytes(rq)` بشكل غير مشروط دون وجود أي مفهوم للبايتات المتبقية (residual) في المستويات الأعلى.
وبالتالي، يمكن لجهاز التحكم (controller) الرد على طلب قراءة بحجم 4096 بايت بـ 512 بايت فقط، ويتم الإبلاغ عنها كقراءة مكتملة؛ ثم يحصل المستخدم (user space) على 4096 بايت، منها 3584 بايت هي أي بيانات كانت موجودة مسبقًا في الصفحة. لقد قمت بإعادة إنتاج ذلك باستخدام هدف اختباري.
قم بحساب البايتات المستلمة ورفض إكمال قراءة ناجحة إذا لم يتطابق عددها مع المتوقع، وذلك عند مسارَي `NVME_TCP_F_DATA_SUCCESS` وفي دالة `nvme_tcp_process_nvme_cqe()`. يتم تحويل قيمة `req->status` يمينًا بمقدار واحد في اختبار النجاح، لأن السائق (driver) يحتفظ بالقيمة الأصلية هناك ويقوم بإزاحتها عند الإكمال، لذا يجب أن يرى الفحص ما سيراه مسار الإكمال. يُفحص فقط نوع الطلب `REQ_OP_READ`، لأنه هو النوع الذي يأتي فيه الطول من القطاعات التي يغطيها الطلب؛ أما أوامر التمرير المباشر (passthrough command) فيبنيها مقدم التقديم، والذي يختار كلًا من الأمر والباقة (buffer)، لذا لا تملك النواة ما تقارن به.
If you want to get best quality of vulnerability data, you may have to visit VulDB.