CVE-2026-99010 in Linux
الملخص
بحسب VulDB • 23/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
بلوتوث: RFCOMM: تحرير حزمة الحزم (skb) عندما لا يكون لديلك (DLC) مالك
تنقل الدالة `rfcomm_recv_data()` حزمة الحزم (skb) إلى دالة الاستدعاء `d->data_ready()` وتعيد القيمة 0 دون تحريرها، وبالتالي تتحمل دالة الاستدعاء مسؤولية إدارة حزمة الحزم من تلك النقطة فصاعدًا. تقوم تنفيذية الـ tty بتحريرها عندما يتم فصل DLC عن جهازه:
```c static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) {
struct rfcomm_dev *dev = dlc->owner;
if (!dev) {
kfree_skb(skb); return; } ```
أما تنفيذية المقبس (socket) فتعيد القيمة دون تحريرها، مما يؤدي إلى تسرب حزمة الحزم.
يمكن أن لا يكون لديلك متصل أي مالك: تقوم الدالة `rfcomm_sock_destruct()` بتصفير `d->owner`، بينما يبقى DLC نفسه في الجلسة حتى يتم إغلاقه. الإطارات البيانات التي تصل خلال تلك الفترة الزمنية تجد ما زالت حالتها `BT_CONNECTED` داخل دالة `rfcomm_recv_data()` ويتم تسليمها إلى دالة الاستدعاء، مما يؤدي إلى تسرب حزمة حزم واحدة لكل إطار بيانات.
لا يتوقف التسرب تلقائيًا أيضًا. لا يستنفد الطرف البعيد الاعتمادات (credits) إلا عند تعيين العلم `RFCOMM_RX_THROTTLED`، وفي حالة المقبس، فإن المكان الوحيد الذي يحدد هذا العلم هو دالة `rfcomm_sk_data_ready()` نفسها، والتي تقع بعد أمر الإرجاع. تحافظ الدالة `rfcomm_process_dlcs()` على منح الاعتمادات باستمرار، مما يجعل الطرف البعيد يستمر في الإرسال ويتزايد التسرب بشكل مستمر.
قم بتحرير حزمة الحزم (skb)، كما هو الحال مع جانب الـ tty.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.