CVE-2026-64043: ovpn: fix race between deleting interface and adding new peer
In the Linux kernel, the following vulnerability has been resolved:
ovpn: fix race between deleting interface and adding new peer
While deleting an existing ovpn interface, there is a very narrow window where adding a new peer via netlink may cause the netdevice to hang and prevent its unregistration.
It may happen during ovpndellink(), when all existing peers are freed and the device is queued for deregistration, but a CMDPEERNEW message comes in adding a new peer that takes again a reference to the netdev.
At this point there is no way to release the device because we are under the assumption that all peers were already released.
Fix the race condition by releasing all peers in ndouninit(), when the netdevice has already been removed from the netdev list.
Also ovpnpeeradd() has now an extra check that forces the function to bail out if the device regstate is not REGISTERED. This way any incoming CMDPEERNEW racing with the interface deletion routine will simply stop before adding the peer.
Note that the above check happens while holding the netdevlock to prevent racing netdev state changes.
ovpndellink() is now empty and can be removed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Fix the OpenVPN netdevice deletion race by releasing all peers in ndo_uninit(), and make ovpn_peer_add() bail out while holding netdev_lock when the device reg_state is not REGISTERED, preventing CMD_PEER_NEW from adding a peer during interface deletion.
Event History
Frequently Asked Questions
Who can trigger this issue?
An attacker needs local access and low-privileged permissions to send a CMD_PEER_NEW netlink request while an existing ovpn interface is being deleted. Exploitation depends on winning a very narrow race window.
What is the practical impact if the race succeeds?
A new peer can retain a reference to the netdevice after deletion has begun, causing the device to hang and preventing its unregistration. The reported impact is availability only; no confidentiality or integrity impact is specified.
Are systems affected during normal ovpn operation?
The race requires concurrent interface deletion and peer creation. The described condition occurs specifically while an ovpn interface is being removed and a CMD_PEER_NEW message arrives before deregistration completes.
What does the fix change?
The fix releases peers during ndo_uninit(), after the netdevice has been removed from the netdevice list, and rejects peer additions unless the device registration state is REGISTERED. The registration-state check is performed while holding netdev_lock to avoid state-change races.