ما الذي تصفه الصفحة، دالةً دالة
تصف صفحة Ubuntu خللًا في إدارة الذاكرة أثناء إنشاء اتصالات TCP عبر IPv4. حين يرسل عميل حزمة SYN، تنشئ النواة طلب اتصال؛ وفي نهاية المصافحة تنشئ الدالة tcp_v4_syn_recv_sock() المقبس الابن. وبحسب الصفحة، تمرّر هذه الدالة خيارات IP الخاصة بالطلب إلى المقبس الابن دون نسخها. فإذا عولجت حزمة SYN معاد إرسالها في اللحظة نفسها على معالج آخر، قد تقرأ النواة تلك الخيارات المحرَّرة أصلًا أثناء بناء SYNACK: وهذا هو الاستخدام بعد التحرير، في ip_options_build().
وتشير الصفحة إلى سباق مشابه أثناء ترحيل الطلبات بين المقابس، حين يكون net.ipv4.tcp_migrate_req=1 أو يعمل برنامج BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. أما الإصلاح الموصوف فيؤجّل تحرير الذاكرة إلى نهاية فترة سماح RCU، باستخدام kfree_rcu()، في inet_sock_destruct() وtcp_v4_reqsk_destructor(). ولا يتأثر IPv6 بالخلل الأول؛ وتذكر الصفحة أن خللًا مشابهًا في الترحيل موجود هناك وسيُعالَج على حدة. وتذكّر أيضًا بما لا تقوله: قابلية الاستغلال عن بُعد غير مثبتة علنًا في الصفحات التي قرأناها.
درجتان من جهتين: 9.8 و8.1
الرقمان لا يتناقضان، بل يصفان أمرين مختلفين. تعرض Ubuntu أولوية High ودرجة CVSS 3 قدرها 9.8 بتصنيف Critical. وتنشر Red Hat درجة CVSS v3.1 قدرها 8.1 بالمتجه CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. وتورد صفحة Red Hat أيضًا، للمقارنة، قيمة cve.org: 9.8 مع AC:L. الذي يتغير هو تعقيد الهجوم فقط: منخفض (AC:L) من جهة، ومرتفع (AC:H) من الأخرى.
تعكس درجة 8.1 لدى Red Hat سباقًا ضيّق التوقيت، يلزم فيه المهاجم أن يجعل معالجتين تتزامنان على معالجين؛ ويتحدث وصفها أولًا عن انهيار، مع احتمال تلف الذاكرة. وتوضح الصفحة أن هذه الدرجات أولية وقابلة للمراجعة. فلا تحتفظ برقم واحد: 9.8 بحسب Ubuntu و8.1 بحسب Red Hat. وفي المتجهات التي نشرتها Red Hat وcve.org، يمكن بلوغ الثغرة عبر الشبكة دون مصادقة (AV:N وPR:N)، وهذا يكفي لأخذها بجدية دون تقديمها كهجوم جارٍ: فلا إحدى الصفحتين اللتين قرأناهما تشير إلى هجوم.
الحالة المنشورة في 30 أكتوبر 2026
مرّر الجدول أفقيًا
| المصدر أو النسخة | الحالة المقروءة في الصفحة | ما يعنيه ذلك لك |
|---|---|---|
| Ubuntu 24.04 LTS (noble) | Vulnerable والإصلاح قيد العمل؛ النسخة المدرجة 6.8.0-149.149 | لا توجد نواة مصلَحة لتثبيتها حاليًا |
| Ubuntu 22.04 LTS (jammy) | Vulnerable والإصلاح قيد العمل؛ النسخة المدرجة 5.15.0-203.213 | لا توجد نواة مصلَحة لتثبيتها حاليًا |
| Ubuntu 26.04 LTS | Vulnerable والإصلاح قيد العمل؛ النسخة المدرجة 7.0.0-43.43 | لا توجد نواة مصلَحة لتثبيتها حاليًا |
| Ubuntu 20.04 LTS (focal) | لا نسخة مدرجة؛ راجع الحالة في الصفحة | أعد فتح الصفحة قبل أي استنتاج |
| Red Hat | CVSS v3.1 قدرها 8.1، لا حل مخفِّف مقترح، لا حزمة مصلَحة مدرجة، Bugzilla 2553390 | لا التفاف رسمي؛ تابع التذكرة |
| Debian وAlmaLinux وRocky وغيرها | لم تُقرأ لهذا المقال | اقرأ إشعار مزوّد توزيعتك ولا تستنتج من Ubuntu |
| رقم نسخة في صفحة | ليس نسخة مصلَحة ما دامت الحالة لم تتحول إلى مصلَحة | لا تقارن `uname -r` بهذا الرقم إلا بعد تغيّر الحالة |
النواة المثبتة ليست النواة العاملة
يضع الأمر apt upgrade أو dnf update نواة جديدة في /boot، لكن النظام يواصل تشغيل النواة المحمّلة عند آخر إقلاع إلى أن يُعاد تشغيله. ويجيب uname -r عن السؤال الوحيد المهم هنا: أي نواة تعمل الآن. أما قائمة الحزم فتجيب عن سؤال آخر: أي نوى موجودة على القرص. فحين يصدر الإصلاح، قد يعرض VPS عبارة «محدَّث» في مدير الحزم ويبقى معرَّضًا أسابيع.
والعكس صحيح اليوم: تثبيت تحديثات اليوم لا يصلح هذه الثغرة، لأن الصفحتين لا تدرجان نواة مصلَحة. وحاويات Docker لا تغيّر شيئًا، فهي تتشارك نواة الجهاز. على آلة افتراضية كاملة تكون هذه النواة نواتك؛ وعلى VPS من نوع الحاويات تكون نواة المضيف، فيلزم سؤال المزوّد. أما إجراء إعادة التشغيل نفسه فمفصّل في دليل PwnEscape وVghost المرتبط أسفل هذا المقال، فلا داعي لتكراره هنا.
افحص VPS في عشر دقائق
اقرأ النواة العاملة
uname -rcat /proc/version
دوّن السلسلة كاملة بلاحقتها (-genericأو-awsأو-kvmأوel9…). هي ما ستقارنه بصفحة توزيعتك، وتدلّك اللاحقة على نوع النواة الذي تبحث عنه.اعرض النوى المثبتة وإعادة التشغيل المعلّقة
Debian وUbuntu:
dpkg -l 'linux-image*' | grep '^ii'ثمls /var/run/reboot-required
RHEL وAlmaLinux وRocky:rpm -q kernelثمsudo needs-restarting -r
إذا اختلفت أحدث نواة مثبتة عن تلك التي يعرضهاuname -r، فهناك إعادة تشغيل معلّقة.ابحث عن إصلاح منشور
Debian وUbuntu:
sudo apt updateثمapt list --upgradable 'linux-image*'
RHEL وAlmaLinux وRocky:sudo dnf updateinfo list --cve CVE-2026-98432ثمsudo dnf check-update kernel
القائمة الفارغة لا تثبت أنك محمي: هي تقول فقط إن مستودعك لا يقترح شيئًا حاليًا.اقرأ ما تعلنه الحزمة المرشحة
Debian وUbuntu:
apt changelog <الحزمة-المدرجة-في-الخطوة-السابقة> | grep -n 'CVE-2026-98432'
RHEL وAlmaLinux وRocky:sudo dnf updateinfo info --cve CVE-2026-98432
إذا ظهر المعرّف فالحزمة تعلن الإصلاح؛ دوّن رقم نسختها وأكّده في صفحة توزيعتك قبل أن تستنتج.اقرأ التعرّض الشبكي
sudo ss -4tlnpsysctl net.ipv4.tcp_migrate_req
يعرض الأمر الأول منافذ TCP عبر IPv4 في حالة الاستماع، أي الأماكن الوحيدة التي تصل إليها مصافحة TCP؛ وهذه قراءتنا للصفحة وليست عبارة منها. ويعرض الثاني حالة إعداد الترحيل (0أو1). هذا الإعداد لا يغلق الثغرة: فالخلل الأول الموصوف موجود من دونه.أعد فتح الصفحة يوم القرار
افتح صفحة توزيعتك، ودوّن حالة نوع نواتك وتاريخ آخر تحديث تعرضه. سجّلهما مع تاريخ القراءة: هذه الصفحات تتغير، والحالة المقروءة قبل ثلاثة أيام ليست حالة اليوم.
التصرف دون إصلاح مؤكد
- أغلق ما لا يلزم بلوغه — كل منفذ TCP عبر IPv4 مفتوح لكل الإنترنت مدخل محتمل. قيّد SSH وقواعد البيانات والإدارة بالعناوين اللازمة عبر
ufwأوfirewalld. هذا يقلّص السطح دون أن يصلح منفذًا عامًا مثل 443. - لا تعتمد على التفاف — لا تقترح Red Hat أي التفاف، ولا يدرج الجزء الذي قرأناه من صفحة Ubuntu أيًّا منها. وضبط
net.ipv4.tcp_migrate_reqعلى0لا يغطي الخلل الأول الموصوف. - جهّز نافذة إعادة التشغيل — اختر الموعد، وأبلغ المستخدمين، وتحقق من أن خدماتك تعمل تلقائيًا بعد الإقلاع (
systemctl is-enabled <service>)، وخذ نسخة احتياطية أو لقطة قبل ذلك. - اكتشف الإصلاح فور صدوره — شغّل يوميًا
apt list --upgradable 'linux-image*'أوdnf check-update kernel، أو أعد قراءة الصفحة. وبحسب الإعداد، قد يثبّت التحديث التلقائي النواة دون إعادة تشغيل. - احتفظ بمدخل احتياطي — حدّد مكان وحدة الطوارئ لدى مزوّدك قبل إعادة التشغيل لا أثناءها: فالنواة التي لا تقلع تُعالَج من هناك.
- راقب الانهيارات — تصف Red Hat انهيارًا في الأساس. يُظهر
journalctl -k -p err --since '7 days ago'وlast -x rebootإعادة تشغيل غير متوقعة أو رسالة نواة غير معتادة تُقارَن بتاريخ النشر.
Livepatch: خيار بشرط واحد
يطبّق التصحيح الساخن إصلاحًا على النواة العاملة دون إعادة تشغيل. ولا يوجد إلا بعد أن ينتجه ناشر التوزيعة أو مزوّد الخدمة، ولا يغطي إلا الثغرات التي عالجها. مع خدمة Livepatch من Canonical، يعرض canonical-livepatch status --verbose الإصلاحات المطبقة؛ وفي توزيعات أخرى تؤدي خدمات من أطراف ثالثة مثل KernelCare هذا الدور. والقاعدة واحدة في كل مكان: ما دام المعرّف CVE-2026-98432 غير ظاهر في قائمة الإصلاحات المطبقة، فأنت غير مغطّى، حتى لو بدت الخدمة نشطة.
لا تذكر أي من الصفحات التي قرأناها livepatch لهذه الثغرة في تاريخ الاطلاع. وlivepatch لا يعفيك من النواة التالية: خطط مع ذلك لإعادة التشغيل نحو النسخة المصلَحة، في الموعد الذي اخترته.
دوّن التاريخ لا الحالة فقط
في دفتر التشغيل لديك، دوّن لكل خادم النواة العاملة والحالة المقروءة في الصفحة وتاريخ القراءة. الحالة الموصوفة في هذا الدليل هي حالة 30 أكتوبر 2026؛ وقد تكون تغيرت حين تقرؤه. هذا الدليل مقدَّم كما هو: إدارة خادمك تبقى من مسؤوليتك، دون دعم من جانبنا.
يوم تظهر نواة مصلَحة
اقرأ الصفحة أولًا: يجب أن تكون حالة نوعك قد تحولت إلى مصلَحة وأن تذكر رقم نسخة. لا تدرج صفحة Ubuntu حزمة واحدة بل عدة حزم (linux وlinux-aws وlinux-azure وlinux-gcp…): اتبع السطر الموافق للاحقة التي يعرضها uname -r، لا سطر الحزمة linux الافتراضية.
ثم ثبّت بالأمر sudo apt upgrade (Debian وUbuntu) أو sudo dnf upgrade kernel (RHEL وAlmaLinux وRocky)، وأعد التشغيل بالأمر sudo reboot، وتحقق عبر uname -r من أن السلسلة العاملة تطابق النواة المصلَحة المعلنة. فإن بقيت تطابق القديمة، فإن إعادة التشغيل لم تنتقل إلى النواة الجديدة: راجع مدخل الإقلاع الافتراضي قبل أن تعلن الخادم مصلَحًا. وأخيرًا دوّن الرقم المثبّت في دفترك.
التوثيق الرسمي
صفحة Ubuntu الخاصة بـ CVE-2026-98432 (نُشرت في 15 أكتوبر 2026 وحُدّثت في 29 أكتوبر 2026): https://ubuntu.com/security/CVE-2026-98432
صفحة Red Hat الخاصة بـ CVE-2026-98432 (CVSS 8.1، Bugzilla 2553390): https://access.redhat.com/security/cve/CVE-2026-98432
اطُّلع على الصفحتين في 30 أكتوبر 2026؛ وقد تكونان تغيرتا منذئذٍ.
