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

الملخص

بحسب VulDB • 30/05/2026

فيما يلي تحليل مفصل للخطأ (Kernel Panic) المرفق، مع التركيز على السبب الجذري (Root Cause) وكيفية حدوثه بناءً على السجلات والوصف المقدم.

### 1. ملخص الخطأ حدث **Kernel Panic** بسبب استثناء قاتل (Fatal Exception) أثناء تنفيذ中断 (Interrupt)، وتحديداً في سياق معالجة حزم الشبكة عبر `net_rx_action`.

المؤشر الرئيسي هو: ``` Krnl Code: ... illegal Last Breaking-Event-Address: [] __napi_poll+0x4c/0x1d8
``` هذا يعني أن المعالج حاول تنفيذ تعليمات غير صالحة (Illegal Instruction) عند عنوان ذاكرة `0x0000000000000000` أو عنوان قريب جداً منه، أثناء استدعاء دالة `__napi_poll`.

---

### 2. التحليل التقني للسبب الجذري

#### أ. السياق: نظام qeth على s390 الخطأ يحدث في دريفر الشبكة `af_iucv` و `qeth` على معالجات IBM Z (s390x). الدالة `__napi_poll` هي جزء من آلية NAPI (New API) المستخدمة لتحسين أداء استقبال الحزم في Linux.

#### ب. المشكلة: مؤشر دالة فارغ (NULL Function Pointer) في سجلات الخطأ: ``` [ 2057.572801] [] net_rx_action+0x2ba/0x398
[ 2057.572809] [] __do_softirq+0x11e/0x3a0
... [ 2057.572843] Last Breaking-Event-Address:
[ 2057.572844] [] __napi_poll+0x4c/0x1d8
``` عندما يستدعي `net_rx_action` دالة `poll` الخاصة بـ NAPI، فإنه يفعل ذلك عبر مؤشر دالة (`napi->poll`). إذا كان هذا المؤشر `NULL`، فإن المعالج يحاول القفز إلى عنوان `0x0`، مما يؤدي إلى تنفيذ تعليمات غير صالحة (Illegal Instruction) أو Crash.

#### ج. السبب المباشر: عدم إعادة تعيين `napi.poll` بعد إعادة التشغيل الوصف المقدم يوضح السبب بدقة:

1. **قبل التعديل (Commit 1cfef80d4c2b):** * عند إيقاف الكارت (`qeth_set_offline`)، كان يتم استدعاء `dev_close()`. * عند إعادة تشغيل الكارت (`qeth_set_online`)، كان يتم استدعاء `dev_open()`. * دالة `dev_open()` كانت تستدعي `qeth_open()`، والتي كانت تعيد تعيين `card->qdio.out_qs[i].napi.poll` بشكل صحيح.

2. **بعد التعديل (Commit 1cfef80d4c2b):** * تم تغيير السلوك بحيث لا يتم استدعاء `dev_close()/dev_open()` أثناء التبديل بين حالة Online/Offline. * عندما يتم إيقاف الكارت (`qeth_set_offline`)، يتم استدعاء `qeth_free_qdio_queues()`، والتي **تمسح** (تجعلها NULL) مؤشر `napi.poll`. * إذا كان الواجهة الشبكية (`network interface`) لا تزال في حالة `UP` أثناء إيقاف الكارت، فإن مؤشر `napi.poll` يبقى `NULL`. * عند إعادة تشغيل الكارت (`qeth_set_online`)، **لا يتم استدعاء `qeth_open()`**، وبالتالي لا يتم إعادة تعيين `napi.poll`. * النتيجة: يبقى `napi.poll` كـ `NULL` بينما الواجهة لا تزال `UP`.

3. **تفعيل الخطأ:** * عندما تصل حزمة شبكة وتحتاج إلى معالجة، يستدعي النظام `net_rx_action`. * تستدعي `net_rx_action` `__napi_poll`. * يحاول `__napi_poll` استدعاء الدالة المؤشرة بواسطة `napi->poll`. * بما أن المؤشر `NULL`، يحدث Crash.

---

### 3. سيناريو إعادة الإنتاج (Reproduction Steps)

كما هو موضح في الوصف:

1. **إعداد البيئة:** ```bash chzdev -e $devno layer2=0 ip link set dev $network_interface up ``` * هنا، الواجهة الشبكية في حالة `UP`.

2. **إيقاف

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

المصادر

Do you know our Splunk app?

Download it now for free!