مجموعة أدوات التخفيف من CVE-2026-98432

استخدام-بعد-التحرير (use-after-free) في inet_opt/ireq_opt لبروتوكول TCP على IPv4 (الإصلاح في المنبع e3f33b0a، kfree ← kfree_rcu في inet_sock_destruct() + tcp_v4_reqsk_destructor()). المُحفِّز: SYN من العميل يحمل خيارات IPv4 (ihl > 5) — بدون الخيارات لا يتم تخصيص الكائن المتسابق ireq_opt أبدًا. يتطلب استغلال الحصول على صلاحيات الجذر عن بُعد المزعوم أيضًا مستمع MPTCP.

الملفات

الملف	يحتاج صلاحيات الجذر	الغرض
cve-audit.sh	لا	تقرير للقراءة فقط عن مدى التعرّض وقابلية الترقيع
cve-mitigate.sh	تطبيق/تراجع	إسقاط حزم SYN التي تحمل خيارات IP عبر nft، مع إيقاف MPTCP اختياريًا
nft-rules.txt	—	مجموعة القواعد بشكل مستقل (nft -f nft-rules.txt)
cve-detect.sh	أوضاع الالتقاط	مستشعر tcpdump لشكل حزم الاستغلال
kpatch-el-build.sh	بناء/تثبيت	أداة بناء kpatch/livepatch مُتحقَّق منها لعائلة EL
klp-handcraft-build.sh	بناء/تحميل	وحدة klp مكتوبة يدويًا لنوى IBT حيث لا يمكن تشغيل kpatch-build (EL10)
patches/CVE-2026-98432.patch	—	إصلاح المنبع، جاهز لـ kpatch-build
tests/run-tests.sh	لا	أداة اختبار (تحميل مجموعة القواعد في netns + اختبار شامل لأداة البناء المُحاكاة)

البدء السريع للحوادث

./cve-audit.sh                                # where do I stand?
./cve-mitigate.sh apply --with-mptcp-off      # closes trigger + claimed root path
./cve-detect.sh count 30                      # anyone probing with IP options?
sudo ./kpatch-el-build.sh --name CVE-2026-98432 \
     --expect inet_sock_destruct,tcp_v4_reqsk_destructor \
     [--sign priv.pem cert.pem] [--install] \
     patches/CVE-2026-98432.patch
# verify: cat /sys/kernel/livepatch/CVE-2026-98432/enabled  -> 1
./cve-mitigate.sh status                      # keep until 100% patched, then:
./cve-mitigate.sh undo

مصفوفة EL

الهدف	ملاحظات
EL7 (3.10)	غير معرّض للثغرة (وصل كود التفعيل في 4.4)؛ لا يزال المُنشئ يعمل مع تصحيحات أخرى
EL7h/EL8 (4.18)	معرّض للثغرة؛ يوفّر kernel-debuginfo المسار /usr/src/debug/kernel-*/linux-*؛ وkpatch-build من EPEL
EL9 (5.14)	معرّض للثغرة؛ النواة مبنية باستخدام gcc-toolset — يضيف المُنشئ تلقائيًا بادئة /opt/rh/gcc-toolset-* المطابقة
EL10 (6.12)	IBT: يرفض kpatch-build 0.9.11 نوى CONFIG_X86_KERNEL_IBT=y (dynup/kpatch#1320) — استخدم klp-handcraft-build.sh؛ توقيع الوحدات مفروض تحت Secure Boot/lockdown
CloudLinux 8/9/10	معرّف التوزيعة غير موجود في قائمة الدعم لدى kpatch-build، لذا يمرّر المُنشئ دائمًا -s/-c/-v صراحةً؛ تأتي معلومات التصحيح (debuginfo) من kernel-debuginfo الخاص بـ AlmaLinux/CentOS المطابق لـ rpm -qf /boot/vmlinuz-$(uname -r)

تتطلب معلومات التصحيح (debuginfo) على RHEL تفعيل المستودعات، مثل dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms وغيرها على المضيفين غير المفوترين).

ما يتحقق منه المُنشئ قبل تحميل أي شيء

1. CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y في الإعدادات الجارية.
2. النواة الهدف == النواة الجارية (حاجز vermagic)، مع وجود kernel-devel/debuginfo/vmlinux.
3. يُطبَّق التصحيح بالاتجاه الأمامي؛ وإذا طُبِّق بالاتجاه العكسي فسيُخبرك أن النواة تحتوي بالفعل على الإصلاح (وإلا سيفشل kpatch لاحقًا برسالة "no functional changes").
4. المُصرِّف يطابق gcc المستخدم في بناء النواة (فحص مستوى .comment مُفوَّض إلى kpatch-build؛ والبحث عن toolset يتم هنا).
5. بعد البناء: vermagic، وقائمة سماح صارمة ثنائية الاتجاه للدوال المتغيّرة (--expect) — أي كائن تغيير ثالث غير متوقع يُعدّ فشلًا قاطعًا.
6. خيار sign-file مع زوج مفاتيحك + إعادة فحص modinfo sig_type؛ وسجّل الشهادة عبر MOK من أجل Secure Boot.
7. يضع --install الملف في /var/lib/kpatch/$(uname -r)/، ويحمّله عبر kpatch/insmod، ويفعّل kpatch.service لضمان الاستمرارية بعد إعادة التشغيل.

دليل التشغيل التجريبي (نفّذ هذا قبل النشر على الأسطول)

1. جهاز VM تجريبي (canary)، بنفس uname -r الخاص بالأسطول.
2. ./kpatch-el-build.sh ... --install؛ وتأكد من أن /sys/kernel/livepatch/<name>/enabled == 1.
3. اختبار السباق المكثّف: من جهاز ثانٍ، أطلق فيضان hping3 -S -p <port> --tcp-opts ... على منفذ استماع مع تبديل net.ipv4.tcp_migrate_req=1 على الجهاز التجريبي؛ ويفترض أن يعيد إنتاج نسخة نواة KASAN مع udelay() مصطنع داخل ip_options_build() ثغرة UAF بدون التصحيح ويبقى صامتًا معه.
4. راقب بقاء uname -r دون تغيير (فالـ livepatch لا يرفعه)، وkpatch list، وdmesg -w بحثًا عن taint وتعثّر انتقال klp (/sys/kernel/livepatch/<name>/transition يجب أن ينخفض إلى 0).
5. انشر على الأسطول؛ وأزل قاعدة nft بعد 24–48 ساعة من تغطية 100%.
6. أعد التشغيل إلى نواة المورّد في النافذة التالية بغض النظر عن ذلك — فالـ livepatches تتراكم بشكل سيئ عبر ترقيات النواة.

الحالة / الصدق

منظومة الاختبار (Harness): تنجح جميع الفحوصات على جهاز VM بنظام AlmaLinux 10.2 (النواة 6.12.0-211.64.1.el10_2). تُحمَّل مجموعات قواعد nft الحقيقية وتُدرَج داخل netns جديد؛ وتُصرَّف مرشّحات pcap مقابل tcpdump حيّ؛ وتُجرَّب خط أنابيب المُنشئ من البداية إلى النهاية مقابل kpatch-build وهمي مع ملف .ko حقيقي وتغذيات رموز (symbol feeds) مُحقَنة.

تم التحقق منه مباشرةً على تلك الآلة الافتراضية EL10:

• klp-handcraft-build.sh --load بنى وفعّل livepatch: /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1، واكتملت عملية الانتقال (transition drained)، ويسرد sysfs القيمتين inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1؛ ولم يتأثر TCP العادي (HTTP 200). ملف .ko غير الموقّع يلوّث النواة (taints the kernel)؛ وكان Secure Boot lockdown سيرفضه (شُغّلت الآلة الافتراضية بدون توقيع).
• يفشل kpatch-build الحقيقي (dynup 0.9.11، المبني من المصدر) فشلًا قاطعًا على EL10 برسالة "kernel option CONFIG_X86_KERNEL_IBT not supported" — وأصبح الباني الآن يفحص ذلك مسبقًا ويوجّه إلى مسار البناء اليدوي (handcraft). ولا يزال تشغيل kpatch-build الحقيقي القائم على فرق ثنائي (binary-diff) غير مُختبَر على EL8/EL9.
• التخفيف فعّال مباشرةً: تم عدّ وإسقاط 20 حزمة SYN بخيارات scapy عبر الشبكة بواسطة قاعدة الحماية (guard rule)؛ ومرّت 3 حزم SYN عادية؛ ولم يتأثر ssh.
• اكتشاف ميداني: على EL10 6.12.0-211، تصطدم حزم SYN المصنوعة يدويًا مع خيارات IP بخطاف nft الخام prerouting (-300) لكنها لا تصل أبدًا إلى خطاف INPUT (المنفذ المفتوح، وlo، وnetns نظيف كلها تعيد إنتاج المشكلة؛ ولا يوجد حدث tracepoint من نوع kfree_skb، رغم أن SELinux منع perf/kprobes ولم يلتقط tcpdump شيئًا، لذا فإن دالة الإسقاط الدقيقة غير محددة). لذلك تربط سلسلة التخفيف خطاف prerouting priority raw، الذي يرصدها ويسقطها؛ وقاعدة صديق عند prerouting priority -310 تعمل للسبب نفسه. شغّل المسار السليم (happy path) مرة واحدة على آلة EL الخاصة بك للاختبار قبل الوثوق به في حادثة.