В ядре Linux устранена следующая уязвимость:
можно: bcm: отложить освобождение rx_op в рабочую очередь, чтобы исправить тример UAF
Зафиксируйте f1b4e32aca08 («можно: bcm: использовать call_rcu() вместо дорогостоящего
синхронизация_rcu()") замененаsync_rcu() в bcm_delete_rx_op().
с call_rcu() и представил флаг RX_NO_AUTOTIMER. Однако эта проверка флага была опущена для thrtimer в пакете rx.
быстрый путь. Во время отключения операции BCM RX одновременное считывание RCU
(bcm_rx_handler) может участвовать в гонках и повторно активировать таймер через
bcm_rx_update_and_send() после запланированного вызова call_rcu().
Однажды
льготный период RCU истекает, bcm_op освобождается. Впоследствии
запуск тримера затем разыменовывает освобожденную операцию, вызывая UAF. Добавление проверок флагов в быстрый путь приема (bcm_rx_update_and_send) не
полностью закрывает гонку TOCTOU и вводит задержку для каждого кадра CAN.
И наоборот, вызов hrtimer_cancel() непосредственно внутри обратного вызова RCU.
(контекст softirq) является фатальным, поскольку hrtimer_cancel() может перейти в спящий режим, вызывая срабатывание
паника «планирования в то время как атомарная». Решите эту проблему, отложив отмену таймера и освобождение памяти до
выделенная несвязанная рабочая очередь (bcm_wq). Обратный вызов RCU теперь ставит в очередь
рабочий элемент в bcm_wq, который безопасно отменяет оба таймера и освобождает
память в контексте спящего процесса.
Выделенная рабочая очередь используется для
предотвращает общесистемное насыщение WQ и полностью очищается/уничтожается
при выгрузке модуля, чтобы избежать ошибок страницы rmmod. Поскольку отложенная работа теперь может пережить контекст вызова
неограниченное количество, также берите ссылку на op->sk при ее назначении
и отбросить его только после того, как отложенная работа отменит оба таймера, поэтому
сокет больше нельзя высвободить из-под все еще включенного таймера, чей
обратный вызов (bcm_send_to_user()) разыменовывает op->sk.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly synchronize_rcu()") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a "scheduling while atomic" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.
Характеристики атаки
Последствия
Строка CVSS v3.1