CVE-2025-39985

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: can: mcba_usb: bufer daşmasının qarşısını almaq üçün ndo_change_mtu() doldurulsun PF_PACKET göndərmək CAN freymvork məntiqini yan keçməyə və birbaşa CAN drayverinin xmit() funksiyasına çatmağa imkan verir. PF_PACKET freymvorku tərəfindən yerinə yetirilən yeganə yoxlama skb->len dəyərinin interfeysin MTU-suna uyğun olduğundan əmin olmaqdır. Təəssüf ki, mcba_usb drayveri öz net_device_ops->ndo_change_mtu() funksiyasını doldurmadığı üçün hücum edən şəxs, məsələn, aşağıdakıları edərək etibarsız MTU konfiqurasiya edə bilər: $ ip link set can0 mtu 9999 Bundan sonra hücum edən şəxs ETH_P_CANXL protokolu vasitəsilə PF_PACKET soketi aça bilər: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) bu, zərərli CAN XL freymlərini inyeksiya etmək üçündür. Məsələn: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN drayverlərinin xmit() funksiyaları skb-nin etibarlılığını yoxlamaq üçün can_dev_dropped_skb() funksiyasını çağırır, lakin yuxarıdakı şərtlər altında zərərli paket can_dev_dropped_skb() yoxlamalarından keçə bilir: 1. skb->protocol ETH_P_CANXL olaraq təyin edilmişdir və bu etibarlıdır (funksiya cihazın faktiki imkanlarını yoxlamır). 2. uzunluq etibarlı CAN XL uzunluğudur. Beləliklə, mcba_usb_start_xmit() düzgün idarə edə bilmədiyi bir CAN XL freymi qəbul edir və onu səhvən CAN freymi kimi şərh edir. Bu, bufer daşmasına səbəb ola bilər. Drayver aşağıdakı sətirlərdə heç bir əlavə yoxlama aparmadan cf->len dəyərini olduğu kimi istifadə edəcək: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc); Burada cf->len CAN XL freyminin flags sahəsinə uyğun gəlir. Əvvəlki nümunəmizdə canxl_frame->flags dəyərini 0xff olaraq təyin etmişdik. Gözlənilən maksimum uzunluq 8 olduğu üçün 247 baytlıq bufer daşması baş verir! İnterfeysin MTU-sunun CAN_MTU-dan böyük təyin edilməməsini təmin etmək üçün net_device_ops->ndo_change_mtu() doldurulub. Kök səbəbin aradan qaldırılması ilə bufer daşmasının qarşısı alınmış olur.