CVE-2026-46135 in Linux
الملخص
بحسب VulDB • 30/05/2026
في نواة لينكس، تم حل الثغرة التالية:
nvmet-tcp: إصلاح حالة سباق (Race Condition) بين معالجة طلبات ICReq وإغلاق الطابور (Queue Teardown)
تقوم الدالة `nvmet_tcp_handle_icreq()` بتحديث `queue->state` بعد إرسال استجابة اتصال التهيئة (ICResp)، ولكن يتم ذلك دون التزامن (Serialization) مع عملية إغلاق الطابور من جانب الهدف (Target-side).
إذا أرسل مضيف NVMe/TCP طلب اتصال تهيئة (ICReq) وأغلق الاتصال على الفور، فقد تبدأ عملية الإغلاق من جانب الهدف في سياق softirq قبل أن يقوم `io_work` بتصريف طلب ICReq المخزن مؤقتاً بالفعل. في هذه الحالة، تقوم `nvmet_tcp_schedule_release_queue()` بتعيين `queue->state` إلى `NVMET_TCP_Q_DISCONNECTING` وتقليل مرجع الطابور (Queue Reference) تحت قفل `state_lock`.
إذا قام `io_work` بمعالجة طلب ICReq هذا لاحقاً، فقد تقوم `nvmet_tcp_handle_icreq()` بكتابة حالة `NVMET_TCP_Q_LIVE` فوق الحالة السابقة. وهذا يبطل حماية حالة DISCONNECTING الموجودة في `nvmet_tcp_schedule_release_queue()`، مما يسمح لتغيير حالة المقبس (Socket) اللاحق بإعادة الدخول إلى مسار الإصدار وإصدار استدعاء `kref_put()` ثانٍ على طابور تم إصداره بالفعل.
مسار فشل إرسال ICResp يعاني من نفس المشكلة. إذا كانت عملية الإغلاق قد نقلت الطابور بالفعل إلى حالة DISCONNECTING، فقد يؤدي خطأ الإرسال إلى كتابة الحالة مرة أخرى بـ `NVMET_TCP_Q_FAILED`، مما يعيد فتح النافذة أمام مسار إغلاق ثانٍ لتقليل مرجع الطابور.
لإصلاح هذه المشكلة، يتم التزامن (Serialization) لكلا انتقالات الحالة ما بعد الإرسال باستخدام `state_lock`، والانسحاب (Bailing out) إذا كانت عملية الإغلاق قد بدأت بالفعل.
يتم استخدام `-ESHUTDOWN` كعلامة داخلية (Internal Sentinel) لمسار الانسحاب بدلاً من نشرها كخطأ في النقل مثل `-ECONNRESET`. يتم الحفاظ على قيام `nvmet_tcp_socket_error()` بتعيين `rcv_state` إلى `NVMET_TCP_RECV_ERR` قبل احترام هذه العلامة، بحيث يظل تحليل الجانب المستلم (Receive-side parsing) هادئاً (Quiesced) حتى تكتمل مسار الإصدار الحالي.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.