باختصار
CVE-2026-98432 خلل من نوع الاستخدام بعد التحرير (use-after-free) في معالجة نواة Linux لاتصالات IPv4 TCP، وقد صُنّف حرجًا بدرجة CVSS قدرها 9.8 [1]. ويعود الخلل إلى الإصدار Linux 4.4، وأُصلح في الإصدار 7.3 وفي عدة إصدارات مستقرة [2]. ولا يحتاج المهاجم البعيد إلى تسجيل الدخول [1]. والإصلاح الكامل الوحيد هو تثبيت نواة مُصلَحة ثم إعادة التشغيل [6].
أهم النقاط
- نشر فريق CVE الخاص بنواة Linux الثغرة CVE-2026-98432 في 15 أكتوبر 2026، بدرجة CVSS 3.1 قدرها 9.8 (حرجة) ومتجه هجوم عبر الشبكة [1].
- ظهر الخلل في الإصدار Linux 4.4، وأُصلح في الإصدارات 5.10.272 و5.15.223 و6.1.190 و6.6.159 و6.12.113 و6.18.56 و7.2.10 و7.3 [2].
- تقول Anthropic إن إثبات المفهوم الذي طورته منح مهاجمًا بعيدًا القدرة على تنفيذ أوامر بصلاحيات الجذر على خوادم Linux التي تشغّل مُنصتًا لبروتوكول TCP متعدد المسارات (MPTCP) [4]، لكن Red Hat تقول إن MPTCP ليس شرطًا لازمًا لاستغلال الثغرة [6].
- حتى 3 نوفمبر 2026، أصدرت Red Hat وDebian وAlmaLinux أنوية مُصلَحة لإصداراتها المدعومة [7][9][10]، في حين تُدرج Ubuntu إصلاحاتها على أنها قيد العمل [8].
- تقلل قواعد الجدار الناري التي تُسقط حزم IPv4 TCP الحاملة لخيارات IP من التعرض للخطر، لكنها بحسب Red Hat وUbuntu لا تمنع الاستغلال منعًا تامًا [6][8].
- حتى 3 نوفمبر 2026 لم تُدرج الثغرة في فهرس الثغرات المستغلة المعروفة لدى وكالة CISA [14]، وتقول Akamai إنها لا تعلم بوجود استغلال عامّ فعّال [11].
في هذه الصفحة ١٢ أقسام
ما الثغرة CVE-2026-98432؟
CVE-2026-98432 ثغرة في نواة Linux، وهي لبّ أنظمة التشغيل المبنية على Linux. وعنوانها الرسمي ipv4: free inet_opt and ireq_opt after an RCU grace period [1]. وقد خصصها فريق CVE الخاص بنواة Linux ونشر سجلها في 15 أكتوبر 2026 [1]. ويمنحها السجل درجة أساسية في CVSS 3.1 قدرها 9.8، وهي درجة مصنفة حرجة [1].
الخلل من نوع الاستخدام بعد التحرير: أي أن البرنامج يواصل استخدام جزء من الذاكرة بعد تحريره، فتكون تلك الذاكرة قد صارت تحمل بيانات أخرى. ويقع الخلل هنا في الشيفرة التي تعالج طلبات اتصال IPv4 TCP الواردة [10]. ومتجه CVSS هو AV:N/AC:L/PR:N/UI:N، ومعناه أن الهجوم يتم عبر الشبكة، وأن تعقيده منخفض، وأنه لا يحتاج إلى أي صلاحيات ولا إلى أي تفاعل من المستخدم [1].
والخلل موجود منذ الإصدار Linux 4.4، إذ دخل مع الإيداع 079096f103fa [2]. وقد أودِع إصلاح كتبه إريك دوماز (Eric Dumazet) في 5 أكتوبر 2026، وهو الآن في النواة الرئيسية [3]. ونُقل الإصلاح إلى الفروع المستقرة التي ما زالت تحظى بالصيانة [2][4].
ما الأنظمة المتأثرة؟
تقول Red Hat إن الخلل يؤثر في أي نظام يشغّل نواة معرّضة مع تفعيل شبكات IPv4 TCP. والأنظمة التي تقبل اتصالات TCP واردة هي الأكثر تعرضًا بشكل مباشر [6]. وتنصح AlmaLinux بمعاملة أي نظام يقبل اتصالات IPv4 TCP من شبكات غير موثوقة على أنه معرّض [10]. أما IPv6 فلا يتأثر بالمشكلة الرئيسية [2].
كيف تعمل الثغرة؟
يبدأ اتصال TCP بعملية مصافحة: يرسل العميل حزمة SYN، فيرد الخادم بحزمة SYN-ACK، ثم يؤكد العميل. ويمكن أن تحمل حزمة SYN ما يُعرف بـخيارات IPv4، وهي حقول إضافية اختيارية في ترويسة IP، ومن أمثلتها خيارا تسجيل المسار (Record Route) والطابع الزمني (Timestamp) [1].
وبحسب وصف النواة، تسلّم الدالة tcp_v4_syn_recv_sock() الخيارات المحفوظة إلى المقبس الفرعي الجديد دون أن تنسخها [2]. وفي الوقت نفسه، قد تعالج نواة معالج أخرى حزمة SYN مُعادة الإرسال للطلب نفسه، فتبني حزمة SYN-ACK تقرأ تلك الخيارات [2]. ولا شيء يمنع تحرير المقبس الفرعي بينما لا تزال حزمة SYN-ACK قيد البناء. وتُحرَّر خياراته باستدعاء kfree() عادي، فتقرأ النواة ذاكرة محرَّرة داخل ip_options_build() [2].
وثمة سباق ثانٍ مشابه يظهر عند تفعيل ترحيل مقابس الطلبات، إما عبر net.ipv4.tcp_migrate_req=1 أو عبر برنامج BPF من نوع reuseport [2]. ويجعل الإصلاح مساري التحرير كليهما ينتظران انقضاء فترة سماح RCU، وذلك باستخدام kfree_rcu() في inet_sock_destruct() وtcp_v4_reqsk_destructor() [2]. وRCU (القراءة والنسخ والتحديث) تقنية في النواة تؤخر تحرير الذاكرة إلى أن يتأكد أنه لم يعد هناك قارئ يستخدمها.
ماذا يستطيع المهاجم أن يفعل بها؟
تصف ملاحظات التقييم في سجل الثغرة ثلاثة آثار [1]:
- كشف المعلومات: قد تُعاد استعمال الذاكرة المحرَّرة لبيانات أخرى، ويمكن أن يُنسخ محتواها إلى حزمة SYN-ACK المرسلة إلى المهاجم [1].
- إفساد الذاكرة: يمكن للأطوال والإزاحات القديمة أن توجّه عمليات الكتابة في النواة إلى خارج الحدود، مع احتمال إفساد مسار التحكم في التنفيذ [1].
- الأعطال: قد تتسبب قيمة طول مُعاد استعمالها في انهيار النواة (kernel panic)، كما قد تؤدي عمليات الكتابة الشاردة إلى انهيارها أيضًا [1].
وتضيف Red Hat أن تنفيذ الشيفرة بشكل موثوق عبر هذا الخلل الحساس للتوقيت يتطلب تحكمًا دقيقًا في الكومة (heap). ومع ذلك تصنّفه حرجًا لأنه لا يتطلب أي شروط مسبقة على مستوى الشبكة، ولأنه قد يسبب اضطرابًا شديدًا في استقرار النظام [7].
ماذا كشفت Anthropic، وما دور MPTCP؟
في 27 أكتوبر 2026، نشر فريق Frontier Red Team التابع لشركة Anthropic تقريرًا عن ثغرات اكتشفها باستخدام نماذج Claude [4][11]. وبالنسبة إلى CVE-2026-98432، يقول إن الفريق بنى استغلالًا يتيح لمهاجم بعيد تشغيل أوامر عشوائية بصلاحيات الجذر على خوادم Linux التي تشغّل مُنصتًا لبروتوكول TCP متعدد المسارات (MPTCP)، دون بيانات اعتماد ودون تفاعل من المستخدم [4]. وMPTCP امتداد لبروتوكول TCP يتيح لاتصال واحد استخدام عدة مسارات شبكية في آن واحد.
وتصف Anthropic مرحلتين: أولًا يُسرّب الاستغلال مؤشرًا من النواة لتجاوز KASLR، أي التوزيع العشوائي لعناوين النواة. ثم يكتب فوق مؤشر استدعاء راجع (callback) لتنفّذ النواة أمرًا يختاره المهاجم بصلاحيات الجذر [4]. وخسارة السباق لا تؤدي إلا إلى فشل المصافحة دون أن ينهار النظام، ولذا يستطيع المهاجم مواصلة المحاولة [4]. وفي إثبات المفهوم لدى Anthropic، استغرق تسريب مؤشر النواة 48 دقيقة، واستغرق تنفيذ الأوامر خمس دقائق أخرى [4].
هل MPTCP شرط لازم؟
لا، بحسب الجهات المورّدة التي قيّمت الثغرة. إذ تقول Red Hat إن MPTCP ليس شرطًا لازمًا لهذا الخلل، وإن الأنظمة التي عُطّل فيها MPTCP تبقى متأثرة [6]. ويقول فريق أمن Go إن الاستغلال الذي عُرض يحتاج إلى مُنصت MPTCP، لكن الخلل الأساسي غير مقصور على MPTCP [5]. ولـGo صلة بالأمر لأن برامج Go تفعّل MPTCP افتراضيًا لمقابس الاستماع على Linux منذ الإصدار Go 1.24 [5].
وبحسب Akamai، لم تنشر Anthropic استغلالها الذي يمنح صلاحيات الجذر، وقالت Akamai في 2 نوفمبر 2026 إنها لا تعلم بوجود استغلال عامّ فعّال [11].
ما إصدارات النواة والتوزيعات المُصلَحة؟
يُدرج فريق CVE الخاص بالنواة الإصلاحات التالية في المصدر الأصلي (upstream): 5.10.272 و5.15.223 و6.1.190 و6.6.159 و6.12.113 و6.18.56 و7.2.10 والنواة الرئيسية 7.3 [2]. غير أن معظم الناس يشغّلون نواة تبنيها توزيعتهم، وهي تستخدم أرقام إصدارات خاصة بها. لذا راجع النشرة الأمنية لتوزيعتك بدلًا من المقارنة بأرقام المصدر الأصلي.
الوضع حتى 3 نوفمبر 2026:
- Red Hat Enterprise Linux: صدرت أنوية مُصلَحة في 1 نوفمبر 2026 للإصدارات RHEL 8 و9 و10. ويُدرج الإصداران RHEL 6 و7 على أنهما غير متأثرين. أما نواة الزمن الحقيقي في RHEL 9 وصور عُقد OpenShift فما زالت مدرجة على أنها متأثرة [7].
- Ubuntu: تصنّف Ubuntu المشكلة حرجة. ويُظهر متتبّعها الإصدارات 26.10 و26.04 LTS و24.04 LTS و22.04 LTS على أنها معرّضة مع إصلاحات قيد العمل؛ كما تُدرج الإصدارات 20.04 و18.04 و16.04 على أنها معرّضة، والإصدار 14.04 على أنه غير متأثر [8].
- Debian: تتوفر إصلاحات للإصدار Debian 12 bookworm (linux 6.1.190-1 وlinux-6.12 6.12.113-1~deb12u1) والإصدار Debian 13 trixie (linux 6.12.113-1)، وللفرع unstable [9].
- AlmaLinux: الأنوية المُصلَحة للإصدارات AlmaLinux 8 و9 و10 موجودة في مستودعات الإنتاج [10].
- توزيعات أخرى: أفادت Akamai بأن SUSE وOracle Linux وAmazon Linux 2023 أصدرت أنوية مُصلَحة لبعض الإصدارات بحلول 30 أكتوبر 2026 [11].
ماذا عن هواتف Android؟
يستخدم Android نواة Linux، لكن نشرة أمان Android الصادرة في 2 نوفمبر 2026 لا تُدرج الثغرة CVE-2026-98432 [13]. وينبغي لمالكي الهواتف تثبيت التحديثات الأمنية حين تصدرها الشركة المصنّعة.
كيف تتحقق مما إذا كان الخادم معرّضًا؟
- اعرف النواة العاملة. نفّذ الأمر
uname -r. ولا يُحتسب الإصلاح إلا بعد إعادة تشغيل الجهاز على النواة الجديدة. وتطلب AlmaLinux من المستخدمين إعادة التشغيل ثم التأكد من الإصدار باستخدامuname -r[10]. - قارن بمتتبّع الجهة المورّدة. ابحث عن CVE-2026-98432 في صفحة الأمان الخاصة بتوزيعتك. إذ تُدرج كل من Red Hat [7] وUbuntu [8] وDebian [9] وAlmaLinux [10] إصدارات الحزم التي تتضمن الإصلاح.
- افحص MPTCP. يُظهر الأمر
sysctl net.mptcp.enabledما إذا كان MPTCP مفعّلًا. ويسرد الأمرsudo ss -lnMpمُنصتات MPTCP والعمليات التي تملكها [10]. وتقترح Akamai أيضًا فحصnet.ipv4.tcp_migrate_req[11]. - ابحث عن خدمات Go. البرامج المبنية بالإصدار Go 1.24 أو أحدث تفتح مُنصتات MPTCP افتراضيًا على Linux [5]. ولذلك قد تكشف أي خدمة Go تشغّلها المسار الذي استغلته Anthropic.
- افحص المنتجات المبنية فوق النواة. تحذّر Red Hat من أن أي منتج مبني على نواة RHEL، بما في ذلك OpenShift وOpenStack وRed Hat Virtualization، قد يكون متأثرًا كذلك [6].
كيف تُصلح الثغرة CVE-2026-98432 أو تخفف أثرها؟
الإصلاح الحقيقي هو نواة مُصحَّحة. إذ تصف Red Hat تطبيق تحديثات النواة بأنه الحل الكامل الوحيد [6]، ويقول فريق أمن Go إن أفضل إصلاح هو الترقية إلى نواة مُصحَّحة [5]. ثبّت تحديث النواة الخاص بتوزيعتك، وأعد التشغيل، وتأكد من الإصدار العامل.
ماذا تفعل قبل وصول التصحيح؟
- أسقِط حزم TCP التي تحمل خيارات IPv4. تنشر Red Hat، ويُدرج متتبّع Ubuntu بوصفه حلًا التفافيًا ساهم به المستخدمون، قاعدةً في nftables تُسقط حزم IPv4 TCP الواردة التي تزيد ترويسة IP فيها على 20 بايت الأساسية، أي الحزم الحاملة لخيارات (
ip hdrlength > 5) [6][8]. أما خيارات TCP العادية مثل الطوابع الزمنية وتوسيع النافذة فتقع في ترويسة TCP ولا تتأثر [8]. وتقول الجهتان كلتاهما إن القاعدة تقلل الخطر لكنها لا تستطيع منع الاستغلال منعًا تامًا [6][8]. - اعرف حدود القاعدة. تشير AlmaLinux إلى أن النسخة التي تقدمها لا تبقى بعد إعادة التشغيل، وأن حركة المرور بين الحاويات على المضيف نفسه قد تتجاوزها، وأنها تُسقط أيضًا الحزم المُمرَّرة على المضيفات التي تعمل موجّهات، وأنها تعطّل الشبكات التي تعتمد على وسوم CIPSO/NetLabel [10]. وتشير Ubuntu إلى أن الحاويات ذات الشبكات المستقلة تحتاج إلى تطبيق القاعدة عليها بشكل منفصل [8].
- عطّل MPTCP إن لم تكن بحاجة إليه. يؤدي ضبط
net.mptcp.enabled=0إلى إيقاف MPTCP على مستوى النظام كله [10]. وتقترح Akamai أيضًا ضبطnet.ipv4.tcp_migrate_req=0[11]. وتحذّر Akamai من أن تعطيل MPTCP وحده لا يمنع الاستغلال، بل يقلل فقط فرصة إطلاق السباق [11]. ويمكن لبرامج Go كذلك الانسحاب عبرGODEBUG=multipathtcp=0، لكن فريق Go يصف الانسحاب على مستوى كل برنامج بأنه هش [5]. - رشّح الحركة عند الحافة. بالنسبة إلى OpenShift، تشير Red Hat إلى أن القواعد المطبّقة على العقدة لا ترشّح الحركة بين الكبسولات (pods)، في حين يتجنب الترشيح عند حدود الشبكة أمام العنقود هذا القيد [6].
هل يفيد الخيار init_on_free=1؟
اقترح منشور في قائمة oss-security خيار الإقلاع init_on_free=1 حلًا مؤقتًا إضافيًا. فردّ أحد أعضاء فريق النواة في شركة CIQ بأنه لا يخفف هذه الثغرة تخفيفًا يُعتدّ به، ولا ينبغي أن يُعطى وزنًا في النشرات الأمنية [12]. تعامل معه على أنه تقوية عامة للنظام، لا تخفيف لهذا الخلل.
هل تُستغل الثغرة CVE-2026-98432 فعليًا؟
حتى 3 نوفمبر 2026، لا تظهر CVE-2026-98432 في فهرس الثغرات المستغلة المعروفة لدى وكالة CISA، وهو قائمة الحكومة الأمريكية بالثغرات التي ثبت استغلالها في الواقع [14]. وقالت Akamai في 2 نوفمبر 2026 إنها لا تعلم بوجود استغلال عامّ فعّال [11]. لكن ذلك ليس دليلًا على أن أحدًا لا يستغل الخلل؛ فقد ثبت وجود استغلال موثوق [4]، والتفاصيل التقنية منشورة علنًا في إصلاح النواة [3].
كما تغيّرت صورة الخطورة مع مرور الوقت. فقد نُشرت الثغرة أول مرة في 15 أكتوبر 2026 [1]، ثم اتسع الاهتمام بها بعد تقرير Anthropic في 27 أكتوبر [4][11]، وتلت ذلك نشرات الجهات المورّدة المتضمنة تدابير تخفيف مؤقتة بين 29 أكتوبر و2 نوفمبر [5][6][10]. ولعل المسؤولين الذين اكتفوا بتصفح السجل الأصلي قد فاتتهم الإرشادات اللاحقة.
ماذا بعد؟
تصف Red Hat تحقيقها بأنه مستمر، وتقول إن نشرتها ستُحدَّث كلما ظهرت معلومات جديدة [6]. ويُتوقع أن تتلقى الحزم المتبقية إصلاحات خلال الأيام أو الأسابيع المقبلة، مثل نواة الزمن الحقيقي في RHEL 9 وصور OpenShift [7] وأنوية Ubuntu التي ما زالت قيد العمل [8]. راجع متتبّعات الجهات المورّدة لا الملخصات الإخبارية، لأن هذه الصفحات تغيّرت عدة مرات في الأسابيع الأولى.
ويترك إصلاح النواة أيضًا مشكلة ذات صلة مفتوحة. إذ يقول وصف النواة إن الدالة tcp_v6_reqsk_destructor() في IPv6 تعاني مشكلة الترحيل نفسها مع الخيارات التي يضبطها CALIPSO وحده، وإن ذلك سيُعالَج في تصحيح منفصل [2]. وبموجب سياسة الإفصاح المنسّق لدى Anthropic، تمنح الشركة 90 يومًا للتصحيح ثم 45 يومًا إضافية قبل مناقشة أي تفاصيل تتجاوز النشرة العامة [4]. ولذلك قد تظهر تفاصيل تقنية أكثر لاحقًا.
هذه معلومات تقنية عامة، وليست بديلًا عن النشرة الأمنية للجهة المورّدة أو عن إجراءات الاستجابة للحوادث في مؤسستك.
| النواة أو التوزيعة | الإصدار المُصلَح أو الحالة | ملاحظات |
|---|---|---|
| الفروع المستقرة الأصلية 5.10 / 5.15 / 6.1 | 5.10.272 و5.15.223 و6.1.190 [2] | ظهر الخلل في الإصدار 4.4 [2] |
| الفروع المستقرة الأصلية 6.6 / 6.12 / 6.18 | 6.6.159 و6.12.113 و6.18.56 [2] | نُقل الإصلاح إلى الفروع التي تحظى بالصيانة [4] |
| الإصدار الأصلي 7.2 / النواة الرئيسية | 7.2.10 و7.3 [2] | أودِع إصلاح النواة الرئيسية في 5 أكتوبر 2026 [3] |
| Red Hat Enterprise Linux 8 / 9 / 10 | صدرت أنوية مُصلَحة في 1 نوفمبر 2026 [7] | ما زالت kernel-rt في RHEL 9 وOpenShift مدرجة على أنها متأثرة [7] |
| Ubuntu 22.04 و24.04 و26.04 و26.10 | معرّضة، والإصلاح قيد العمل [8] | أولوية Ubuntu: حرجة [8] |
| Debian 12 و13 | 6.1.190-1 و6.12.113-1~deb12u1 (12)؛ 6.12.113-1 (13) [9] | أُصلحت عبر DLA-4841-1 وDLA-4850-1 وDSA-6568-1 [9] |
| AlmaLinux 8 / 9 / 10 | أنوية مُصلَحة في مستودعات الإنتاج [10] | MPTCP معطّل افتراضيًا، لكن الإصلاح يظل ضروريًا [10] |
أخطاء شائعة
تثبيت حزمة النواة دون إعادة التشغيل
الصواب: تبقى النواة القديمة عاملة حتى إعادة التشغيل. أعد التشغيل، ثم تأكد من الإصدار العامل باستخدام uname -r، كما تنصح AlmaLinux [10].
افتراض أن الخادم آمن لأن MPTCP معطّل
الصواب: تقول Red Hat إن MPTCP ليس شرطًا لازمًا وإن الأنظمة التي عُطّل فيها تبقى متأثرة [6]. وتقول Akamai إن تعطيل MPTCP لا يفعل سوى تقليل فرصة إطلاق السباق [11]. صحّح النواة.
اعتبار قاعدة nftables إصلاحًا
الصواب: تقول Red Hat وUbuntu كلتاهما إن قاعدة خيارات IPv4 تقلل التعرض لكنها لا تستطيع منع الاستغلال منعًا تامًا [6][8]. استخدمها فقط إلى أن تُثبَّت نواة مُصلَحة، ثم أزلها كما تصف Red Hat [6].
مقارنة أرقام إصدارات المصدر الأصلي بأنوية التوزيعات
الصواب: تنقل التوزيعات الإصلاحات تحت أرقام إصدارات خاصة بها. ابحث عن الثغرة في متتبّع الجهة المورّدة لك، مثل متتبّع Red Hat [7] أو Ubuntu [8] أو Debian [9].
نسيان الحاويات والعناقيد
الصواب: قد تتجاوز حركة المرور بين الحاويات على المضيف نفسه قواعد الجدار الناري للمضيف [10]، كما أن قواعد عُقد OpenShift لا ترشّح الحركة بين الكبسولات [6]. صحّح نواة المضيف، لأن الحاويات تتشاركها.
الأسئلة الشائعة
هل الثغرة CVE-2026-98432 حقيقية، وما مدى خطورتها؟
نعم. إنها سجل CVE منشور من فريق CVE الخاص بنواة Linux، بتاريخ 15 أكتوبر 2026، بدرجة CVSS 3.1 قدرها 9.8 (حرجة) [1]. كما تصنّفها Red Hat [7] وUbuntu [8] حرجة.
هل تؤثر CVE-2026-98432 في حاسوبي المنزلي أو هاتفي؟
تقول Red Hat إن الأنظمة الأكثر تعرضًا بشكل مباشر هي تلك التي تقبل اتصالات TCP واردة [6]، وهي في الغالب الخوادم. ونشرة Android الصادرة في 2 نوفمبر 2026 لا تُدرج هذه الثغرة [13]. وفي كل الأحوال، ثبّت تحديثات الجهة المورّدة.
هل يجب أن يكون MPTCP مفعّلًا حتى يكون النظام معرّضًا؟
لا. فقد استخدم استغلال Anthropic مُنصت MPTCP [4]، لكن Red Hat تقول إن MPTCP ليس شرطًا لازمًا [6]، ويقول فريق أمن Go إن الخلل الأساسي غير مقصور على MPTCP [5].
ما إصدارات نواة Linux التي تُصلح CVE-2026-98432؟
إصلاحات المصدر الأصلي موجودة في 5.10.272 و5.15.223 و6.1.190 و6.6.159 و6.12.113 و6.18.56 و7.2.10 و7.3 [2]. أما أنوية التوزيعات فتستخدم أرقامًا خاصة بها، لذا راجع النشرة الأمنية لجهتك المورّدة [7][8][9].
هل يوجد استغلال عامّ للثغرة CVE-2026-98432؟
وصفت Anthropic إثبات مفهوم فعّالًا لكنها لم تنشره [4][11]. وحتى 2 نوفمبر 2026، لم تكن Akamai على علم باستغلال عامّ فعّال [11]، وحتى 3 نوفمبر لم تكن الثغرة مدرجة في فهرس KEV لدى CISA [14].
هل يتأثر IPv6؟
لا يتأثر بالمشكلة الرئيسية. إذ يقول وصف النواة إن IPv6 ينسخ الخيارات بدلًا من نقلها، لكنه يشير إلى مشكلة ترحيل ذات صلة مع خيارات CALIPSO ستُصلَح في تصحيح منفصل [2].
مسرد المصطلحات
- CVE
- الثغرات والتعرضات الشائعة (Common Vulnerabilities and Exposures): معرّف عام لخلل أمني محدد وموثّق، مثل CVE-2026-98432 [1].
- الاستخدام بعد التحرير (Use-after-free)
- خلل في سلامة الذاكرة يواصل فيه البرنامج استخدام الذاكرة بعد تحريرها، فقد تكون قد صارت تحمل بيانات أخرى.
- CVSS
- نظام تقييم الثغرات الشائعة (Common Vulnerability Scoring System): درجة خطورة من 0 إلى 10؛ والدرجة 9.8 تقع في فئة الحرجة [1].
- MPTCP
- بروتوكول TCP متعدد المسارات (Multipath TCP): امتداد يتيح لاتصال TCP واحد استخدام عدة مسارات شبكية. ويفعّله Go 1.24 والإصدارات الأحدث افتراضيًا لمقابس الاستماع على Linux [5].
- خيارات IPv4
- حقول اختيارية في ترويسة IPv4، مثل تسجيل المسار والطابع الزمني، يمكن للمهاجم وضعها في حزمة SYN للوصول إلى الشيفرة المعرّضة [1].
- KASLR
- التوزيع العشوائي لتخطيط فضاء عناوين النواة (Kernel Address Space Layout Randomisation): آلية دفاعية تضع النواة في عنوان ذاكرة لا يمكن التنبؤ به. ويبدأ استغلال Anthropic بتسريب مؤشر لتجاوزها [4].
- RCU
- القراءة والنسخ والتحديث (Read-copy-update): تقنية في النواة تؤخر تحرير الذاكرة إلى أن يتأكد أنه لم يعد هناك قارئ يستخدمها. ويحوّل الإصلاح عمليتي تحرير إلى kfree_rcu() [2].
المصادر
- CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period CVE Program (record assigned by the Linux kernel CNA) · 2026-10-15
- CVE-2026-98432 announcement: description, severity and affected/fixed versions Linux kernel CVE team (kernel.org) · 2026-10-15
- ipv4: free inet_opt and ireq_opt after an RCU grace period (mainline commit e3f33b0a1d89) Linux kernel source tree (kernel.org) · 2026-10-05
- Discovering vulnerabilities with Claude Anthropic · 2026-10-27
- Fwd: Protecting against CVE-2026-98432 when using Go programs (Go Security Team announcement) oss-security mailing list (Openwall) · 2026-10-30
- RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432) Red Hat Product Security · 2026-10-30
- CVE-2026-98432 (Red Hat CVE database: severity, statement and affected packages) Red Hat; live page, retrieved 2026-11-03 · 2026-10-15
- CVE-2026-98432 | Ubuntu Canonical Ubuntu Security; live page, retrieved 2026-11-03 · 2026-10-15
- CVE-2026-98432 (Debian Security Bug Tracker) Debian Security Team; live page, retrieved 2026-11-03
- CVE-2026-98432: fixed kernels and interim mitigations for AlmaLinux AlmaLinux OS Foundation (Andrew Lukoshko) · 2026-10-30
- CVE-2026-98432: A Remote Use-After-Free in the Linux Kernel's TCP Stack Akamai Security Intelligence Group · 2026-11-02
- Re: CVE-2026-98432: init_on_free=1 as an additional interim mitigation oss-security mailing list (Openwall) · 2026-11-03
- Android Security Bulletin, November 2026 Android Open Source Project (Google) · 2026-11-02
- Known Exploited Vulnerabilities Catalog US Cybersecurity and Infrastructure Security Agency (CISA); checked 2026-11-03
التعليقات
أبرز التعليقات