CVE-2026-72343 is a temporal coupling defect in the mlx5e driver where buffer allocation occurs before the parameter governing its size is initialized. The call to kvzalloc() during enable uses stats_nch, but this value isn't populated until channels open later — creating a window where zero-size allocation succeeds via ZERO_SIZE_PTR, a degenerate handle that passes NULL checks while pointing to an invalid address. The fault surfaces later in mlx5e_hv_vhca_stats_work() when memset operates on this poisoned handle.
This pattern is the kernel's recurring vulnerability class: the allocator returns ZERO_SIZE_PTR for zero-size requests rather than NULL, and every developer must remember to guard against this case everywhere. The kernel won't change this — the behavior is ABI-locked by out-of-tree allocator implementations.
The fix anchors allocation to max_nch, a stable upper bound set during priv_init() before enable(). This mirrors how priv->channel_stats already works in the same driver: preallocate to max, lazily fill to active. The patch adds max(max_nch, stats_nch) to handle attach/detach cycles where max_nch can shrink while stats_nch persists — the fix papers over a state machine collision rather than eliminating the temporal coupling entirely.
For defenders: audit any kvzalloc/kzalloc call where the size argument depends on a parameter initialized later in the driver lifecycle. Look for the pattern of allocating before subsystem enable. Check whether your size parameter is stable at allocation time or only populated after a later callback. The mlx5e fix documents the collision surface — treat this CVE as a fingerprint for finding similar latent ordering bugs in adjacent driver code.