В ядре Linux устранена следующая уязвимость:
vsock/virtio: сброс работает в порядке зависимости
virtio_vsock_remove() останавливает очереди virtio, а затем сбрасывает каждую работу.
элемент перед освобождением включающего его virtio_vsock. Текущий порядок делает
не учитывать зависимости между этими элементами: tx_work может стоять в очереди
send_pkt_work и send_pkt_work могут поставить в очередь rx_work. В частности, send_pkt_work может установить restart_rx и снять tx_lock.
Путь удаления может затем остановить очереди и очистить rx_work перед
send_pkt_work ставит его в очередь. Хотя более поздний сброс send_pkt_work ждет
чтобы этот производитель завершил работу, ничто не ждет только что поставленного в очередь rx_work,
так что kfree(vsock) может с ним соревноваться. КАСАН сообщил:
ОШИБКА: KASAN: использование плиты после освобождения
virtio_transport_rx_work+0x487/0x4b0
Чтение размера 8 по адресу ffff888114c2b008 с помощью задачи kworker/1:1/47.
Рабочая очередь: virtio_vsock virtio_transport_rx_work
Отслеживание вызова:
virtio_transport_rx_work+0x487/0x4b0
процесс_one_work+0x688/0x1120
рабочий_поток+0x45b/0xd10
Выделено по задаче 1:
virtio_vsock_probe+0xef/0x6b0
Освобожден заданием 84:
kfree+0x131/0x3c0
virtio_vsock_remove+0xd1/0x100
Промойте работы в порядке «производитель-потребитель». virtio_vsock_vqs_del()
уже отключил обратные вызовы очереди и очистил флаги запуска, поэтому
после того, как tx_work и send_pkt_work исчерпаны, не остается источника, который мог бы
очередь rx_work после ее сброса.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: flush works in dependency order virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work. In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it. KASAN reported: BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100 Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.