تخفيف مؤقت لـ CVE-2026-98432 على Ubuntu وDebian

سكربت واحد عديم الأثر الجانبي (idempotent) يُسقط حزم TCP الواردة من IPv4 التي تحمل خيارات IP، ويحافظ على القاعدة عبر عمليات إعادة التشغيل، ويتحقق من أنها تعمل. وهو مخصص لخوادم Ubuntu (18.04 – 24.04) وDebian (11 – 13) التي لا يمكنها الحصول على نواة مُصحّحة بعد.

هذا حل مؤقت، وليس إصلاحًا. الإصلاح الحقيقي الوحيد هو نواة مُرقّعة مع إعادة تشغيل. أزل هذا التخفيف بمجرد أن يعمل الخادم بنواة مُصحّحة.

الاستخدام

curl -fsSL https://raw.githubusercontent.com/Mervent/cve-2026-98432/master/install.sh | sudo sh

يمكنك تشغيله أي عدد من المرات: تُستبدل الملفات ولا تتكرر القاعدة أبدًا. في النهاية يتحقق السكربت من النتيجة ويخرج بقيمة غير صفرية عند أي فشل:

--- validation ---
OK    helper installed: /usr/local/sbin/cve-2026-98432-mitigation
OK    cron entry: /etc/cron.d/cve-2026-98432
OK    cron service enabled
OK    iptables rule active (raw/PREROUTING)
OK    exactly one rule (no duplicates)
      plain SYN: connected, SYN with IP options: timeout
OK    drop test: packets with IP options are dropped
--- rule counters ---
 pkts bytes target     prot opt in     out     source               destination
    3   204 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            u32 "0x0>>0x18&0xf=0x6:0xf" /* cve-2026-98432 */

ما الذي يقوم بتثبيته

المسار	الغرض
/usr/local/sbin/cve-2026-98432-mitigation	أداة مساعدة تحتفظ بالقاعدة. عند عدم تمرير أي وسيط تُضيف القاعدة إن كانت مفقودة. --check يُرجع رمز الخروج 0 إذا كانت القاعدة نشطة. --remove يحذفها.
/etc/cron.d/cve-2026-98432	إدخال @reboot يعيد تطبيق القاعدة بعد كل إقلاع

القاعدة نفسها:

iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" \
    -m comment --comment cve-2026-98432 -j DROP

التحقق بعد إعادة التشغيل

sudo /usr/local/sbin/cve-2026-98432-mitigation --check && echo active
sudo iptables -t raw -L PREROUTING -v -n | grep cve-2026-98432

الإزالة بعد الإقلاع إلى نواة ثابتة

sudo /usr/local/sbin/cve-2026-98432-mitigation --remove
sudo rm /usr/local/sbin/cve-2026-98432-mitigation /etc/cron.d/cve-2026-98432

لمعرفة ما إذا كانت توزيعتك قد أصدرت إصلاحًا، تحقق من Ubuntu أو Debian (بالنسبة إلى Debian 9 – 11، راجع متتبع Freexian ELTS). بمجرد أن يُظهر إصدارك حالة "Fixed"، شغّل apt update && apt full-upgrade، ثم أعد التشغيل، ثم أزل التخفيف.

اعتبارًا من 1 نوفمبر 2026، أصبح لدى Debian 12 (linux 6.1.190-1، DLA-4841-1) وDebian 13 (linux 6.12.113-1، DSA-6568-1) نوى مُصلحة بالفعل، لذا على هذين الإصدارين قم بالترقية بدلًا من استخدام هذا السكربت. إصلاح Debian 11 (linux 5.10.272-1، ELA-1846-1) موجود فقط في مستودع ELTS الخاص بـ Freexian: تجاري، لكنه مجاني عند الطلب للأفراد والمنظمات غير الربحية الصغيرة.

المبررات

الثغرة الأمنية

CVE-2026-98432 ("ipv4: free inet_opt and ireq_opt after an RCU grace period") هي ثغرة استخدام بعد التحرير (use-after-free) في مصافحة TCP الخاصة بـ IPv4. تؤثر على Linux 4.4 وما بعده وتصنَّف بتقييم CVSS 9.8.

إذا كانت حزمة SYN تحمل خيارات IPv4، يحفظها النواة على مقبس الطلب (request socket) حتى يتمكن من إعادتها في SYN-ACK. بعد ذلك يسلّم tcp_v4_syn_recv_sock() هذا المخزن المؤقت إلى المقبس الابن دون نسخه. عندما يموت المقبس الابن، يُحرَّر المخزن المؤقت باستخدام kfree() عادي، بينما قد يكون معالج آخر لا يزال يقرأه لبناء SYN-ACK لحزمة SYN مُعاد إرسالها.

كل هذا يحدث في النواة قبل أن ترى أي تطبيق الاتصال. أي منفذ TCP يستمع على IPv4 يمكن الوصول إليه بهذه الطريقة (SSH، HTTP، PostgreSQL وغيرها)، ولا حاجة إلى أي بيانات اعتماد. أبلغت Anthropic عن استغلال عملي للوصول إلى صلاحيات الجذر عن بُعد ضد مضيفين لديهم مستمع متعدد المسارات TCP (MPTCP). يشير فريق أمان Go إلى أن الخطأ ليس خاصًا بـ MPTCP.

لماذا إسقاط حزم TCP التي تحمل خيارات IP

الذاكرة التي تُحرَّر مبكرًا جدًا لا توجد إلا عندما تحمل حزمة SYN الواردة خيارات IPv4. فبدون خيارات لا يوجد مخزن مؤقت محفوظ، وبالتالي لا يوجد ما يمكن أن تؤثر عليه ثغرة الاستخدام بعد التحرير. حركة TCP الشرعية لا تحمل عمليًا خيارات IPv4 أبدًا، لذا فإن إسقاط تلك الحزم لا يكلف شيئًا في الممارسة. تنشر Red Hat (RHSB-2026-016) وAlmaLinux قاعدة nftables مكافئة.

يقرأ u32 "0>>24&0xF=6:15" حقل IHL، وهو طول ترويسة IPv4 بوحدات الكلمات ذات 32 بت. القيمة 5 تعني الترويسة المجردة ذات 20 بايت. القيم من 6 إلى 15 تعني وجود خيارات.

تذكر Red Hat أن مثل هذه القاعدة "تقلل التعرض لهذه الثغرة لكنها لا تستطيع منعها بالكامل". تعامل معها على أنها تقليل للمخاطر حتى يتم ترقيع النواة.

لماذا raw / PREROUTING

• يرى PREROUTING كل حزمة واردة، سواء كانت حركة موجهة إلى المضيف أو حركة مُمرَّرة إلى حاويات Docker على منافذ منشورة. أما قاعدة في INPUT، وهو المكان الذي تضع فيه ufw قواعدها، فستفوّت الحركة المُمرَّرة.
• يعمل جدول raw قبل تتبع الاتصالات، لذا فإن الحزم المُسقطة لا تنشئ أبدًا إدخالات conntrack.
• لا تقوم ufw وDocker بتفريغ raw/PREROUTING، لذا تبقى القاعدة بعد إعادة تشغيلهما.

لماذا iptables وليس nftables

• iptables موجود في كل إصدار Ubuntu مستهدف. على Ubuntu 18.04 و20.04 يستخدم الواجهة الخلفية القديمة (legacy)؛ ومن Ubuntu 22.04 وما بعده وعلى Debian 11+ فهو iptables-nft. أما ملف nft التنفيذي فليس مثبتًا افتراضيًا في كل مكان. على Debian، قد يكون iptables نفسه مفقودًا؛ حينها يطلب منك السكربت تشغيل apt install iptables.
• مع iptables-nft، تتشارك ufw/Docker وهذه القاعدة الواجهة الخلفية nf_tables، لذا تغطي قاعدة واحدة كليهما.
• يحتاج مطابق u32 إلى وحدة النواة xt_u32. إذا كانت مفقودة، يفشل السكربت ويخبرك بفحص modinfo xt_u32.

لماذا إدخال cron من نوع @reboot

• ليس nftables.service. على Ubuntu يبدأ /etc/nftables.conf بـ flush ruleset، كما أن الخدمة تُشغّل nft flush ruleset عند الإيقاف. أيٌّ منهما يمسح قواعد ufw وDocker.
• ليس iptables-persistent. يقوم netfilter-persistent save بتفريغ كل قاعدة حالية، بما فيها قواعد Docker، واستعادة تلك اللقطة عند الإقلاع تتعارض مع القواعد التي ينشئها Docker بنفسه.
• ليس ufw before.rules. فهو يعمل فقط عندما يكون ufw مُفعَّلًا، وسلاسله لا ترى حركة المرور المُمرَّرة إلى الحاويات.
• cron.d. فهو مثبَّت على خوادم Ubuntu وDebian القياسية (يتحقق السكربت من وجوده)، والملف في /etc/cron.d عديم الأثر الجانبي بفضل الكتابة فوقه، وإزالته أمر rm واحد. المقايضة هي نافذة من بضع ثوانٍ بعد الإقلاع تكون فيها الشبكة متاحة لكن cron لم يطبّق القاعدة بعد. وهذا مقبول لتخفيف لا يحتاج إلا أن يستمر حتى تحديث النواة التالي.

لماذا لا يكفي net.mptcp.enabled=0 فقط

تعطيل MPTCP يزيل الشرط المسبق للثغرة المنشورة الوحيدة، لا الخلل نفسه. فمستمعو TCP العاديون لا يزالون يمرون عبر الكود المصاب نفسه. وعلى خادم بلا مستمعي MPTCP (ss -Mlnp لا يطبع شيئًا) لا يغيّر sysctl شيئًا على الإطلاق. فهو إضافة غير ضارة، وليس بديلًا عن هذه القاعدة.

التحقق

يتحقق السكربت من تثبيت المساعد ومدخل cron، ومن تفعيل cron، ومن وجود قاعدة واحدة نشطة بالضبط. ثم يُجري اختبار إسقاط شامل باستخدام python3، يُتخطّى إذا كان python3 غير موجود:

1. يفتح مستمعًا على 127.0.0.1.
2. يتصل مرة واحدة دون خيارات IP؛ يجب أن ينجح هذا الاتصال.
3. يتصل مرة واحدة مع خيار IP من نوع Record Route؛ يجب أن ينتهي هذا الاتصال بمهلة.

تمر حركة المرور عبر loopback من raw/PREROUTING، لذا يُثبت هذا أن القاعدة تُسقط الحزم فعلًا وليست مجرد موجودة في الجدول.

القيود

• لا يُصلح خلل النواة. تُصرّح Red Hat بأن تصفية خيارات IP "لا يمكنها منع" الاستغلال "منعًا كاملًا".
• قد تفوتها حركة المرور بين الحاويات على جسر المضيف نفسه. تُحذّر AlmaLinux من أن هذه الحركة "قد تتجاوز" هذا النوع من التصفية.
• تُعطّل تسميات أمان CIPSO، التي تنتقل في خيارات IPv4. لا تستخدمها على الشبكات التي تعتمد عليها.
• توجد نافذة من بضع ثوانٍ بعد الإقلاع قبل أن يطبّق cron القاعدة.
• لا يُمسّ IPv6. فالخلل الرئيسي خاص بـ IPv4 فقط.

ما تم اختباره