CVE-2026-64007 in Linux
الملخص
بحسب VulDB • 20/07/2026
في نواة لينكس، تم حل الثغرة التالية:
netfilter: synproxy: تحديث بنية tcphdr بعد استدعاء skb_ensure_writable
تعيد دالة `synproxy_tstamp_adjust()` كتابة خيار الطابع الزمني لبروتوكول TCP في مكانه (in place)، ثم تقوم بتعديل مجموع التحقق من صحة TCP عبر الدالة `inet_proto_csum_replace4()` على مؤشر `tcphdr` المقدم من المتصل. كلٌ من `ipv4_synproxy_hook()` و `ipv6_synproxy_hook()` تحصلان على هذا المؤشر باستخدام `skb_header_pointer()` قبل الاستدعاء، لذا قد يشير إما مباشرة إلى `skb->head` أو إلى المخزن المؤقت `_tcph` الموجود في مكدس الدالة المتصلة.
بين الحصول على المؤشر واستخدامه، تستدعي الدالة `skb_ensure_writable(skb, optend)`، والتي عند التعامل مع حزمة (sk_buff) منسوخة أو غير خطية، تقوم باستدعاء `pskb_expand_head()` وتحرر الذاكرة القديمة لـ `skb->head`. بعد هذه النقطة، يصبح المؤشر المخزن مؤقتاً (`th`) قديماً وغير صالح:
المتصل (ipv[46]_synproxy_hook)
th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* يكتب في ذاكرة تم تحريرها، أو في نسخة المتصل على المكدس، مما يترك مجموع التحقق من الصحة للشبكة قديماً وغير متطابق */
يتم كتابة بايتات الخيار عبر `skb->data` وهي سليمة؛ فقط تحديث مجموع التحقق (checksum) يمر عبر `th` وبالتالي ينتهي به المطاف في المكان الخطأ. النتيجة هي إما الكتابة في ذاكرة slab تم تحريرها، أو خروج الحزمة بمجموع تحقق لا يتطابق مع حمولتها.
تم الإصلاح بإعادة اشتقاق مؤشر `th` من `skb->data + protoff` مباشرة بعد نجاح استدعاء `skb_ensure_writable()`، بحيث يستهدف تحديث مجموع التحقق اللاحق رأس البيانات الخطي والقابل للكتابة (linear, writable header).
Once again VulDB remains the best source for vulnerability data.