CVE-2026-99045 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
ibmveth: h_free logical LAN on open-fail after register
ibmveth_open() registers the logical LAN, then allocates the RX buffer pools. A pool failure jumps to out_free_buffer_pools without h_free_logical_lan(), so PHYP still owns the buffer-list page when it is unmapped. request_irq() failure already issued the hypercall before taking the same label.
Move that h_free to the shared post-register unwind so both paths deregister before the buffer list is unmapped.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The ibmveth driver in the Linux kernel contains a resource management flaw within its initialization sequence, specifically during the opening of the logical LAN interface on PowerVM systems. This vulnerability arises from an incorrect ordering of operations and improper error handling paths that can lead to state desynchronization between the guest operating system and the hypervisor. The core issue is located in the ibmveth_open function, which is responsible for setting up the network device for transmission and reception. During this process, the driver first registers the logical LAN with the hardware abstraction layer and subsequently attempts to allocate receive buffer pools necessary for packet processing.
A critical defect exists in how resource cleanup is handled when these allocations fail or when interrupt registration fails. If the allocation of RX buffer pools fails after the logical LAN has been registered but before it is properly freed, the code jumps to a label intended for freeing buffers without invoking h_free_logical_lan. This hypercall is essential for notifying the Power Hypervisor that the guest no longer owns specific resources associated with the network interface. Consequently, when the driver proceeds to unmap the buffer list pages due to the error condition, it releases memory that PHYP still believes is owned by the virtual machine. Similarly, if request_irq fails after issuing certain hypercalls but before completing full initialization, a similar path may be taken where cleanup is incomplete relative to hypervisor expectations.
This state mismatch results in the hypervisor retaining ownership of buffer-list pages that have been unmapped and potentially reused or freed by the guest kernel. Such an inconsistency can lead to undefined behavior, including potential data corruption if those memory regions are accessed later under different contexts, or stability issues such as system hangs or crashes within the virtual machine environment. The vulnerability represents a classic case of improper resource cleanup during error handling paths, where partial initialization leads to orphaned resources from the perspective of the hypervisor management layer.
From a classification standpoint, this issue aligns with CWE-401, which describes missing release of memory after successful allocation, and more specifically relates to race conditions or state inconsistencies in multi-party resource ownership scenarios often seen in virtualization environments. In terms of attack surface analysis, while primarily an internal stability flaw rather than a direct exploitation vector for privilege escalation, it could potentially be leveraged in denial-of-service attacks if triggered repeatedly by local users with network interface control capabilities, causing instability to the guest or host environment depending on hypervisor implementation details.
To mitigate this vulnerability, the fix involves restructuring the error handling logic within ibmveth_open. The h_free_logical_lan hypercall must be moved to a shared post-register unwind path that is executed regardless of whether buffer pool allocation succeeds or fails. This ensures that before any memory associated with the buffer list is unmapped, the hypervisor is correctly notified that it should reclaim ownership of those resources. System administrators and kernel maintainers should ensure that systems running affected versions of the Linux kernel are updated to a patched version where this initialization sequence has been corrected. Regular auditing of driver error paths for proper resource deallocation order remains a best practice in maintaining system integrity, particularly in virtualized environments where guest-host state synchronization is critical for operational stability.