CVE-2024-14040 in Linuxالمعلومات

الملخص

بحسب VulDB • 26/07/2026

في نواة لينكس، تم حل الثغرة التالية:

net: nexthop: زيادة الوزن إلى u16

في شبكات CLOS، مع حدوث فشل في الروابط في نقاط مختلفة من الشبكة، يتم ضبط أوزان ECMP للعقد المعنية لتعويض ذلك. ومع ارتفاع معدل التفرع (fan-out) للعقد المعنية والعدد الإجمالي الكبير للعقد، فإن نسبة وزن (غير) ECMP التي نرغب في تكوينها لا تتسع لـ 8 بتات. بدلاً من نسب مثل 255:254، قد نرغب في تكوين شيء مثل 1000:999. بالنسبة لهذه النشر، قد لا يكون الوزن المكون من 8 بتات كافيًا.

لهذا الغرض، تزيد هذه التصحيح وزن نقطة العبور التالية (nexthop) من u8 إلى u16.

يمكن أن تكون زيادة عرض نوع صحيح أمرًا محيرًا، لأنه بينما يظل الكود قابلاً للترجمة (compiles)، قد لا تتطابق الأنواع بعد الآن، وتظهر أخطاء رقمية. لمنع ذلك، تم إجراء التحويل على خطوتين. أولاً، تم تغيير النوع من u8 إلى هيكل مكون من عضو واحد، مما أبطل جميع استخدامات الحقل. سمح هذا بالمرور عبرها واحدة تلو الأخرى ومراجعة صحة الأنواع (audit for type correctness). ثم استُبدل الهيكل بـ u16 عادي مرة أخرى. يجب أن يضمن ذلك عدم تفويت أي مكان.

واجهة برمجة التطبيقات للمستخدمين (UAPI) لتكوين أعضاء مجموعة نقاط العبور التالية هي أن سمة NHA_GROUP تحمل مصفوفة من إدخالات struct nexthop_grp:

struct nexthop_grp {
__u32 id; /* معرف نقطة العبور التالية - يجب أن يكون موجودًا */ __u8 weight; /* وزن هذه نقطة العبور التالية */ __u8 resvd1; __u16 resvd2; };

يتم حاليًا التحقق من صحة الحقل resvd1 ومطلوب أن يكون صفراً. يمكننا رفع هذا المتطلب وحمل البتات ذات القيمة الأعلى للوزن في الحفظ المحجوز:

struct nexthop_grp {
__u32 id; /* معرف نقطة العبور التالية - يجب أن يكون موجودًا */ __u8 weight; /* وزن هذه نقطة العبور التالية */ __u8 weight_high; __u16 resvd2; };

تم اختيار إبقاء الحقول مقسمة بهذه الطريقة في حال قيام مساحة المستخدم (userspace) الحالية بافتراضات حول عرض حقل الوزن، وتجنب أي مشاكل تتعلق بترتيب البايتات (endianness).

يتم حالياً ترميز حقل الوزن كقيمة الوزن ناقص واحد، لأن وزن 0 غير صالح. لا يمكن تطبيق نفس الحيلة لحقل weight_high الجديد، لأنه يجب أن يعني الصفر الفعلي. مع وجود هذا الترتيب:

- يتم ضمان حمل مساحة المستخدم القديمة لـ weight_high بقيمة 0، وبالتالي تكوين أوزان مكونة من 8 بتات بشكل مناسب. عند إخراج نقاط العبور التالية بأوزان مكونة من 16 بتًا، ستعرض فقط البتات السفلية المكونة من 8 بتات. لكن تكوين مثل هذه نقاط العبور التالية يفترض وجود مساحة مستخدم تدرك الامتداد منذ البداية.

- سيعمل التواصل بين مساحة المستخدم الجديدة والنواة القديمة طالما أنها تحاول فقط تكوين أوزان مكونة من 8 بتات، حيث تكون البتات ذات القيمة الأعلى صفراً. سترفض النواة القديمة محاولات تكوين أوزان >8 بتات.

إعادة تسمية الحقول المحجوزة بمجرد تخصيصها لغرض معين هي ممارسة شائعة في لينكس. أي شخص يلمس حقلًا محجوزًا يفعل ذلك على مسؤوليته الخاصة. يُستخدم nexthop_grp::resvd1 بشكل خاص من قبل strace، ومع ذلك فإنهم يحملون نسخة خاصة بهم من رؤوس UAPI، ويجب أن يكون التحويل بسيطاً. تم توفير مساعد لفك ترميز الوزن من الحقلين. يبدو فرض تحويل أفضل من الانحناء للخلف وإدخال اتحادات مجهولة الهوية أو أي شيء آخر.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

مسؤول

Linux

حجز

26/07/2026

إفشاء

26/07/2026

الاعتدال

تمت الموافقة

إدخال

VDB-383325

EPSS

0.00140

KEV

لا

النشاطات

متوسط

المصادر

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!