В ядре Linux устранена следующая уязвимость:
может: bcm: отслеживать один исходный интерфейс для операций тайм-аута/регулирования ANYDEV
Операция приема ANYDEV (ifindex == 0) с активным тайм-аутом приема и/или
таймер дроссельной заслонки не имеет определенной семантики при поступлении соответствующих кадров
из нескольких интерфейсов: bcm_rx_handler() может выполняться одновременно для
одна и та же операция на разных процессорах, гонка hrtimer_cancel()/
bcm_rx_starttimer() против bcm_rx_timeout_handler() и вызывая
ложные уведомления RX_TIMEOUT и повреждение Last_frames.
тот же параллелизм позволяет регулировать мультиплексирование кадров из разных
интерфейсы затирают отдельные поля rx_ifindex/rx_stamp, общие для
оп. Добавьте op->if_detected для отслеживания первого интерфейса, который доставляет
соответствующий кадр, пока настроен таймер таймаута/дросселя, и
отклонять кадры из любого другого интерфейса для этой операции. Претензия
решено в bcm_rx_handler() до того, как коснется hrtimer_cancel()
op->timer, поэтому отклоненный кадр никогда не сможет нарушить заявленный
сторожевой таймер интерфейса.
Операции в режиме RTR исключаются через RX_RTR_FRAME,
независимо от kt_ival1/kt_ival2, поскольку они могут кратковременно удерживать
устаревшее значение из более ранней конфигурации, не поддерживающей RTR. Утверждение выдается в bcm_notify() на NETDEV_UNREGISTER и в
bcm_rx_setup(), когда SETTIMER перенастраивает значения таймера.
(Повторная) заявка возможна только на устройствах CAN в NETREG_REGISTERED.
dev->reg_state для освещения выпуска в bcm_notify(), где reg_state
становится NETREG_UNREGISTERING до синхронизации_net().
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().
Характеристики атаки
Последствия
Строка CVSS v3.1