Xuedugu

**اسم البرنامج المصاب والإصدارات المتأثرة** D-Link E15 (الإصدارات المتأثرة غير محددة) D-Link M32 (الإصدارات المتأثرة غير محددة) D-Link R15 (الإصدارات المتأثرة غير محددة) D-Link R32 (الإصدارات المتأثرة غير محددة) **Description** يوجد خلل في مكون MQTT Broker بسبب المعالجة غير الصحيحة للملف `/etc/emDaemon/passwd`. يؤدي هذا الأمر إلى وجود بيانات اعتماد مدمجة (hard-coded)، مما يسمح للمهاجم بتنفيذ هجوم عن بُعد. **Recommendations** في الوقت الحالي، لا توجد معلومات حول إصدار أحدث يحتوي على إصلاح لهذه الثغرة.

**Name of the Vulnerable Software and Affected Versions** Zephyr (affected versions not specified) **Description** In CONFIG USERSPACE builds, the system-call verifier for `i3c do ccc()` in drivers/i3c/i3c handlers.c fails to validate per-target data buffers within the `i3c ccc target payload` structure. Specifically, the data pointer and `data len` are not processed through `K SYSCALL MEMORY()` before being passed to `z impl i3c do ccc()` and the controller driver. Additionally, the verifier uses the caller's live structure instead of a snapshot, allowing a second user thread to modify validated fields between the check and the driver's execution. An unprivileged user-mode thread with access to the I3C controller device object can provide an arbitrary kernel address as a target payload data pointer. This allows a read CCC to write bus-received bytes into an attacker-chosen kernel address or a write CCC to transmit kernel memory onto the I3C bus, leading to out-of-bounds kernel write and kernel memory disclosure, which can result in privilege escalation to supervisor level. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Zephyr (affected versions not specified) **Description** The SMBus driver API exposes `smbus smbalert remove cb()` and `smbus host notify remove cb()` as syscalls. The verifiers for these syscalls only validate the `dev` argument and fail to perform memory read or write validation on the caller-supplied `cb` pointer. In builds where `CONFIG USERSPACE=y` and `CONFIG SMBUS=y` are enabled, along with specific drivers (such as `intel pch smbus.c` or `smbus stm32.c`), an unprivileged user-mode thread with access to the SMBus device object can provide an arbitrary pointer to these syscalls. This allows the thread to unregister SMBALERT or Host Notify callbacks registered by supervisor-mode components, effectively disabling alert handling for the system. Additionally, in builds with `CONFIG ASSERT=y`, providing a bogus pointer can trigger a kernel-mode fault and a fatal system error, which may be used to disclose mapped addresses. **Recommendations** Remove the syscall entry points for `smbus smbalert remove cb()` and `smbus host notify remove cb()` and convert them into static inline calls to ensure callback list manipulation is restricted to supervisor-mode code.

**Name of the Vulnerable Software and Affected Versions** RTIO versions prior to 4.3.0 **Description** The userspace verifier function `z vrfy rtio sqe copy in get handles()` in `subsys/rtio/rtio syscalls.c` (and `subsys/rtio/rtio handlers.c` in earlier versions) fails to validate the `handle` out-parameter. This allows a user-mode thread with a `struct rtio` kernel object to provide an arbitrary address in the `handle` parameter. Because the system stores the kernel address of a submission-queue entry (SQE) through this pointer in supervisor mode without a `K SYSCALL MEMORY WRITE` check, it creates a write-what-where primitive. An attacker can use this to place a pointer to attacker-controlled data at any kernel address, potentially corrupting kernel function pointers, thread structures, or memory-domain partition tables. This can lead to kernel memory corruption, system crashes, or privilege escalation from user mode to kernel mode. This issue specifically affects builds configured with `CONFIG USERSPACE` and `CONFIG RTIO`. **Recommendations** Update to version 4.3.0 or later to ensure the `K SYSCALL MEMORY WRITE` check is implemented for the `handle` parameter.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** عميل OCPP 1.6 (لم يتم تحديد الإصدارات المتأثرة) **الوصف** يوجد تجاوز سعة مخزن المكدس في الدالة `parse getconfig msg()` الموجودة في الملف `subsys/net/lib/ocpp/ocpp j.c`. تحدث المشكلة عندما يقوم المعالج بمعالجة طلب GetConfiguration من نظام مركزي ويستخدم دالة `strcpy()` غير محدودة لنسخ سلسلة `key` بتنسيق JSON يسيطر عليها المهاجم إلى مخزن مؤقت ثابت سعة 50 بايت `skey[CISTR50]` الموجود في `subsys/net/lib/ocpp/ocpp.c`. ونظرًا لأن طول قيمة `key` لا يقتصر إلا على حجم مخزن الاستقبال (`CONFIG OCPP RECV BUFFER SIZE`)، يمكن للمهاجم الذي يتحكم في نقطة نهاية النظام المركزي أو الذي ينفذ هجومًا من نوع «الرجل في الوسط» (man-in-the-middle) على اتصال غير مشفر أن يرسل طلبًا يحتوي على حقل `key` يتجاوز 50 بايت. قد يؤدي ذلك إلى حدوث «تحطيم المكدس» (stack smash) في مؤشر ترابط القارئ `ocpp wsreader()`، مما يؤدي إلى رفض الخدمة أو احتمال تنفيذ تعليمات برمجية عن بُعد. **التوصيات** استبدل الدالة `strcpy()` بدالة محدودة `strncpy(key, payload.key[0], CISTR50 - 1)` وتأكد من إنهاء السلسلة صراحةً بحرف NUL.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** Zephyr الإصدار 4.3.0 Zephyr الإصدار 4.4.0 **الوصف** يفشل مُحلل DNS الموجود في `subsys/net/lib/dns` في التحقق بشكل صحيح من صحة قيمة `rdlength` لسجلات الموارد في استجابات DNS داخل الدالة `dns unpack answer()`. وهذا يسمح بقبول قيمة `rdlength` التي يحددها المهاجم والتي قد تتجاوز نهاية حزمة البيانات المستلمة. وبالتالي، يستخدم مستهلكو TXT و SRV في الدالة `dns validate record()` (الموجودة في `resolve.c`) دالة `memcpy` لقراءة ما يصل إلى `rdlength` بايت من مخزن الاستقبال المؤقت دون إجراء فحص للحدود مقارنةً بحجم الحزمة الفعلي. يمكن لخادم DNS ضار، أو مهاجم على المسار، أو عقدة شبكة محلية (LAN) (في حالة تمكين mDNS/LLMNR) صياغة استجابات TXT أو SRV مقطوعة لإحداث قراءة خارج الحدود لذاكرة حوض الاستقبال المجاورة. ويؤدي ذلك إلى تسرب للمعلومات حيث يتم إرجاع بايتات قديمة من حزم DNS سابقة أو ذاكرة غير مهيأة إلى التطبيق. وفي بعض التكوينات، قد يتسبب هذا أيضًا في حدوث عطل في النظام يؤدي إلى رفض الخدمة. **التوصيات** قم بتحديث إصدار Zephyr 4.3.0 إلى إصدار ترفض فيه الدالة `dns unpack answer()` السجلات التي يتجاوز حجم rdata المعلن فيها `dns msg->msg size`. تحديث إصدار Zephyr 4.4.0 إلى إصدار ترفض فيه الدالة `dns unpack answer()` السجلات التي يتجاوز حجم rdata المعلن فيها `dns msg->msg size`.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Zephyr من 3.0.0 إلى 3.x **الوصف** توجد ثغرة قراءة خارج النطاق في طبقة تكييف ISO لوحدة التحكم في البلوتوث داخل الملف `subsys/bluetooth/controller/ll sw/isoal.c`. تحدث هذه المشكلة لأن الدالة `isoal check seg header()` تفشل في التحقق بشكل صحيح من صحة حقل الطول في مقطع بدء PDU ISO المُؤطَّر. وفقًا لمواصفات Bluetooth، يجب أن يكون طول رأس مقطع البداية 3 بايت على الأقل لاستيعاب `time offset`. وعندما يتم توفير طول يتراوح بين 0 و2، تقوم الدالة `isoal rx framed consume()` بإجراء عملية طرح تؤدي إلى انخفاض القيمة عن الحد الأدنى للعدد الصحيح، مما ينتج عنه قيمة طول أكبر من المسموح به. ثم يتم تمرير هذه القيمة إلى `isoal rx append to sdu()`، التي تنسخ ما يصل إلى 255 بايت من ذاكرة وحدة التحكم خارج نطاق وحدة PDU المستلمة إلى حزمة بيانات HCI ISO. يمكن لمهاجم عن بُعد تشغيل هذه الثغرة عبر مسارات بيانات HCI CIS أو BIS-sync أو مسار بيانات المورد، مما يؤدي إلى كشف المعلومات للمضيف أو حدوث رفض الخدمة. **التوصيات** تحديث Zephyr إلى إصدار ترفض فيه الدالة `isoal check seg header()` المقاطع الأولية التي يقل طولها عن 3، ويتم تنفيذ آلية حماية قبل عملية الطرح في الدالة `isoal rx framed consume()`.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** Zephyr (لم يتم تحديد الإصدارات المتأثرة) **الوصف** يفشل محلل إدخالات الدليل في نظام الملفات ext2 في التحقق بشكل كامل من صحة بنية إدخال الدليل الموجود على القرص قبل نسخ اسم الإدخال والمضي قدمًا في حالة التصفح. وعلى وجه التحديد، في الدالة `ext2 fetch direntry()`، يتحقق النظام مما إذا كان `de name len` أقل من أو يساوي `EXT2 MAX FILE NAME`، لكنه لا يتحقق من العلاقة الهيكلية بين `de rec len` و`de name len` وحدود كتلة الدليل. ويشمل ذلك الفشل في التحقق من أن `de rec len` غير صفر، وأنه يساوي على الأقل حجم رأس المدخل، وأن السجل يتناسب مع حجم الكتلة. ثم تستخدم دوال مثل `find dir entry()` و`ext2 get direntry()` قيمة `de rec len` غير المصادق عليها للمضي قدمًا في عملية التصفح. يمكن لصورة ext2 مصممة خصيصًا أن تؤدي إلى قراءة خارج النطاق من مخزن بلوك الدليل عبر نسخة اسم كبيرة الحجم أو أن تتسبب في حلقة لا نهائية إذا كانت قيمة `de rec len` تساوي صفرًا. تحدث هذه المشكلة أثناء مسارات اجتياز الدليل، بما في ذلك البحث عن اسم المسار، وstat، وopen، وunlink، وrename، وreaddir، مما قد يؤدي إلى رفض الخدمة وقراءات خارج النطاق عند تركيب وسائط غير موثوق بها. **التوصيات** في الوقت الحالي، لا توجد معلومات حول إصدار أحدث يحتوي على إصلاح لهذه الثغرة الأمنية.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Zephyr من 1.7 إلى 4.4.0 **الوصف** يحتوي محلل دور «Hands-Free» في ملف تعريف «Bluetooth Classic Hands-Free Profile» (HFP) الموجود في `subsys/bluetooth/host/classic/hfp hf.c` على عملية كتابة خارج نطاق الذاكرة. أثناء إعداد اتصال مستوى الخدمة (Service Level Connection)، ترسل وحدة «التحرر من استخدام اليدين» (Hands-Free: HF) الأمر `AT+CIND=?` وتقوم بتحليل استجابة بوابة المرافق (Attendant Gateway: AG) في الدالة `cind handle()`، التي تخصص مؤشر عداد لكل إدخال وتستدعي الدالة `cind handle values()` لكل عنصر في القائمة. تقوم الدالة `cind handle values()` بالكتابة إلى `hf-ind table[index]` دون التحقق من أن `index` يقع ضمن مصفوفة `int8 t ind table[]` المكونة من 20 عنصرًا في `struct bt hfp hf`. نظرًا لأن المحلل لا يحدد عدد إدخالات قائمة `+CIND:`، يمكن لبوابة Attendant Gateway عن بُعد إرسال استجابة تحتوي على أكثر من 20 إدخالًا لزيادة قيمة `index` بشكل تعسفي. وهذا يسمح بكتابة قيم تتجاوز المصفوفة في حقول البنية المجاورة، مثل أقنعة الميزات، وحالة SDP/الإصدار، ومصفوفة `calls[]`، وسجلات العمل/العمليات الذرية، مما قد يؤدي إلى تجاوز فتحة تجمع الاتصالات الثابتة. ينتج عن ذلك تلف في الذاكرة ورفض خدمة مضيف Bluetooth، ويتم تشغيله بواسطة استجابة AT واحدة مشوهة دون تدخل من المستخدم. **التوصيات** قم بتحديث Zephyr إلى إصدار أحدث من 4.4.0. كحل مؤقت، قم بتعطيل `CONFIG BT HFP HF` لتقليل مخاطر الاستغلال.