CVE-2026-98432: دالة واحدة استُبدلت بأخرى مرتين، ولماذا تعطيل MPTCP لا يُعدّ إصلاحاً

دالة واحدة استُبدلت بأخرى مرتين، وتقييم CVSS يبلغ 9.8

قبل: kfree(). بعد: kfree_rcu(). هذا هو كامل الإصلاح لثغرة CVE-2026-98432، مكرر في دالتين مختلفتين في ملفين مختلفين. إذا قرأت تقييم CVSS أولاً، تبدو الثغرة مجردة: 9.8، حرجة، بلا صلاحيات، بلا تفاعل من المستخدم. إذا قرأت الفرق (diff) أولاً، يتبخر التجريد. الثغرة هي اسم دالة واحد، استُبدل بالاسم الخاطئ، في موضعين فقط بالضبط.

ثغرة CVE-2026-98432 هي use-after-free في كيفية تعامل مكدّس IPv4 TCP في نواة لينكس مع خيارات IP لاتصال ما، موجودة منذ التزام (commit) من عام 2015، وأُصلحت الآن في كل فرع مستقر مدعوم.[1] قيّمها فريق CNA الخاص بـNVD بـ9.8، AV:N/AC:L/PR:N/UI:N: عن بُعد، تعقيد منخفض، بلا صلاحيات، بلا تفاعل من المستخدم. بعد ثلاثة أسابيع من الإفصاح، لا تزال نشرة Red Hat نفسها لا تُسمّي أي نسخة مُصلَحة، ولا يزال متتبّع Ubuntu نفسه يُصنّف كل إصدار مدعوم على أنه معرّض للخطر أو قيد العمل.[2][3] ويُقال إن نموذج بحث غير منشور من Anthropic حوّل هذه الثغرة إلى مسار zero-click فعّال نحو root في أقل من ساعة.[4] مزيد عن هذا الادعاء في ما يلي، بعناية، لأن تفصيلاً واحداً مرتبطاً به على الإنترنت ليس في الحقيقة ما قالته Anthropic.

قرأت التزام الإصلاح بنفسي، لا نسخة مُعاد صياغتها عنه. أعاد git.kernel.org استجابة HTTP 403 لطلب مباشر، فقرأت نفس الالتزام تماماً، عبر قيمة التجزئة (hash)، من المرآة العامة لشجرة الإصدار المستقر التي يحتفظ بها Greg Kroah-Hartman على GitHub.[5] لم أُعِد إنتاج هذا في مختبر. هذا المقال مبنيّ على قراءة المصادر الأساسية من أولها إلى آخرها، لا على تشغيل استغلال فعلي، وهذا الفرق مهم لكل ما يلي.

// The actual kfree -> kfree_rcu swap, per the fixing commit (dossier
// S2). Surrounding code is an illustrative reconstruction of shape, not
// a literal excerpt.

net/ipv4/af_inet.c, inet_sock_destruct():
-   kfree(opt)
+   kfree_rcu(opt, rcu)

net/ipv4/tcp_ipv4.c, tcp_v4_reqsk_destructor():
-   kfree(opt)
+   kfree_rcu(opt, rcu)

ما الذي يُفترض أن يمنحك «التحرير لاحقاً»

هذه هي القاعدة الثابتة التي يعتمد عليها كثير من كود الشبكة في النواة دون تفكير مضاعف: القارئ داخل rcu_read_lock() يفترض أن الذاكرة التي ينظر إليها لا تزال موجودة، لأن العُرف هو أن الكاتبين يؤجّلون التحرير الفعلي إلى أن يكون كل قارئ قد انتهى فعلاً. هذا هو RCU، أي read-copy-update، وهو إجابة النواة عن مسألة صعبة: كيف تسمح للقراء بالعمل بسرعة وبلا أقفال، بينما يظل الكاتبون قادرين على حذف الأشياء، دون أن يلمس أي قارئ ذاكرة أصبحت بالفعل غائبة؟

يمكن لمقبس طلب TCP (request socket) — وهو كائن النواة الذي يمثّل اتصالاً نصف مفتوح أثناء المصافحة — أن يحمل خيارات IP: بيانات يتحكم بها المهاجم أو الشبكة، مرفقة برأس IP لحزمة SYN. تُخزّن النواة هذه الخيارات خلف مؤشر (ireq_opt في request socket، وinet_opt بعد ترقيته إلى مقبس كامل) وتقرأها لاحقاً، عند بناء SYN-ACK أو ACK، داخل ip_options_build(). تلك القراءة تحدث تحت RCU. ويجب أن تكون كذلك: فمعالج مركزي ثانٍ يعالج SYN أُعيد إرساله لنفس الاتصال يمكن أن يكون شرعياً داخل تلك الدالة في اللحظة نفسها التي يُفكّك فيها معالج آخر الاتصال.[1][5]

مُدمِّران، اختصار واحد، صفر فترة سماح

موضعان في الكود خالفا العقد الذي يعتمد عليه RCU: inet_sock_destruct() في net/ipv4/af_inet.c، وtcp_v4_reqsk_destructor() في net/ipv4/tcp_ipv4.c — كلاهما حرّر نفس مؤشر خيارات IP باستخدام kfree() عادية، فوراً، بدل kfree_rcu() المؤجلة عبر RCU.[5] تجعل kfree() العادية الذاكرة متاحة لإعادة الاستخدام في اللحظة نفسها التي تُستدعى فيها: بلا فترة سماح، بلا انتظار لانتهاء القراء. أي معالج مركزي لا يزال داخل ip_options_build()، يقرأ المؤشر الذي حرّره المُدمِّر للتو، يقرأ الآن ذاكرة يمكن إعادة تخصيصها وكتابتها من تحته.

استخدم جانب القراءة RCU: رخيص، بلا أقفال، ويتحمّل التحرير المتزامن ما دام ذلك التحرير مؤجلاً. موضعان على جانب الكتابة لم يلتزما بجانبهما من هذا الاتفاق. هذا التعارض هو تماماً نوع الثغرة التي لن يراها أبداً WAF، أو فحص مصادقة، أو أي ضابط على مستوى التطبيق، لأنها تعيش بالكامل داخل إدارة الذاكرة الخاصة بالنواة نفسها، على عمق استدعاءين لدالتين من سطر واحد في مسار مُدمِّر.

// Illustrative timeline of the SYN-retransmit race (one of two trigger
// paths), reconstructed from the fixing commit's own description -- not
// a captured trace, and not exploit code.

CPU A (processing the connection)        CPU B (retransmitted SYN)
----------------------------------      ----------------------------------
child socket created, inherits the
ireq_opt pointer -- not copied
tcp_v4_reqsk_destructor() runs:
  kfree(ireq_opt)   <-- freed now,
  no grace period
                                          still inside rcu_read_lock(),
                                          ip_options_build() dereferences
                                          the same pointer -- already
                                          freed, possibly reused

الـSYN الذي تعيد إرساله، أو مقبس الطلب الذي تُرحّله

يصف التزام الإصلاح طريقتين تماماً للوصول إلى داخل تلك النافذة، ولا تحتاج أي منهما إلى شيء غير عادي. الأولى: تُسلّم tcp_v4_syn_recv_sock() خيارات IP لمقبس الطلب إلى المقبس الفرعي الجديد دون نسخها أولاً، فيستطيع معالج مركزي ثانٍ لا يزال يعالج SYN أُعيد إرساله — سلوك TCP عادي — قراءة تلك الخيارات بعد تحريرها بالفعل.[1][5] تحدث عمليات إعادة إرسال SYN باستمرار في الشبكات الحقيقية، فلا يحتاج المهاجم إلى افتراع هذا الشرط. يحتاج فقط إلى توقيته بدقة.

يحتاج المسار الثاني إلى أمر إضافي واحد: تفعيل ترحيل مقبس الطلب في TCP صريحاً، إما عبر net.ipv4.tcp_migrate_req=1 أو برنامج BPF مرفق يستخدم SK_REUSEPORT_SELECT_OR_MIGRATE.[5] وهذا ليس الإعداد الافتراضي في أي مكان. وعندما يكون مفعّلاً، يشارك مقبس الطلب المُستنسخ نفس مؤشر الخيارات مع الأصلي، ويحرّره نفس المُدمِّر من تحت أيٍّ منهما ما زال يستخدمه. إذا كنت تُشغّل مكدّساً مختلطاً من IPv4 وIPv6، فهناك تفصيل مهم هنا: يذكر التزام الإصلاح أن IPv6 غير متأثر بسباق إعادة الإرسال، لأن IPv6 يُكرّر خيارات مقبس الطلب بدل مشاركتها. وتُؤجَّل مشكلة ترحيل مرتبطة بـIPv6 إلى تصحيح منفصل.[1][5] هذا الإصلاح يخص IPv4 فقط.

ثمانٍ وأربعون دقيقة إلى مؤشر، وخمس دقائق أخرى إلى root

هذا هو الجزء من هذه القصة الذي انتشر فعلاً، ويستحق أن يُروى بدقة. ينص منشور بحث Anthropic نفسه، الموقّع باسم فريق Frontier Red Team، على أن نموذجاً بحثياً داخلياً غير منشور وجد ودمج ثغرات في استغلال عن بُعد وzero-click ضد خوادم لينكس تُشغّل مستمع multipath TCP: بلا بيانات اعتماد، بلا تفاعل من المستخدم، صلاحيات root عبر الشبكة.[4][6][7] يذكر المنشور CVE-2026-98432 باسمها الرقمي. بكلمات Anthropic نفسها: استغرق تسريب مؤشر النواة 48 دقيقة، وخمس دقائق أخرى بعد ذلك للوصول إلى تنفيذ أوامر الصدفة (shell).[4]

تفصيل واحد يتردد مع هذا الادعاء على الإنترنت ليس موجوداً فيه فعلاً. الاسم الرمزي «Project Glasswing» لا يظهر في أي مكان في منشور Anthropic. يعود مصدره إلى خيط ثانوي غير مُتحقَّق منه، لا إلى كلام Anthropic نفسها، ولن أكرره هنا كما لو أن Anthropic أكدت اسماً لم تستخدمه قط. ما هو مؤكَّد بشكل مستقل: جهتان إعلاميتان ثانويتان تنشران نفس رقم CVE، ونفس تقييم CVSS، ونفس التوقيت — 48 دقيقة وخمس دقائق — وكلاهما يُحيل إلى منشور Anthropic نفسه كمصدر.[6][7] تضيف إحداهما جملة تستحق التوقف عندها قبل الفقرة التالية: «السجل العام لهذه الثغرة يصف إصلاحاً لـIPv4 TCP لا لـmultipath TCP، والربط بينهما يأتي فقط من منشور Anthropic».[7]

نشرة Red Hat لا تذكر MPTCP أبداً. ولا يذكرها الإصلاح أيضاً.

هذه الجملة هي خلاصة القصة كلها، وهي حيث تُخطئ معظم النصائح المتداولة. اقرأ التزام الإصلاح الخاص بالنواة نفسه، فهو يصف مساري تحفيز بعبارات IPv4 TCP عادية تماماً: إعادة إرسال SYN وترحيل مقبس الطلب، دون أي ذكر لـMultipath TCP على الإطلاق.[1][5] اقرأ نشرة Red Hat نفسها، RHSB-2026-016، فهي نفس الشيء: «الأنظمة التي تقبل اتصالات TCP الواردة» بوصفها الفئة المعرّضة، ووصف عام لحالة السباق، بلا MPTCP في الشرط المسبق، أو ناقل الهجوم، أو توصيات التخفيف.[2] مصدران أساسيان. لا يذكر أيٌّ منهما الشيء الذي ينصح نصف الإنترنت بتعطيله.

هذه قراءتي الخاصة لهذين المصدرين جنباً إلى جنب، لا جملة ينص عليها أيٌّ منهما صريحاً، فسأقولها بوضوح: مستمع MPTCP هو طريقة واحدة للوصول إلى هذه الثغرة بشكل موثوق. إنه ليس الشرط المسبق المحدِّد للثغرة. وإذا كان استغلال مُثبَت بعينه استخدم MPTCP كنقطة دخول مختارة — وهذا، بحسب القسم السابق، تفصيل معقول لكنه غير مؤكَّد بعد عن استغلال واحد مزعوم — فإن ذلك يخبرك عن مسار عملي واحد للفوز بالسباق، لا عن ما تتطلبه الثغرة نفسها فعلاً.[4][7] تعطيل MPTCP (net.mptcp.enabled=0) يُزيل ذلك النوع المحدد من المستمعات كسطح تحفيز. لكنه لا يلمس use-after-free الأساسية، التي تبقى قابلة للوصول بالكامل عبر معالجة TCP العادية غير المرتبطة بـMPTCP.

// What the vulnerability actually requires (b), versus what one
// reported demonstration used (c). Don't let (c) stand in for (b).

(b) Real preconditions, per the kernel's own commit and Red Hat's
    advisory -- neither names MPTCP:
      - A listener processing IPv4 TCP SYNs and retransmitted SYNs
        (ordinary behavior, any TCP listener), OR
      - Request-socket migration explicitly enabled
        (net.ipv4.tcp_migrate_req=1, or a BPF
        SK_REUSEPORT_SELECT_OR_MIGRATE program) -- not the default.
      - Precise timing to win the race window.
      - No credentials, no user interaction (PR:N/UI:N).

(c) What one reported demonstration reportedly used to trigger it
    reliably:
      - A reachable multipath TCP (MPTCP) listener.

Disabling MPTCP removes (c). It leaves (b) exactly where it was.

أُصلحت في النواة. ولم تُصلح بعد في النواة التي يُشغّلها معظم الناس

الإصلاح الأساسي موجود، ومؤرَّخ بدقة: الفروع المستقرة خالية من الثغرة بدءاً من 5.10.272 و5.15.223 و6.1.190 و6.6.159 و6.12.113 و6.18.56، مع 7.2.10 والإصلاح الأصلي الموسوم لإصدار mainline 7.3 — وكل ذلك يطابق بيانات NVD الخاصة بالمورّد بدقة.[1] هذا هو الجزء السهل من هذه القصة. أما مطابقة النواة التي تعمل عليها حِمل عملك الفعلي لأحد هذه الأرقام، فهذا الجزء الذي يحتاج فحصاً، لا افتراضاً.

تُصنِّف نشرة Red Hat نفسها، التي آخر تحديث لها كان في 2026-10-30، هذه الثغرة بأنها «تأثير حرج»، لكنها لا تُسمّي أي نسخة مُصلَحة، أو نشرة تصحيحات، أو أي تقييم CVSS على الإطلاق. تذكر فقط أن Red Hat «تُسرّع إصدار الإصلاحات».[2] يُصنّف متتبّع Ubuntu نفسه، في وقت كتابة هذا المقال، كل إصدار مدعوم من 16.04 إلى 26.10 على أنه Vulnerable أو Vulnerable، قيد العمل. فقط 14.04، الذي خرج فعلاً من الدعم القياسي، مُصنَّف خالياً من الثغرة.[3] تخفيف Red Hat المؤقت، إن كنت تنتظر نسخة مُصلَحة: قاعدة nftables تُسقط حزم IPv4 TCP الواردة التي يحمل رأس IP فيها خيارات، وهي لا تلمس خيارات طبقة TCP العادية، وتُذكر صراحة بأنها ليست بديلاً عن التصحيح.[2]

رقم آخر مهم هنا، لأن العناوين تميل بشدة إلى التحذير العاجل: في وقت كتابة هذا المقال، لا تظهر CVE-2026-98432 في فهرس CISA للثغرات المُستغَلّة المعروفة — تم التحقق من ذلك بطريقتين مستقلتين — ولا يُوثّق أي مصدر رُوجع هنا استغلالاً مؤكَّداً في الواقع.[8][9] هذا ليس نفس القول بأنه «يمكن تأجيل الاهتمام به». فتقييم 9.8 دون مصادقة ودون تفاعل من المستخدم يكتسب إلحاحاً حقيقياً بذاته. هذا هو الميزان الصادق: حرجة وغير مُصلَحة في معظم التوزيعات، لكنها غير مؤكَّدة كهدف لهجوم نشط.

Unaffected starting at (NVD vendor data, matches the kernel's own
per-branch fixes exactly):
  5.10.272   5.15.223   6.1.190   6.6.159
  6.12.113   6.18.56    7.2.10    (original fix tagged for mainline 7.3)

Distro status, read from each vendor's own tracker as of this writing:
  Red Hat (RHSB-2026-016):  Critical impact. No fixed version or
                             errata named. "Expediting the release
                             of fixes." Last updated 2026-10-30.
  Ubuntu (security tracker): every supported release, 16.04-26.10,
                             Vulnerable or Vulnerable, work in
                             progress. Only 14.04 (out of support)
                             is clear.

ما المؤكَّد، وما هو مجرد ادعاء على الإنترنت حتى الآن

يتردد أمران آخران حول هذه الثغرة، ولن أحسم أيّاً منهما، لأن السجل المتاح لا يسمح بذلك. تقول رواية واحدة أن Red Hat قيّمت هذه الثغرة في البداية بـ5.9، ثم 8.1، ثم 9.8، مع ربط التصعيد جزئياً بإفصاح Anthropic عن توقيت الاستغلال. لكن نشرة Red Hat الحالية لا تُظهر أي تقييم، أو ناقل، أو أي سجل تقييمات على الإطلاق، فهذه القصة المحدّدة من 5.9 إلى 8.1 إلى 9.8 لا تُؤكَّد ولا تُنفى بالمصدر الأساسي الوحيد المتاح للتحقق منها.[2]

والأمر الآخر هو ما إذا كان إثبات مفهوم (PoC) فعّال للاستغلال منشوراً فعلاً. يزعم خيط واحد أن نسخاً من PoC موجودة على GitHub منذ 2026-10-29؛ وتقول روايات أخرى إن الاستغلال لم يُنشر أبداً. لم أعثر على أي مستودع PoC فعّال ولم أتحقق منه في أي من الاتجاهين. إن أخبرك أحد بثقة أيّ من هذين صحيح، فاطلب منه المستودع نفسه، لا مجرد الادعاء.

ما يجب فحصه فعلاً هذا الأسبوع

بالترتيب الذي يهم فعلاً، لا الترتيب الذي يصنع أفضل عنوان.

Patch and verify, in order:
  [ ] Confirm the kernel actually RUNNING, not the changelog: 5.10.272 /
      5.15.223 / 6.1.190 / 6.6.159 / 6.12.113 / 6.18.56 / 7.2.10 or later.
  [ ] If your distro hasn't shipped a fixed build yet, check its own
      tracker directly -- don't trust a blog post's snapshot of it,
      this one included. Apply Red Hat's interim nftables rule in the
      meantime: drop inbound IPv4 TCP with IP header length > 5.
  [ ] Check net.ipv4.tcp_migrate_req. If it's 1, or a BPF
      SK_REUSEPORT_SELECT_OR_MIGRATE program is attached, the second
      trigger path is open regardless of MPTCP.
  [ ] Disable MPTCP if you want to (net.mptcp.enabled=0) -- a
      reasonable attack-surface reduction, but record it as exactly
      that, not as the fix for this CVE.
  [ ] Don't use CISA's KEV list as a signal of how exposed you are
      here. As of this writing this CVE isn't on it, and that's a
      statement about confirmed in-the-wild use, not about your risk.

قالت النشرة «use-after-free». وقال الفرق (diff) أين بالضبط

تكرر كل نشرة عن هذه الثغرة الكلمات الثلاث نفسها: use-after-free، نواة، IPv4. لا تخبرك أيٌّ منها بمفردها أن الخطأ الفعلي كان اختيار kfree() بدل kfree_rcu() في مُدمِّرين، أو أن نصيحة MPTCP المتداولة تُعامل الباب الذي اختاره استغلال واحد كما لو كان الباب الوحيد في المبنى. الفرق (diff) هو ما أخبرني بذلك. النشرة لم تفعل، ولم تكن تحاول: فهذا ليس الغرض من النشرة أساساً.

هذه بالضبط الثغرة التي أبحث عنها في مراجعة كود أمنية: ليس هل يقول سجل التغييرات «تم الإصلاح»، بل هل يعالج الفرق الفعلي السبب الجذري أم فقط المسار الواحد الذي صادف أن وجده أحدهم أولاً. إذا كنت تُصيّن كوداً بلغة C أو C++ يتضمّن نفس نمط الملكية المشتركة وتأجيل انتهاء الصلاحية — عبر RCU أو غيره — وتريد من شخص أن يقرأ مسارات المُدمِّرين وهذا السؤال في ذهنه، فهذا تماماً نوع المراجعة التي أقوم بها. أخبرني بما تُشغّله، وسنحدد نطاق العمل.