xen0bit/netprobe-cve-2026-98432مسبار بعيد بالصندوق الأسود يكتشف CVE-2026-98432، وهو ثغرة use-after-free في Linux IPv4 TCP ireq_opt، عبر صدى خيارات SYN-ACK التفاضلي، إضافةً إلى التحقق الساكن من vmlinux.
مرحبًا. CVE-2026-98432 هو ثغرة Use-After-Free قابلة للاستغلال عن بُعد في نواة Linux. تذكر بعض التقارير أن مختبرات الذكاء الاصطناعي استغلتها بعد نحو 45 دقيقة عبر Multi-Path TCP (MPTCP). الثغرة في الواقع موجودة في مكدس IPv4 TCP نفسه، لكن MPTCP هو الطريقة العملية الوحيدة حتى عن بُعد للوصول إلى مسار الشيفرة المصابة. وحتى مع ذلك، فإن الـ 45 دقيقة تلك تستحق تدقيقًا شديدًا.
ireq_opt وأول إزالة مرجع.من المؤكد وجود أنوية Linux مخصصة تستخدم MPTCP مع خيارات توجيه لكل حزمة، والتي من المحتمل أن تجعل هذه الثغرة "قابلة للوصول" بالمعنى الأنقى. عمليًا، من شبه المؤكد أنك لا تشغّل مثل هذا التكوين للنواة، ولست أيضًا محظوظًا بما يكفي ليكون أحدهم قريبًا بما يكفي من زمن التأخر ومثابرًا بما يكفي لاستغلال تلك الفجوة.
العامل الأساسي الذي يجعل الاستغلال عمليًا ولو عن بُعد هو الأجهزة الافتراضية الافتراضية/المُفرطة في التخصيص (oversubscribed VMs)، مع PREEMPT_RT وthreadirqs وغيرها... وهذا ليس شيئًا يملك المهاجم أي سيطرة أو تأثير عليه ما لم يكن لديه وصول إضافي مميز/موثّق. لديّ أصدقاء في المجال يعرفون على الأرجح حيلة أو حيلتين قد تغيّر رأيي، لكنني لا أعرف أي شيء، وقد خرج الذكاء الاصطناعي بلا شيء، وعلى أقل تقدير فإن تلك "الحيلة" إن وُجدت ليست معروفة على نطاق واسع.
يجب عليك ترقيع خوادمك، لكن على الأرجح لا داعي للذعر بشأن ذلك. كل شيء آخر في هذا المستودع، بما في ذلك الأسطر أدناه، مُولَّد بالذكاء الاصطناعي، لكنني قدت الجلسة وراجعت المخرجات للتأكد من دقتها.
كما يلي:
مسبار أسود الصندوق عن بُعد يُثبت وجود CVE-2026-98432
(ثغرة use-after-free في ireq_opt / inet_opt في Linux IPv4 TCP) بأدلة على مستوى الحزم — وليس بمطابقة إصدارات النواة.
يتوقف عند use-after-free: فهو يُثبت أن النواة قرأت ذاكرة محرَّرة وأعلنت ذلك على الشبكة. وهو لا يتجاوز KASLR، ولا يختطف تدفق التحكم، ولا ينفّذ شيفرة.
للاختبار المصرّح به فقط. يمكن لمسبار السباق أن يزعزع استقرار الهدف؛ فانهيار النواة نتيجة محتملة. استخدمه فقط على خوادم تملكها أو لديك إذن كتابي باختبارها.
الإصلاح هو e3f33b0a1d89d738e2b913dab519226eaf76e15b
(ipv4: free inet_opt and ireq_opt after an RCU grace period)، وهو تغيير من سطرين
من kfree() إلى kfree_rcu() في inet_sock_destruct() و
tcp_v4_reqsk_destructor().
tcp_v4_init_req() خيارات IP المُعادة في SYN (Record Route /
Timestamp) في ireq->ireq_opt.tcp_v4_syn_recv_sock() المؤشر إلى المقبس الابن بدلًا
من نسخه.ireq->ireq_opt تحت
rcu_read_lock() ويستخدمه في ip_options_build().تلك النقطة الأخيرة هي الكاشف: فالنواة تعيد إرسال بايتات الخيارات القديمة إلى المرسل.
تصحيح النطاق: سجل CVE عام لـ IPv4 TCP. فقط مدونة Anthropic تربطه بـ "multipath TCP listener"؛ لا يذكر أي نص من CVE/NVD/Red Hat/Debian/Ubuntu MPTCP. يختبر المسبار TCP العادي أولًا.
ثلاثة مسارات مستقلة، من الأضعف إلى الأقوى:
| المحور | ما يوضحه | المخرجات |
|---|---|---|
| ثابت (مثبّت بـ build-id) | شكل شيفرة النواة قيد التشغيل: kfree عادي عند كلا المدمّرين = مصاب؛ kvfree_call_rcu = مُرقّع | verify-local، الجدول أدناه |
| أوراكل اصطناعي | ينطلق كاشف الشبكة عندما يعيد المستجيب صدى ذاكرة slab معاد استخدامها | scripts/validate_synthetic.sh → CONFIRMED VULNERABLE |
| ديناميكي، على مستوى النواة (مختبر KVM) | تُبلّغ KASAN عن slab-use-after-free الفعلي في ip_options_build، مع مكدّسات الـ commit؛ نواة kfree_rcu بحركة مرور مطابقة تبقى نظيفة | evidence/guest-inst-vuln6-KASAN.log، evidence/guest-inst-patched2-CONTROL.log |
| مرئي على الشبكة، نواة حقيقية (مختبر غير KASAN) | حمل SYN-ACK على الشبكة كتلة الخيارات المرشوشة (42 04 be ef…) بدلاً من الطابع الزمني المُعاد؛ بقي عنصر التحكم kfree_rcu نظيفاً | evidence/race-stage1-wire-uaf.json، evidence/race-control-kfree_rcu.json |
المحور الديناميكي هو ضيف 7.0.14 مُصمَّم لغرض محدد (KASAN + تمديد نافذة
بمعامل إقلاع) مع توجيه CPU لكل حزمة: تتم معالجة SYN المُعاد إرساله
على vCPU واحد، وACK/النقل على ثانٍ، وaccept()+close() الخاص بالضحية
على ثالث، بحيث يصبح التجاوز روتينياً بدلاً من
عرضي. وقد أبلغت النواة نفسها:
BUG: KASAN: slab-use-after-free in ip_options_build
Read of size 16 ... by task swapper/0 (cpu0, softirq)
__asan_memcpy <- ip_options_build <- ip_build_and_send_pkt
<- tcp_v4_send_synack <- tcp_rtx_synack <- tcp_check_req <- tcp_v4_rcv
Freed by task 1 (victim, cpu3):
kfree <- inet_sock_destruct <- __sk_destruct <- inet_release <- __x64_sys_close
object: kmalloc-96, 16 bytes in (struct ip_options at the rcu_head offset)
بالإضافة إلى 30 سجل READ-AFTER-FREE من جانب القارئ (قُرئ بعد 71–322 ميكروثانية من التحرير، optlen=40، ظل KASAN 0xfb). شغّل عنصر التحكم المُرقَّع (kfree_rcu، الذي تم التحقق منه في ملف الكائن) نفس السباق والفترة الزمنية: 0 KASAN، 0 قراءة بعد التحرير. هذا هو الثغرة، وليس تخمينًا لإصدار.
القارئ ليس حلقة طويلة. يقوم tcp_v4_send_synack() بتحميل ireq->ireq_opt ويمرره إلى ip_build_and_send_pkt()/ip_options_build()، حيث يُعدّ memcpy الخاص به هو قراءة الاستخدام بعد التحرير؛ التحميل والقراءة يفصلهما بضع تعليمات (عشرات إلى مئات النانوثانية). أما جانب التحرير — تدمير العنصر التابع بعد accept()+close() الخاص بالضحية — فهو أبعد بكثير: دورة الإغلاق المقاسة وحدها تبلغ 61–92 ميكروثانية، وتضيف زمن وصول ACK→التدمير إيقاظًا عبر المعالجات.
لذا فإن الحدثين ليسا نادرين معًا فحسب؛ بل يفصلهما ~90 ميكروثانية بحكم البنية، وتنتهي القراءة قبل التحرير بوقت طويل. تُحدّد تجربة التوقيت الطبيعي ذلك كميًا: مع النواة المزوّدة بأدوات القياس نفسها، دون تمديد النافذة، وحوالي 140 ألف محاولة سباق وتدافع متزامن للاتصالات نصف المفتوحة،
stats: frees=180223 overlaps=0 raf=0 KASAN: 0
لم يهبط النطاق الحر ولو مرة واحدة داخل نافذة القارئ. استخدمت محاولة ثانية أقوى رشّ الألواح الخاص بالمختبر: 8,000 محاولة تحمل كل منها 200 حزمة SYN معاد إرسالها (1.6 مليون نافذة قارئ مستقلة) ضد نواة نقية أُبقيت فيها vCPU الخاصة بالقارئ قابلة للتشغيل ومستبقة بواسطة عمليات CFS المضيفة المزدحمة - ومع ذلك ظل عدد حزم SYN-ACK التي تحمل الرشّ صفرًا. تُستبق vCPU الخاصة بالقارئ نحو مرة كل 5 مللي ثانية من زمن التشغيل؛ و2 مليون نافذة بمدة ~10 نانوثانية مقابل 20-40 ثانية من زمن التشغيل تعني حفنة من الإصابات حتى في ظل نموذج موحّد تمامًا، والصفر الملاحظ يعني أن نقاط الاستباق ليست موحّدة في تدفق تعليمات الضيف.
لذلك يحتاج الإثبات على مستوى الشبكة إلى تأخير القارئ بشكل حتمي، وهو ما يفعله المختبر عبر تمديد نافذة بمعامل إقلاع (reader_hold_us)؛ أما على هدف حقيقي فلا يمكن لأي شيء سوى تعطّل في الهايبرفايزر أو المجدول داخل تلك الـ ~10 نانوثانية أن يحقق ذلك. لهذا السبب يعامل المسبار البعيد النتيجة الإيجابية كإثبات والنتيجة السلبية كحدّ أعلى، وليس أبدًا كـ "مُرقَّع".
وثمة نتيجة أخرى: على نواة KASAN يُبقي الحجر الصحي البايتات المحرَّرة سليمة، لذا لا يمكن لـ الشبكة أن تُظهر UAF حتى عندما يحدث. أما على نواة إنتاجية فإن أوراكل الشبكة لا ينطلق إلا عندما يُعاد استخدام خانة kmalloc-96 المحرَّرة قبل memcpy الخاص بالقارئ. ولم يعد هذا المسار اصطناعيًا فحسب: في نواة المختبر غير المزوّدة بـ KASAN (بلا حجر صحي) أغلق الضحية العملية الفرعية وأعاد تخصيص الخانة فورًا بكائنات خيارات بحجم 40 بايت، فنسختها النواة إلى SYN-ACK (42 04 be ef…، evidence/race-stage1-wire-uaf.json). أما النواة نفسها مع kfree_rcu فلم تُنتج شيئًا (evidence/race-control-kfree_rcu.json).