В ядре Linux устранена следующая уязвимость:
может: bcm: добавить блокировку при обновлении значений фильтра и таймера
KCSAN обнаружил одновременный доступ к значениям таймера, которые можно
перезаписывается в bcm_rx_setup() при обновлении содержимого таймера и фильтра
в то время как bcm_rx_handler(), bcm_rx_timeout_handler() или bcm_rx_thr_handler()
работать одновременно на входящем трафике CAN. Защитите таймер (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) и отфильтруйте
(nframes/flags/frames/last_frames) обновляется в bcm_rx_setup() новым
для каждой операции bcm_rx_update_lock, взятый с соответствующей областью в RX
обработчики. memcpy_from_msg() помещается во временный буфер перед
блокировка взята, так как она может спать и не должна работать под спин-блокировкой.
hrtimer_cancel() всегда вызывается без удержания bcm_rx_update_lock, поскольку
bcm_rx_timeout_handler()/bcm_rx_thr_handler() принимают ту же блокировку и
в противном случае запуск обратного вызова приведет к тупику в отношении отмены. Также закройте связанную гонку: bcm_rx_setup() очистил флаг RTR в
can_id сохраненного кадра ответа как отдельный незащищенный шаг после
содержимое фрейма уже установлено, поэтому одновременный вызов bcm_rx_handler()
может передать устаревший ответ с установленным CAN_RTR_FLAG.
Сложите это
вместо этого нормализацию в начальную подготовку кадра (на поэтапном этапе
буфер для обновлений, непосредственно на op->frames, предварительная регистрация новых
ops), поэтому установленный фрейм всегда атомарно самосогласован. Проверка RX_RTR_FRAME функции bcm_rx_handler() теперь требует защищенного блокировкой
снимок флагов op-> перед принятием решения о вызове bcm_can_tx(),
но не удерживает блокировку этого вызова. Также сделайте защищенный блокировкой снимок currframe в bcm_can_tx().
чтобы избежать частичной перезаписи при обновлении содержимого в bcm_tx_setup().
Наконец, проверьте, не сбросился ли TX_RESET_MULTI_IDX/SETTIMER.
op->currframe между двумя заблокированными разделами в bcm_can_tx(). Опустите вызов hrtimer_forward() с нулевым интервалом в bcm_rx_thr_handler().
kt_ival2 мог быть одновременно очищен функцией bcm_rx_setup() перед этим.
отменяет этот таймер, поэтому проверьте kt_ival2 внутри bcm_rx_update_lock.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.
Характеристики атаки
Последствия
Строка CVSS v3.1