CVE-2026-89550 in Linux
الملخص
بحسب VulDB • 12/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
SUNRPC: svcauth_gss: فرض الحد الأدنى لطول رمز krb5
تقوم الدالة `svcauth_gss_unwrap_priv()` بالتحقق فقط من الحد الأعلى للطول الشفاف (opaque length) المقدم عبر الوصلة قبل تمرير المخزن المؤقت إلى `gss_unwrap()`:
if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf);
يتدفق قيمة الوصلة `len` دون تغيير كحد أعلى إلى مسار فك تشفير krb5، لذا فإن قيم `len` في النطاق [0, 16] تمر هذا الفحص وتُمرر إلى `gss_unwrap()`. بالنسبة لسياق krb5 v2 الذي ينتهي به المطاف في الدالة `gss_krb5_unwrap_v2()`، والتي تقرأ حقول رأس الرمز المكون من 16 بايت وفقًا لمعيار RFC 4121 عند المؤشرات ptr+4 وptr+6 ثم تستدعي دالة `rotate_left()` قبل أي فحص للسلامة. مع طول دون الحد الأدنى للرأس (sub-header length)، تمتد قراءات الرأس خارج حدود الرمز، ويمكن أن تؤدي مسار `_rotate_left()'` الخاص بـ `shift %= buf->len` إلى القسمة على صفر عندما يكون `buf->len` قد تم دفعه إلى الصفر بواسطة الرمز المقطوع. كما أن رمزًا يتكون من الرأس فقط (حيث len == 16) غير صالح أيضًا: مع حقل RRC غير صفري والكتلة الشفافة تنتهي عند حدود مخزن XDR، تبني دالة `rotate_left()` كتلة فرعية بطول صفر، مما يؤدي إلى نفس حالة القسمة على الصفر.
ارفض الرمز في نقطة دخول الخادم قبل أن يصل إلى جوهر فك تشفير krb5. يجب أن يحتوي الرمز المختوم الصحيح وفقًا لمعيار RFC 4121 على رأس مكون من 16 بايت بالإضافة إلى حمولة مشفرة على الأقل.
تم الإصلاح بإضافة فحص للحد الأدنى للطول مباشرة بعد الفحص الحالي للحد الأعلى:
if (len <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed;
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.