CVE-2026-72343

WysokieCVSS 8.4

Opublikowano: 15/08/2026(UTC)Zaktualizowano: 16/10/2026(UTC)Przetłumaczono: 15/08/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.20%

Percentyl 9 - wyżej niż 9% wszystkich znanych CVE

Streszczenie

W sterowniku mlx5e dla kart sieciowych Mellanox wykryto podatność polegającą na alokacji bufora o zerowym rozmiarze dla statystyk HV VHCA. Bufor jest alokowany przed inicjalizacją kanałów, gdy liczba kanałów wynosi zero, co prowadzi do uzyskania wskaźnika ZERO_SIZE_PTR zamiast NULL. Po otwarciu kanałów i włączeniu raportowania przez hiperwizor, operacja memset na tym wskaźniku powoduje błąd strony (fault) pod adresem 0x10.

Ocena ryzyka

Podatność może prowadzić do awarii systemu (kernel panic) w środowiskach wirtualizowanych z kartami Mellanox, co skutkuje przerwą w działaniu usług. Atakujący z uprawnieniami hiperwizora może celowo wywołać tę sytuację, powodując denial of service.

Rekomendacja

Zaleca się natychmiastowe zastosowanie poprawki dostarczonej przez producenta jądra Linux. Należy zaktualizować system do wersji jądra zawierającej fix dla CVE-2026-72343 oraz monitorować komunikaty o nowych wersjach.

Inne podatności w Linux kernel

Zobacz wszystkie

Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS