В ядре Linux устранена следующая уязвимость:
net/mlx5e: исправлено выделение буфера статистики HV VHCA с нулевым размером.
mlx5e_hv_vhca_stats_create() вызывается из mlx5e_nic_enable(),
перед mlx5e_open(). В этот момент priv->stats_nch все еще равен нулю,
потому что он увеличивается только в mlx5e_channel_stats_alloc(),
который достигается только из mlx5e_open_channel().
mlx5e_hv_vhca_stats_buf_size() поэтому возвращает 0, и
kvzalloc(0, GFP_KERNEL) возвращает ZERO_SIZE_PTR ((void *)16) скорее
чем НУЛЬ. Охранник «if (!buf)» этого не улавливает и
mlx5e_hv_vhca_stats_create() завершается «успешно» с
priv->stats_agent.buf имеет значение ZERO_SIZE_PTR.
Как только каналы открыты (priv->stats_nch > 0) и гипервизор
включает отчеты по статистике, mlx5e_hv_vhca_stats_work() пересчитывает
buf_len использует новый ненулевой stats_nch и вызывает
memset(buf, 0, buf_len) на ZERO_SIZE_PTR, ошибка по адресу 0x10. Выделите буфер на основе priv->max_nch, который установлен в
mlx5e_priv_init() и является верхней границей stats_nch:
- Добавьте отдельный помощник mlx5e_hv_vhca_stats_buf_max_size(), который
возвращает sizeof(per_ring_stats) * max(max_nch, stats_nch) и
используйте его для kvzalloc() в mlx5e_hv_vhca_stats_create().
- Оставьте mlx5e_hv_vhca_stats_buf_size() (который возвращает результат на основе
stats_nch) для размера активной полезной нагрузки работника, поэтому провод
формат (block->rings = stats_nch) и объем заполняемых данных
от mlx5e_hv_vhca_fill_stats() не изменились. Защита max(max_nch, stats_nch) обрабатывает редкий случай, когда
mlx5e_attach_netdev() пересчитывает max_nch вниз по
цикл отсоединения/возобновления, пока сохраняется priv->stats_nch (mlx5e_detach_netdev
не вызывает mlx5e_priv_cleanup, поэтому stats_nch сбрасывается только тогда, когда
netdev уничтожен).
Без охраны рабочий мог вычислить
buf_len из stats_nch и переполнить меньший буфер, выделенный на основе
на уменьшенном max_nch. Выделение ненулевого буфера также приводит к тому, что путь сбоя kvzalloc()
mlx5e_hv_vhca_stats_create() доступен впервые: он возвращает
раньше без (повторного) создания агента. Очистить
priv->stats_agent.{agent,buf} в mlx5e_hv_vhca_stats_destroy() после
освобождая их, так что, если более поздний метод create() выйдет из строя на этом пути,
последующее удаление не приводит к двойному освобождению устаревшего агента/буфера
из предыдущего цикла включения/выключения.
Это отражает существующий шаблон mlx5e предварительного выделения массивов
размер max_nch (например, priv->channel_stats) и ленивое заполнение
записи до stats_nch по требованию.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(), before mlx5e_open(). At that point priv->stats_nch is still zero, because it is only ever incremented in mlx5e_channel_stats_alloc(), which is reached only from mlx5e_open_channel(). mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and kvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16) rather than NULL. The "if (!buf)" guard does not catch this, and mlx5e_hv_vhca_stats_create() completes "successfully" with priv->stats_agent.buf set to ZERO_SIZE_PTR. Once channels are opened (priv->stats_nch > 0) and the hypervisor enables stats reporting, mlx5e_hv_vhca_stats_work() recomputes buf_len using the new non-zero stats_nch and calls memset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at address 0x10. Allocate the buffer based on priv->max_nch, which is set in mlx5e_priv_init() and is the upper bound on stats_nch: - Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that returns sizeof(per_ring_stats) * max(max_nch, stats_nch), and use it for the kvzalloc() in mlx5e_hv_vhca_stats_create(). - Keep mlx5e_hv_vhca_stats_buf_size() (which returns based on stats_nch) for the worker's active payload size, so the wire format (block->rings = stats_nch) and the amount of data filled by mlx5e_hv_vhca_fill_stats() are unchanged. The max(max_nch, stats_nch) guard handles the rare case where mlx5e_attach_netdev() recomputes max_nch downward across a detach/resume cycle while priv->stats_nch persists (mlx5e_detach_netdev does not call mlx5e_priv_cleanup, so stats_nch is only reset when the netdev is destroyed). Without the guard, the worker could compute buf_len from stats_nch and overrun the smaller buffer allocated based on the reduced max_nch. Allocating a non-zero buffer also makes the kvzalloc() failure path in mlx5e_hv_vhca_stats_create() reachable for the first time: it returns early without (re)creating the agent. Clear priv->stats_agent.{agent,buf} in mlx5e_hv_vhca_stats_destroy() after freeing them, so that if a later create() bails out on this path, a subsequent teardown does not double-free the stale agent/buffer left from a previous enable/disable cycle. This mirrors the existing mlx5e pattern of preallocating arrays of size max_nch (e.g. priv->channel_stats) and lazily populating entries up to stats_nch on demand.
Характеристики атаки
Последствия
Строка CVSS v3.1