한국어

تخفيف مؤقت لـ CVE-2026-98432

يحتوي هذا المستودع على سكربتات تُسقط حزم IPv4 TCP التي تحمل خيارات IP على مضيف Linux. على المضيفات التي لا تحتوي على وسم CIPSO عبر SELinux/Smack NetLabel، لا يمكن لـ CVE-2026-98432 (استخدام-بعد-تحرير في IPv4 TCP في نواة Linux) أن يُستغَل دون وجود مثل هذه الحزم. هذا تخفيف مؤقت وليس إصلاحًا. لم يُختبر ضد استغلال حقيقي (لا يوجد PoC عام)، ولا تؤيده أي جهة مصنّعة. إذا كانت توزيعتك تُوفّر بالفعل نواة مُصلحة، فثبّتها، وشغّل revert.sh إذا كنت قد طبّقت هذا. وإذا لم تكن كذلك، فتحقق من أن التخفيف ينطبق على مضيفك، ثم طبّقه وتحقق منه بالخطوات التالية (حوالي 10 دقائق). المؤلف مسؤول فردي وليس جهة مصنّعة.

هل ينطبق هذا عليك

1. قارن uname -r مع الإصدارات المستقرة المُصلحة: 5.10.272، 5.15.223، 6.1.190، 6.6.159، 6.12.113، 6.18.56، 7.2.10، 7.3 (commit الإصلاح e3f33b0a1d89d738e2b913dab519226eaf76e15b). قد تحمل نواة التوزيعة الإصلاح تحت رقم إصدار مختلف، لذا تحقق أيضًا من متتبّع جهة المصنّع.
2. تحقق من وسم CIPSO: cat /sys/kernel/security/lsm. إذا كان SELinux أو Smack مُدرجًا وكنت تستخدم NetLabel مع تعيين CIPSOV4، فإن هذا التخفيف لا يغطي ذلك المسار.
3. تحقق من المتطلبات: صلاحيات root، وsystemd، وnft. لدى OpenWrt مسار خاص بها (انظر Files). المضيفات التي لا تحتوي على systemd، بخلاف OpenWrt، غير مشمولة.

الخطورة: يمنح CNA الخاص بالنواة تقييم CVSS قدره 9.8. وتمنح Red Hat وOracle وSUSE تقييم 8.1، وتمنح Amazon تقييم 7.0. وصفت Anthropic علنًا استغلالًا عن بُعد للحصول على صلاحيات root ضد خوادم Linux لديها مستمع MPTCP (2026-10-27). لم يُبلَّغ عن أي استغلال في البرية حتى 2026-10-29.

حالة التوزيعات حتى 2026-10-29/30 (لقطة، لذا تحقق من جهة المصنّع):

التوزيعة	الحالة
Ubuntu (جميع الإصدارات المدعومة)	لا توجد نواة مُصلحة
RHEL 8/9/10	لا توجد نواة مُصلحة
Proxmox VE	لم يكن في سجل تغييرات pve-kernel أي إدخال لهذه الثغرة في 2026-10-30
Debian، Oracle Linux UEK، بعض إصدارات SUSE، بعض إصدارات Amazon Linux	الإصلاحات متاحة

التطبيق

1. شغّل sudo ./mitigate.sh. وهو عديم الأثر التكراري (تشغيله مرة أخرى يعيد تحميل مجموعة القواعد). يثبّت الملفات المدرجة تحت Files، ويتوقف إذا لم تكن root، أو إذا كان nft مفقودًا، أو إذا كان systemd مفقودًا.

2. قارن المخرجات مع المرجع أدناه. يجب أن يكون السطر الأول:

   svc=active enabled=enabled mptcp=0
   

   تتبع القاعدتان ذلك، واحدة في جدول inet وأخرى في جدول bridge.

3. إذا كانت إحدى الخدمات تستمع عبر MPTCP، فأعد تشغيلها. يؤثر net.mptcp.enabled=0 على المقابس الجديدة فقط، لذا يبقى مستمع MPTCP المفتوح مسبقًا على MPTCP حتى تُعاد خدمته. الـ sysctl خاص بكل فضاء أسماء شبكة، ويضبطه mitigate.sh لفضاء أسماء المضيف فقط.

4. إذا كان المضيف يشغّل حاويات LXC أو Docker، فتابع إلى قسم الحاويات.

استهدف الاستغلال المنشور مستمعي MPTCP. أما السباق نفسه فلا يتطلب MPTCP (استنتاج من وصف الإصلاح). ولم يُثبت ما إذا كان يمكن اختراق مضيف بلا MPTCP اختراقًا كاملًا.

التحقق

يعكس SYN-ACK الخاص بالهدف خيارات IP. والعميل الذي يطبّق هذا التخفيف بنفسه يُسقط ذلك SYN-ACK، لذا يُبلّغ check-blocked.py عن "blocked" حتى عندما يكون الهدف غير مخفَّف. قيس على مضيف واحد: بعد تشغيل revert.sh على الهدف، ظل check-blocked.py من عميل مخفَّف يطبع ipopt FAIL TimeoutError، بينما أظهر verify-synack.sh القيمة ipopt synack=5.

اختر أداة واحدة:

1. إذا كان لديك عميل بلا هذا التخفيف، فشغّل عليه python3 check-blocked.py <host> <port> (لا حاجة إلى root). يتصل مرتين: اتصال عادي، ثم اتصال مع خيار IPv4 Record Route مضبوط عبر خيار المقبس IP_OPTIONS.
2. إذا لم تستطع ضمان ذلك، فشغّل sudo ./verify-synack.sh <ip> <port> على أي عميل (يلزم root وtcpdump وpython3 على العميل). يرسل SYN عاديًا وSYN مع خيارات IP من منافذ مصدر ثابتة ويحصي SYN-ACKs الخاصة بالهدف باستخدام tcpdump.

ثم قارن المخرجات مع جدول تلك الأداة.

check-blocked.py (من عميل بلا التخفيف):

المخرجات	المعنى
plain CONNECTED	TCP العادي يعمل
ipopt FAIL TimeoutError	أُسقط SYN مع خيارات IP، كما هو مقصود

verify-synack.sh:

المخرجات	المعنى
plain: CONNECTED synack=N | ipopt: TimeoutError synack=0	الهدف مخفَّف
ipopt ... synack>=1	الهدف غير مخفَّف (تمت الاستجابة لـ SYN مع خيارات IP)

النتيجة على مستوى النواة (مضيف Proxmox VE واحد، نواة 7.0، 2026-10-30): مع إيقاف التخفيف، نُفّذ مسار الشيفرة الثغرة مرة واحدة لكل مسار، عبر WireGuard ومن LXC إلى LXC. ومع تشغيله، انتهت مهلة SYN ونُفّذ المسار 0 مرة. العينة مساران في حالتين على مضيف واحد. طريقة التتبع موجودة في docs/ANALYSIS.md (بالإنجليزية).

الحاويات

حالة nftables خاصة بكل فضاء أسماء شبكة، لذا لا تحمي قواعد المضيف وحدها فضاءات أسماء الحاويات. قيس على حاويات LXC: مع قواعد المضيف فقط، نجح اتصال SYN مع خيارات IP من داخل حاوية إلى 127.0.0.1 الخاصة بها أو إلى IP الخاص بها. تتشارك الحاويات نواة المضيف، لذا يمكن للشيفرة داخل أي حاوية الوصول إلى المسار الثغرة بهذه الطريقة.

1. أكمل خطوة التطبيق على المضيف أولًا.
2. شغّل sudo ./inject-netns.sh على المضيف. يحمّل مجموعة القواعد نفسها في كل حاوية LXC قيد التشغيل (عبر pct/lxc-info، Proxmox) وكل حاوية Docker قيد التشغيل (تُتخطى حاويات شبكة المضيف).
3. قارن المخرجات مع الجدول.

المخرجات	المعنى
ok lxc:<id> أو ok docker:<id>	حُمّلت مجموعة القواعد في فضاء أسماء تلك الحاوية
injected=N failed=M	الإجماليات، ويجب أن تكون M مساوية لـ 0

الحقن غير دائم. يُفقد عند إعادة تشغيل الحاوية، لذا أعد تشغيل السكربت بعد عمليات إعادة التشغيل. تحتاج حاويات Docker المتداخلة داخل حاوية LXC إلى تشغيل السكربت داخل تلك الحاوية LXC (لم يُقس).

النتيجة المقيسة: عبر 5 مضيفات Proxmox، حُقنت 64 فضاء أسماء حاوية دون أي فشل. بعد الحقن، انتهت مهلة الاختبار نفسه وارتفع عدّاد الإسقاط في فضاء أسماء الحاوية.

إذا تعطّل شيء

عَرَض تداخل هذا التخفيف هو اتصال TCP يتعلّق (تنتهي مهلته) بدلًا من أن يُرفض، مع ارتفاع عدّاد في مخرجات:

nft list ruleset | grep counter

الأمر	التأثير
systemctl stop cve-2026-98432-mitigation	إيقاف فوري، ويعود عند إعادة التشغيل
systemctl disable --now cve-2026-98432-mitigation	إيقاف الآن وعبر عمليات إعادة التشغيل

التوافق المقاس على المضيفين المختبَرين: تقع القواعد في جداولها الخاصة وتعايشت مع Docker وufw وقواعد NAT الخاصة بـ iptables-legacy وتوجيه NetBird (WireGuard). استمرت اتصالات TCP العادية في العمل على كل مسار مختبَر. بقيت عدّادات الإسقاط عند أعداد حزم الاختبار أثناء التشغيل العادي (لم تطابق أي حركة مرور شرعية) خلال نافذة مراقبة قصيرة (ساعات، لا أيام).

استنتاج، وليس قياسًا: خدمة nftables.service التي يحتوي إعدادها على flush ruleset ستحذف الجداول عند إعادة تحميلها. تحقق من ذلك، وأعد تشغيل mitigate.sh بعد إعادة التحميل تلك.

الإزالة بعد الترقيع

1. أقلع النواة المُصلَحة وتأكد باستخدام uname -r.
2. شغّل sudo ./revert.sh. أضف --mptcp إذا أردت أيضًا إعادة تفعيل MPTCP.
3. قارن السطر الأخير من المخرجات:

المخرجات	المعنى
remaining tables: 0	الوحدة معطّلة، والملفات الثلاثة والجدولان قد اختفيا

القيود

1. قاعدة الجسر تطابق IPv4 غير الموسوم (ether type ip). لم تُختبر الجسور المدركة لـ VLAN.
2. التغطية حسب المسار: حركة NIC وحركة النفق المفكوكة وloopback تمر عبر قاعدة inet، والإطارات المُبدَّلة بين منافذ الجسر تمر عبر قاعدة bridge. تم قياس WireGuard وloopback. لم يتم قياس IPIP وGRE وVXLAN (استدلال من الشيفرة فقط).
3. كانت قيمة tcp_migrate_req تساوي 0 على المضيفين المختبَرين. يحتاج سباق ترحيل مقبس الطلب إلى نفس ireq_opt غير الفارغ، لذا تنطبق القاعدة نفسها (استدلال من الشيفرة).
4. المنصات المختبَرة: Proxmox VE على Debian 13 (النواتان 6.17 و7.0) مع LXC وNetBird؛ Ubuntu 24.04 arm64 مع Docker وufw؛ نوى Arch Linux 7.2.x. تم اختبار دورة السكربت mitigate وrevert وmitigate وinject-netns اختبارًا سريعًا على مضيف Proxmox واحد.

كيف يعمل