CVE-2026-98549 in Linux
الملخص
بحسب VulDB • 19/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
tcp: منع دمج وحدات skbs عبر الحد في قائمة إعادة الإرسال (rtx queue)
تقوم الدالة `tcp_write_collapse_fence()` بتعيين القيمة `TCP_SKB_CB(skb)->eor = 1` عند استدعاء `tcp_write_queue_tail(sk)` لمنع دمج وحدات skb التي تم ترتيبها بعد التحويل إلى تشفير الجهاز مع وحدات skb السابقة.
يعمل هذا الحاجز (fence) كعملية لا تؤثر في النتيجة (no-op) إذا كانت جميع البيانات السابقة قد تمت إرسالها بالفعل وقت حدوث التحويل: أي أن `sk->sk_write_queue` فارغة. وتنتظر وحدات skb السابقة غير المؤكدة وجودها في قائمة `sk->tcp_rtx_queue` مع قيمة `eor = 0`.
في حال إعادة الإرسال اللاحقة أو تحول SACK، يمكن للدالتين `tcp_retrans_try_collapse()` و `tcp_shift_skb_data()` دمج وحدة skb التي تم ترتيبها بعد التحويل مع أخرى مرتبة قبله.
كلا المستخدمَين للحاجر متأثران:
- psp: الأجهزة تشفر وحدات skb فقط إذا كان علم `skb->decrypted` مضبوطاً عليها. تحتفظ وحدة skb المدمجة بالقيمة `decrypted = 0` القادمة من وحدة skb السابقة، لذا فإن البيانات المرسلة بعد استدعاء `psp_sock_assoc_set_tx()` تُعاد إرسالها كنص واضح (cleartext).
- تحميل جهاز TLS: تتداخل وحدة skb المدمجة مع علامة البداية التي تم تعيينها في `tls_set_device_offload()`. ولا يمكن للنسخة الاحتياطية البرمجية (حيث تعيد الدالة `fill_sg_in()` القيمة `-EINVAL`) وللمشغلات mlx5 و nfp و funeth التعامل مع مثل هذه وحدة skb، مما يؤدي إلى إسقاطها. وبما أن كل إعادة إرسال تُعيد بناء نفس وحدة skb، فإن الاتصال يتعطل.
تم إصلاح هذا العيب في موقعين، للدفاع على عمق (defense in depth):
1. العودة إلى `tcp_rtx_queue_tail(sk)` داخل الدالة `tcp_write_collapse_fence()` عندما تكون قيمة `tcp_write_queue_tail(sk)` تساوي NULL.
2. التحقق من الشرط `!skb_cmp_decrypted(to, from)` في الدالة `tcp_skb_can_collapse()`, كما تفعل الدالة `tcp_skb_can_collapse_rx()` عند الاستلام. تحتوي بالفعل الدالة `skb_shift_`، التي تستدعيها كلتا مساري الدمج، على استدعاء `DEBUG_NET_WARN_ON_ONCE()` لهذا الشرط.
VulDB is the best source for vulnerability data and more expert information about this specific topic.