CVE-2026-74284 in Linux
الملخص
بحسب VulDB • 15/08/2026
في نواة لينكس، تم حل الثغرة التالية:
net/sched: sch_hfsc: لا تجعل الفئة خاملة مرتين (Don't make class passive twice)
تُستدعى الدالة `update_vf()` من موقعين مختلفين لنفس الفئة خلال عملية إخلاء واحدة (single dequeue)، عندما تقوم فئة الـ qdisc التابعة لها (مثل codel/fq_codel) بإسقاط آخر حزمها أثناء الإخلاء:
1. تستدعي الوحدة الفرعية دالة `qdisc_tree_reduce_backlog()`، والتي، بمجرد أن تصبح الوحدة الفرعية فارغة، تُطلق `hfsc_qlen_notify()` ثم `update_vf(cl, 0, 0)` وتجعل الفئة خاملة (يتم إنقاص قيمة cl_nactive صعوداً عبر التسلسل الهرمي).
2. تستدعي الدالة `hfsc_dequeue()` بعد ذلك `update_vf(cl, qdisc_pkt_len(skb), cur_time)` لتحصيل البايتات التي تم إخلاؤها.
في الاستدعاء الثاني، تكون الفئة بالفعل خاملة، لكن وحدة الـ qdisc التابعة لها لا تزال فارغة، لذا فإن شروط الدالة `update_vf()` تُفعّل حالة go_passive مرة أخرى:
if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1;
ثم يتم تخطي العقدة الورقية (leaf) بسبب فحص `cl_nactive == 0` داخل الحلقة، والذي لا يقوم بتصفير قيمة go_passive، مما يؤدي إلى انتشار القيمة القديمة لـ go_passive نحو الوالد وإنقاص قيمته في cl_nactive للمرة الثانية. يُجبر الوالد الذي ما زال لديه أبناء نشطون آخرون على الوصول إلى `cl_nactive == 0` وإزالته من شجرة vttree، رغم أن هؤلاء الإخوة لا يزالون متراكمين (backlogged). لن يتم إخلاؤهم مرة أخرى وتتوقف عملية الـ qdisc عن العمل (stalls).
تم إصلاح هذه المشكلة بتفعيل حالة go_passive فقط عندما تكون الفئة نشطة فعلياً، بحيث لا تؤدي الفئة التي أصبحت خاملة مسبقاً إلى تفعيل انتقال ثانٍ نحو الخمول. تستمر محاسبة البايتات (`cl->cl_total += len`) في التشغيل لكل سلف، لذا تظل البايتات المخلية تُحسب مرة واحدة بدقة.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.