Description

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 (disable_delayed_work_sync in ndo_uninit), since flush_workqueue does not flush delayed work that is still only pending on its timer.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-09-03T13:06:15.010Z",
  "pubdate": "2026-09-03T13:06:15.010Z",
  "executiveSummary": "The ovpn (OpenVPN data plane) module in the Linux kernel exhibits a concurrency vulnerability involving improper lifecycle management of work items. By relying on global system workqueues, the module fails to ensure that all scheduled work completes before the module is unloaded.\nThis creates a Use-After-Free (UAF) condition where the kernel may attempt to execute module code that has already been deallocated from memory. The vulnerability allows for potential arbitrary code execution or system instability if an attacker can trigger module unloading while asynchronous ovpn tasks are still in flight.\nThe risk is primarily tied to local privilege escalation or kernel panic scenarios. Exploitation requires the attacker to influence device teardown sequences or module removal while concurrent work items remain active in the system workqueue. The issue stems from the lack of a driver-owned synchronization barrier during the module exit sequence.",
  "technicalDetails": "The vulnerability originates from the asynchronous execution model of the ovpn driver, which queues work items to the global system workqueue. In the original implementation, the ovpn module lacked a dedicated workqueue mechanism to manage the lifecycle of its asynchronous tasks. When the ovpn module is removed via rmmod or during kernel teardown, the kernel executes the module exit path without guaranteeing that all pending work items have completed execution.\nThe root cause is a race condition between the module exit routine and the kernel's workqueue workers. While object references were utilized to protect the integrity of the data structures being accessed, these references do not serve as a synchronization primitive for the execution of the callback functions themselves. A worker thread can hold a valid reference to an ovpn-managed object while the underlying module text is unmapped from kernel memory. If the worker thread continues execution after the memory region containing the callback code is freed, the kernel will trigger a page fault or attempt to execute stale instructions, resulting in a Use-After-Free or Kernel Oops.\nThe exploitation flow involves an attacker triggering the creation of ovpn netdevices and subsequently inducing a condition that leads to module unloading or interface teardown. If the attacker can force the scheduler to delay the execution of a queued work item until after the module exit function has begun finalizing, the worker thread will reference memory that has been reclaimed by the kernel. Because the global workqueue is shared and managed by the kernel core, the ovpn module has no mechanism to force a 'drain' of its specific work items.\nThe resolution involves migrating all ovpn-related work items to a dedicated, module-owned workqueue. By establishing a driver-owned workqueue, the module can explicitly call flush_workqueue() during the exit sequence. This action acts as a synchronization barrier, forcing all currently pending and running work items to reach a completion state before the module unloads. By unregistering the netlink and rtnl interfaces prior to flushing the workqueue, and subsequently invoking an RCU barrier, the kernel ensures that no ovpn code or callback will execute once the module is removed. The use of disable_delayed_work_sync() for keepalive tasks remains necessary because standard workqueue flushing does not account for tasks pending in high-resolution timers, ensuring full coverage against residual async execution."
}