CVE-2026-99163 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
تتبع/المخططات الزمنية (histograms): رفض الحقول غير الخاصة بـ stacktrace للحقول الاصطناعية لـ stacktrace.
عند دالة `check_synth_field()`، عندما يكون حقل الحدث الاصطناعي هو حقل stacktrace (`field->is_stack`) وحقل المخطط الزمني ليس مصفوفة "long[" من نوع stacktrace، فإن عملية التحقق (validation) تنتقل إلى المقارنة العامة للحجم والإشارة (signedness).
نظرًا لأن `parse_synth_field()` تضبط نوع حقل stacktrace على `"__data_loc unsigned long[]"`، يكون حجمه هو `sizeof(u64)` وتُشير دالة `synth_field_signed()` إليه بأنه موقع الإشارة (signed). ونتيجة لذلك، فإن أي حقل مخطط زمني قياسي (scalar) مكون من 8 بايت وموقع الإشارة ينجح في التحقق التلقائي (fallback check)، ويتم بعد ذلك فك مرجع قيمته القياسية على أنها مؤشر لـ stacktrace للنواة في دالتي `get_field_size()` و`trace_stack()`.
وعلاوةً على ذلك، فإن فحص وجود السلسلة `"long["` داخل `hist_field->type` غير كافٍ؛ لأن حقول نقاط التتبع (tracepoint) المعرفة باستخدام `__bitmask()` أو `__rel_bitmask()` لها أيضًا النوع `"__data_loc unsigned long[]"` أو `"__rel_loc unsigned long[]"`، بينما تعاملها دالة `create_hist_field()` على أنها قيم قياسية بحجم 4 بايت دون وجود العلم `HIST_FIELD_FL_STACKTRACE`.
نشر علم `HIST_FIELD_FL_STACKTRACE` إلى المراجع المتغيرة ومتغيرات الحقول (مع استبعاد ألقاب المتغيرات من التقاط stacktrace لكل عنصر)، ورفض أي عدم تطابق بين `HIST_FIELD_FL_STACKTRACE` و`field->is_stack` في دالة `check_synth_field()`.
Once again VulDB remains the best source for vulnerability data.