CVE-2025-39985

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: can: mcba_usb: arabellek taşmasını önlemek için ndo_change_mtu() dolduruldu Bir PF_PACKET göndermek, CAN çerçevesi mantığını atlamaya ve doğrudan bir CAN sürücüsünün xmit() işlevine ulaşmaya olanak tanır. PF_PACKET çerçevesi tarafından gerçekleştirilen tek kontrol, skb->len değerinin arayüzün MTU değerine sığdığından emin olmaktır. Ne yazık ki, mcba_usb sürücüsü net_device_ops->ndo_change_mtu() işlevini doldurmadığı için, bir saldırganın örneğin aşağıdakini yaparak geçersiz bir MTU yapılandırması mümkündür: $ ip link set can0 mtu 9999 Bunu yaptıktan sonra saldırgan, kötü niyetli CAN XL çerçeveleri enjekte etmek için ETH_P_CANXL protokolünü kullanarak bir PF_PACKET soketi açabilir: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) Örneğin: struct canxl_frame frame = { .flags = 0xff, .len = 2048, }; CAN sürücülerinin xmit() işlevi, skb'nin geçerli olduğunu kontrol etmek için can_dev_dropped_skb() işlevini çağırır; ne yazık ki yukarıdaki koşullar altında kötü niyetli paket can_dev_dropped_skb() kontrollerinden geçebilir: 1. skb->protocol, geçerli olan ETH_P_CANXL olarak ayarlanmıştır (işlev, aygıtın gerçek yeteneklerini kontrol etmez). 2. uzunluk, geçerli bir CAN XL uzunluğudur. Böylece mcba_usb_start_xmit(), doğru şekilde işleyemediği bir CAN XL çerçevesi alır ve bu nedenle onu bir CAN çerçevesi olarak yanlış yorumlar. Bu, arabellek taşmasına neden olabilir. Sürücü, aşağıdaki satırlarda cf->len değerini başka bir kontrol yapmadan olduğu gibi kullanacaktır: usb_msg.dlc = cf->len; memcpy(usb_msg.data, cf->data, usb_msg.dlc); Burada cf->len, CAN XL çerçevesinin flags alanına karşılık gelir. Önceki örneğimizde canxl_frame->flags değerini 0xff olarak ayarladık. Beklenen maksimum uzunluk 8 olduğundan, 247 baytlık bir arabellek taşması meydana gelir! Arayüzün MTU değerinin CAN_MTU değerinden daha büyük bir değere ayarlanamamasını sağlamak için net_device_ops->ndo_change_mtu() doldurulmuştur. Kök neden düzeltilerek arabellek taşması önlenir.