В ядре Linux устранена следующая уязвимость:
gve: исправлено повреждение буфера заголовка с помощью header-split и HW-GRO. Путь данных DQO RX программирует дескриптор очереди для каждого буфера.
header_buf_addr во время публикации и снова считывает разделенный заголовок
время завершения. И сообщение, и чтение в настоящее время индексируют
буфер заголовка по положению в очереди, а не по идентификатору буфера:
- сообщение (gve_rx_post_buffers_dqo): header_buf_addr вычисляется из
bufq->хвост
- read (gve_rx_dqo): заголовок читается из desc_idx (завершение
индекс заголовка очереди)
Это зависит от индекса очереди буфера и индекса очереди завершения.
быть равным в начале каждого пакета, т. е. на устройстве, потребляющем
опубликованные буферы и возврат завершений в том же порядке.
Это предположение не выполняется, если HW-GRO включен с несколькими потоки: объединенные сегменты принимаются и завершаются в том порядке, который могут отличаться от выложенных буферов заказов, а сегменты из разные потоки могут чередоваться. Это приводит к двум проблемам: 1. Неправильный слот заголовка при чтении.
Поскольку смещение чтения получается из
индекс завершения (desc_idx), пока устройство записывало заголовок в
адрес, запрограммированный для буфера buf_id, драйвер может скопировать
заголовок, принадлежащий другому пакету. Это проявляется как
падение пропускной способности (падение около 30% и большое количество TCP
повторные передачи) с включенным разделением заголовков и HW-GRO, и многие
потоки.
2. Буфер заголовка используется повторно, пока он еще принадлежит устройству.
Водитель перемещает bufq->head на единицу за каждое завершение и повторно публикует буферы на основе на этом. Прибытие N завершений RX гарантирует только то, что по крайней мере N Дескрипторы буфера RX были прочитаны устройством. Это не гарантировать, что устройство отказалось от владения всеми буферы, соответствующие этим N дескрипторам.
С выходом из строя
завершения (например, завершение пакета, скопированного в буфер N
поступает до завершения пакета, скопированного в буфер N-1),
драйвер может повторно опубликовать и перезаписать буфер заголовка, который устройство
все еще собирается записать, повреждая заголовок пакета
завершение которых еще не обработано. Исправьте обе проблемы, проиндексировав буфер заголовка с помощью buf_id в обоих сообщениях.
и читать пути. Таким образом, чтение из слота buf_id всегда корректно.
независимо от порядка завершения (решает проблему 1).
Индексирование с помощью buf_id также связывает каждый слот заголовка со временем жизни его
буферное состояние. Состояние буфера возвращается только в списки свободного/перезагруженного состояния.
когда обрабатывается его собственное завершение (buf_id), поэтому его слот заголовка может
публиковать повторно только после того, как с устройством будет покончено. Это делает заголовок
безопасное повторное использование слотов при внеочередных завершениях (решает проблему 2).
Выделите (gve_rx_alloc_hdr_bufs) и освободите (gve_rx_free_hdr_bufs)
буферы заголовков на основе num_buf_states для соответствия индексации buf_id.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: gve: fix header buffer corruption with header-split and HW-GRO The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing.
Характеристики атаки
Последствия
Строка CVSS v3.1