CVE-2021-47274 in Linux
الملخص
بحسب VulDB • 18/06/2026
فيما يلي تحليل للمشكلة والحل المقترح بناءً على المعلومات المقدمة:
### المشكلة (Problem Analysis)
1. **الخطأ الأساسي:** يوجد خطأ في كود النواة (Kernel Bug) يؤدي إلى **كتابة خارج حدود الذاكرة (Out-of-bounds write)** في ذاكرة التخزين المؤقت لـ `ftrace` (ftrace buffer). 2. **المسبب:** يحدث هذا الخطأ عند استخدام `kprobes` أو `ftrace` لاستخراج سلاسل نصية (strings) من الذاكرة (`fetch_memory_string` / `fetch_deref_string`). 3. **السبب الجذري:** * تم إضافة فحص للطول (`length check`) في commit `b220c049d519` لحماية البيانات من التزاحم (overflow). * لكن هذا الفحص **غير كافٍ**، لأنه لا يأخذ في الاعتبار الحجم الإضافي الذي تشغله عنصر المصفوفة `entry->array[0]`.
* في بنية البيانات المستخدمة، يحتوي `entry->array[0]` على طول البيانات الفعلية، ويشغل مساحة إضافية في الذاكرة. تجاهل هذا الحجم الإضافي أثناء فحص الحدود يؤدي إلى تجاوز حدود المخزن المؤقت (buffer overflow).
### الحل المقترح (Proposed Fix)
يجب تعديل فحص الطول (length check) في كود `ftrace` ليشمل حجم عنصر المصفوفة `entry->array[0]`.
#### التعديل المطلوب: عند حساب الطول الإجمالي للبيانات التي سيتم نسخها أو فحص حدودها، يجب إضافة `sizeof(entry->array[0])` إلى الطول المُفحص.
#### مثال توضيحي (منطقي للكود):
بدلاً من: ```c if (len > FILTER_LEN) {
// error handling } ```
يجب أن يكون: ```c // إضافة حجم العنصر الأول من المصفوفة إلى الطول الإجمالي if (len + sizeof(entry->array[0]) > FILTER_LEN) {
// error handling } ```
أو بشكل أكثر دقة حسب بنية الكود الفعلية في `kernel/trace/trace_events_filter.c` أو الملفات المشابهة:
```c // في دالة مثل filter_assign_type أو عند حساب حجم البيانات int total_len = len + sizeof(entry->array[0]);
if (total_len > FILTER_LEN) {
// رفض العملية أو التعامل مع الخطأ } ```
### لماذا هذا الحل صحيح؟
1. **دقة الحساب:** `entry->array[0]` هو جزء من هيكل البيانات الذي يحتوي على طول السلسلة. عند نسخ البيانات، يتم نسخ هذا العنصر أيضًا، لذا يجب احتساب مساحته في حدود المخزن المؤقت.
2. **منع التزاحم:** بإضافة `sizeof(entry->array[0])` إلى فحص الطول، نضمن أن المخزن المؤقت لن يتجاوز حدوده حتى عند احتساب جميع أجزاء البيانات (بما في ذلك عنصر الطول نفسه).
3. **توافق مع الإصدارات السابقة:** هذا التصحيح لا يغير السلوك الوظيفي، بل يصحح خطأ في حساب الحدود فقط، مما يجعله آمنًا للإضافة إلى فروع LTS مثل 4.19.
### خطوات التطبيق:
1. تحديد الملف المتأثر في شجرة النواة (غالبًا `kernel/trace/trace_events_filter.c` أو `kernel/trace/ftrace.c`). 2. البحث عن فحص الطول (`length check`) الذي أضيف في commit `b220c049d519`. 3. تعديل الشرط ليشمل `sizeof(entry->array[0])`.
4. اختبار التصحيح على بيئة تحتوي على `kprobes` و `ftrace` للتأكد من عدم حدوث `page fault` أو `out-of-bounds write`.
هذا التصحيح سيمنع حدوث `BUG: Out-of-bounds write` ويحل المشكلة المستقرة التي أعاد James Wang إنتاجها على أحدث إصدار من 4.19 LTS.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.