In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
net\/mlx5e: Fix HV VHCA stats zero-sized buffer allocation<\/p>\n
mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(),
\nbefore mlx5e_open(). At that point priv->stats_nch is still zero,
\nbecause it is only ever incremented in mlx5e_channel_stats_alloc(),
\nwhich is reached only from mlx5e_open_channel().<\/p>\n
mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and
\nkvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16) rather
\nthan NULL. The “if (!buf)” guard does not catch this, and
\nmlx5e_hv_vhca_stats_create() completes “successfully” with
\npriv->stats_agent.buf set to ZERO_SIZE_PTR.<\/p>\n
Once channels are opened (priv->stats_nch > 0) and the hypervisor
\nenables stats reporting, mlx5e_hv_vhca_stats_work() recomputes
\nbuf_len using the new non-zero stats_nch and calls
\nmemset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at address 0x10.<\/p>\n
Allocate the buffer based on priv->max_nch, which is set in
\nmlx5e_priv_init() and is the upper bound on stats_nch:<\/p>\n
– Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that
\n returns sizeof(per_ring_stats) * max(max_nch, stats_nch), and
\n use it for the kvzalloc() in mlx5e_hv_vhca_stats_create().
\n – Keep mlx5e_hv_vhca_stats_buf_size() (which returns based on
\n stats_nch) for the worker’s active payload size, so the wire
\n format (block->rings = stats_nch) and the amount of data filled
\n by mlx5e_hv_vhca_fill_stats() are unchanged.<\/p>\n
The max(max_nch, stats_nch) guard handles the rare case where
\nmlx5e_attach_netdev() recomputes max_nch downward across a
\ndetach\/resume cycle while priv->stats_nch persists (mlx5e_detach_netdev
\ndoes not call mlx5e_priv_cleanup, so stats_nch is only reset when
\nthe netdev is destroyed). Without the guard, the worker could compute
\nbuf_len from stats_nch and overrun the smaller buffer allocated based
\non the reduced max_nch.<\/p>\n
Allocating a non-zero buffer also makes the kvzalloc() failure path in
\nmlx5e_hv_vhca_stats_create() reachable for the first time: it returns
\nearly without (re)creating the agent. Clear
\npriv->stats_agent.{agent,buf} in mlx5e_hv_vhca_stats_destroy() after
\nfreeing them, so that if a later create() bails out on this path, a
\nsubsequent teardown does not double-free the stale agent\/buffer left
\nfrom a previous enable\/disable cycle.<\/p>\n
This mirrors the existing mlx5e pattern of preallocating arrays of
\nsize max_nch (e.g. priv->channel_stats) and lazily populating
\nentries up to stats_nch on demand.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
net\/mlx5e: Fix HV VHCA stats zero-sized buffer allocation<\/p>\n
mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(),
\nbefore m<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-6971","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/6971","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6971"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6971"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6971"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}