CVE-2025-39987 in Linux
الملخص
بحسب VulDB • 27/05/2026
في نواة لينكس، تم حل الثغرة التالية:
can: hi311x: تعبئة دالة ndo_change_mtu() لمنع تجاوز المخزن المؤقت (Buffer Overflow)
يتيح إرسال حزم PF_PACKET تجاوز منطق إطار عمل CAN والوصول مباشرة إلى دالة xmit() الخاصة بقائد CAN. الفحص الوحيد الذي يقوم به إطار عمل PF_PACKET هو التأكد من أن قيمة skb->len تتناسب مع MTU الخاص بالواجهة.
للأسف، وبسبب عدم قيام قائد sun4i_can بتعبئة net_device_ops->ndo_change_mtu()، يمكن لمهاجم تكوين قيمة MTU غير صالحة عن طريق تنفيذ الأمر التالي على سبيل المثال:
$ ip link set can0 mtu 9999
بعد ذلك، يمكن للمهاجم فتح مقبس PF_PACKET باستخدام بروتوكول ETH_P_CANXL:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
لحقن إطارات CAN XL خبيثة. على سبيل المثال:
struct canxl_frame frame = {
.flags = 0xff, .len = 2048, };
تقوم دوال xmit() الخاصة بقادة CAN باستدعاء can_dev_dropped_skb() للتحقق من صحة skb. وللأسف، في ظل الظروف المذكورة أعلاه، يمكن للحزمة الخبيثة تجاوز فحوصات can_dev_dropped_skb() للأسباب التالية:
1. يتم تعيين skb->protocol إلى ETH_P_CANXL وهي قيمة صالحة (لا تتحقق الدالة من قدرات الجهاز الفعلية).
2. تكون الطول قيمة صالحة لطول CAN XL.
وبالتالي، تستقبل الدالة hi3110_hard_start_xmit() إطار CAN XL غير القادر على معالجته بشكل صحيح، مما يؤدي إلى تفسيره بشكل خاطئ على أنه إطار CAN. سيقوم القائد باستهلاك frame->len كما هو دون إجراء فحوصات إضافية.
يمكن أن يؤدي ذلك إلى تجاوز مخزن مؤقت (Buffer Overflow) لاحقاً في الدالة hi3110_hw_tx() على السطر التالي:
memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);
هنا، يتوافق frame->len مع حقل flags الخاص بإطار CAN XL. في مثالنا السابق، قمنا بتعيين canxl_frame->flags إلى 0xff. وبما أن الحد الأقصى المتوقع للطول هو 8، يحدث تجاوز مخزن مؤقت (Buffer Overflow) بحجم 247 بايت!
يتم تعبئة net_device_ops->ndo_change_mtu() لضمان عدم إمكانية تعيين MTU الخاص بالواجهة إلى أي قيمة أكبر من CAN_MTU. ومن خلال إصلاح السبب الجذري، يتم منع تجاوز المخزن المؤقت (Buffer Overflow).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.