CVE-2026-72115 in Linux
Сводка
по VulDB • 16.08.2026
В ядре Linux устранена следующая уязвимость:
can: bcm: отслеживание одного исходного интерфейса для операций ANYDEV с таймаутом/ограничением пропускной способности (throttle)
Операция приема данных по протоколу CAN BCM (ANYDEV rx op, если ifindex == 0), имеющая активный таймер ожидания ответа (RX timeout) и/или таймер ограничения пропускной способности (throttle timer), не имеет четко определенных семантик в случае поступления кадров с нескольких интерфейсов: функция bcm_rx_handler() может выполняться параллельно для одной и той же операции на разных процессорах, создавая гонку между вызовами hrtimer_cancel()/bcm_rx_starttimer() и bcm_rx_timeout_handler(), что приводит к ложным уведомлениям RX_TIMEOUT и повреждению поля last_frames. Та же самая ситуация конкурентного доступа позволяет кадрам мультиплексирования с ограничением пропускной способности от разных интерфейсов перезаписывать общие для данной операции поля rx_ifindex/rx_stamp.
Добавлено поле op->if_detected для отслеживания первого интерфейса, доставившего совпадающий кадр в момент настройки таймера ожидания/ограничения, и блокировки кадров с любых других интерфейсов для этой операции. Право на использование (claim) определяется в bcm_rx_handler() до того момента, как hrtimer_cancel() изменит op->timer, поэтому отклоненный кадр никогда не сможет повлиять на watchdog заявленного интерфейса. Операции в режиме RTR исключаются через флаг RX_RTR_FRAME независимо от значений kt_ival1/kt_ival2, поскольку эти значения могут временно содержать устаревшие данные из предыдущей конфигурации без режима RTR.
Право использования (claim) освобождается в bcm_notify() при событии NETDEV_UNREGISTER и в bcm_rx_setup(), когда SETTIMER перенастраивает значения таймеров.
(Пере-)заявление права на использование возможно только для устройств CAN с состоянием dev->reg_state равным NETREG_REGISTERED, чтобы обеспечить корректное освобождение в bcm_notify(), где reg_state становится NETREG_UNREGISTERING до завершения synchronize_net().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.