CVE-2026-80753: ovpn: run deferred work on a module-owned workqueue
In the Linux kernel, the following vulnerability has been resolved:
ovpn: run deferred work on a module-owned workqueue
ovpn queues several work items whose callbacks execute module text. These works currently run on the global system workqueues, so module exit has no driver-owned drain point that guarantees the callbacks have fully returned before the module text can be freed.
Object references protect the objects used by the callbacks, but they do not prove that a workqueue function has returned. In particular, a worker can drop the final reference that unblocks device teardown while it is still executing ovpn code.
Add a module-owned workqueue and queue all ovpn work items on it. During module exit, unregister rtnl and netlink first, flush the workqueue so ordinary ovpn workers finish, run the final RCU barrier, and destroy the workqueue last. This keeps the workqueue available for cleanup work queued from RCU callbacks, while ensuring no ovpn work item can outlive the module text.
The per-device delayed keepalive work remains explicitly disabled during netdev teardown (disabledelayedworksync in ndouninit), since flushworkqueue does not flush delayed work that is still only pending on its timer.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the ovpn code to create a module-owned workqueue and queue all ovpn work items onto that workqueue, instead of using the global system workqueues, so module cleanup can safely flush and drain module-owned work.
openvpn (ovpn) Linux kernel module workqueue ownership = module-owned workqueue; queue all ovpn work items on it - Configuration
During ovpn module exit: unregister rtnl and netlink first, then flush the module-owned workqueue so delayed/pending ovpn work is handled before the module text can be freed; ensure teardown drains work before returning from module exit to avoid callbacks still executing ovpn code.
ovpn Linux kernel module module exit teardown order = unregister rtnl/netlink first; flush/destroy ovpn module workqueue before freeing module text - Configuration
During netdev teardown (ndo_uninit), call disable_delayed_work_sync to disable the per-device delayed keepalive work, since flush_workqueue does not flush delayed work that is still only pending.
ovpn Linux kernel module delayed keepalive work during teardown = disable delayed keepalive work (disable_delayed_work_sync in ndo_uninit) - Compensating control
Ensure the module-owned workqueue remains available for cleanup work and that no ovpn work item can outlive the module text by coordinating device teardown and module exit with workqueue flushing and final RCU barrier/destroy steps as described (RCU deferred work queued from RCU callbacks, then final RCU barrier, then destroy the ovpn workqueues).
Event History
Frequently Asked Questions
When does the unsafe lifetime condition arise?
It arises during ovpn module exit, when work items executing ovpn module code are still running on global system workqueues as the module text may be freed. Object references can protect callback objects but do not guarantee that the workqueue callback itself has returned.
What ordering is required during module shutdown to prevent callbacks from outliving the module?
The resolved shutdown sequence unregisters rtnl and netlink first, flushes the module-owned workqueue, performs the final RCU barrier, and destroys the workqueue last. Keeping the workqueue until after the RCU barrier permits cleanup work queued by RCU callbacks to run safely.
Are delayed keepalive jobs covered by the workqueue flush?
No. Per-device delayed keepalive work must be explicitly disabled with disable_delayed_work_sync during netdev teardown, because flush_workqueue does not flush delayed work that has not yet become runnable.