Dear Maintainer,

The ovpn_dco_v2 module built from the snapshot in trixie/stable
(0.0+git20241121-1) contains a use-after-free in the peer-deletion path
that causes a kernel NULL-pointer dereference under high client
connect/disconnect concurrency. It is fixed upstream (commit f74c59a7,
2026-05-14) but the fix is not present in any released Debian version.

== The defect ==

In drivers/net/ovpn-dco/peer.c, ovpn_peer_delete_work() releases the peer
*before* using it:

     static void ovpn_peer_delete_work(struct work_struct *work)
     {
             struct ovpn_peer *peer = container_of(work, struct ovpn_peer,
                                                   delete_work);
             ovpn_peer_release(peer);              /* arms call_rcu() ->
frees peer */
             ovpn_netlink_notify_del_peer(peer);   /* then derefs
peer->ovpn->dev */
     }

ovpn_peer_release() ends in call_rcu(&peer->rcu, ovpn_peer_release_rcu),
whose callback (ovpn_peer_release_rcu -> ovpn_peer_free) does
dev_put(peer->ovpn->dev) and kfree(peer). Because ovpn_peer_delete_work()
is not in an RCU read-side critical section, that callback can run (on any
CPU) before ovpn_netlink_notify_del_peer() executes. That function then
dereferences peer->ovpn->dev (netdev_info(), nla_put_u32(... ifindex ...),
genlmsg_multicast_netns(dev_net(...))) through freed memory.

In steady state the RCU grace period is long relative to the function, so
the free happens later and nothing is observed. Under a mass simultaneous
reconnect (hundreds of peers deleted/recreated at once on a multi-core
host), grace periods complete in milliseconds and the free races ahead of
the notification -> NULL-pointer dereference.

== Observed crash ==

   BUG: kernel NULL pointer dereference, address: 0000000000000000
   RIP: ovpn_netlink_notify_del_peer+0xa8 [ovpn_dco_v2]
   Workqueue: ovpn-event-wq-<dev> ovpn_peer_delete_work [ovpn_dco_v2]
   CR2: 0000000000000000   RAX: 0000000000000000

After the first oops the module's peer table is corrupted: subsequent peer
deletions oops repeatedly, the tun interface loses its address, and the
module reaches a state where rmmod -f fails ("Device or resource busy",
refcount underflow). A full reboot does not help if clients immediately
reconnect (the oops loop resumes within minutes); the only recovery is to
disable DCO (disable-dco in the OpenVPN server config) so peer operations
go through userspace instead of the kernel module.

== Environment ==

   Debian 13 (trixie), kernel 6.12.x-cloud-amd64
   openvpn 2.6.14-1+deb13u2
   openvpn-dco-dkms 0.0+git20241121-1
   Multi-vCPU host, OpenVPN UDP server with several hundred clients;
   triggered by a mass simultaneous client reconnect.

== Fix ==

Fixed upstream in OpenVPN/ovpn-dco by commit f74c59a7
("ovpn-dco: avoid UAF when releasing peer", 2026-05-14):


https://github.com/OpenVPN/ovpn-dco/commit/f74c59a7e2c8b63958f556df74a585d54e2ac660

which simply reorders the two calls so the notification runs while the peer
is still valid:

     ovpn_netlink_notify_del_peer(peer);   /* notify first */
     ovpn_peer_release(peer);              /* then schedule the free */

A companion commit addresses a related NAPI add/delete race
("ovpn-dco: serialize peer NAPI add/delete", 2026-05-14):


https://github.com/OpenVPN/ovpn-dco/commit/ef379eae8534a7bc4847d8545573b00c5f4887ae

Neither is in any released Debian version: trixie/stable ships
0.0+git20241121-1 and testing/unstable ship 0.0+git20251017-1, both of
which predate the May-2026 fix.

== Request ==

Please update openvpn-dco-dkms to an upstream snapshot that includes
f74c59a7 (and ideally ef379eae). The primary fix is a two-line reorder and
is trivially cherry-pickable as a patch if a full snapshot bump is not
desired for stable.

Note: OpenVPN/ovpn-dco is upstream in bugfix-only/maintenance mode (it
supports OpenVPN 2.6.x). For OpenVPN 2.7+ the replacement is the in-tree
"ovpn" module (Linux 6.16+) / the OpenVPN/ovpn-backports project; this
report concerns the 2.6.x ovpn-dco module shipped in trixie.

Thank you.
Thomas

Just FYI, I have a similar setup, I am using Debian 13 + openvpn 2.7 and
linux 7.0 from Debian backports.
openvpn 2.7 doesn't need openvpn-dco-dkms, the ovpn kernel module is in
linux since 6.16 and gets the fixes/improvemets from there.
Regards.

We believe that the bug you reported is fixed in the latest version of
openvpn-dco-dkms, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1140548@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bernhard Schmidt <berni@debian.org> (supplier of updated openvpn-dco-dkms package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 23 Jun 2026 23:06:30 +0200
Source: openvpn-dco-dkms
Architecture: source
Version: 0.0+git20260519-1
Distribution: unstable
Urgency: medium
Maintainer: Bernhard Schmidt <berni@debian.org>
Changed-By: Bernhard Schmidt <berni@debian.org>
Closes: 1140548
Changes:
 openvpn-dco-dkms (0.0+git20260519-1) unstable; urgency=medium
 .
   * New upstream version 0.0+git20260519
     - fixes ovpn_dco_v2 use-after-free (NULL deref in
       ovpn_netlink_notify_del_peer) crashes under peer-deletion storm
       (Closes: #1140548)
Checksums-Sha1:
 f092e07a163f270dc7cb87ffd054d551a387077e 2053 openvpn-dco-dkms_0.0+git20260519-1.dsc
 92943cdca3a3067e5e56ea1d4770fc982a0b00af 71794 openvpn-dco-dkms_0.0+git20260519.orig.tar.gz
 27886a6f01c7634cdd8bac2b4383a2bdf9515668 3712 openvpn-dco-dkms_0.0+git20260519-1.debian.tar.xz
 f60a32f5cd41d057dc612ba83b22c6e8146a8ecd 5833 openvpn-dco-dkms_0.0+git20260519-1_amd64.buildinfo
Checksums-Sha256:
 248d6551ccb8dc0607e59f835f2f191bd439544423b0695e8675015cf1fc6498 2053 openvpn-dco-dkms_0.0+git20260519-1.dsc
 0d23487c8b469d65d0133f013a3a52ae78d259f627e1efbc941987d1b9501a48 71794 openvpn-dco-dkms_0.0+git20260519.orig.tar.gz
 382c2917649c8d069a2aa37e8e7cfbcd74c6b5211de994ea2f1efddb9bc104fd 3712 openvpn-dco-dkms_0.0+git20260519-1.debian.tar.xz
 9b84616f9105fa70752ff95cb9255aa432ff964461b0525a7474bfd4058bbbb9 5833 openvpn-dco-dkms_0.0+git20260519-1_amd64.buildinfo
Files:
 3dfc631dad6908ef4cf4e78520582fe5 2053 net optional openvpn-dco-dkms_0.0+git20260519-1.dsc
 f1de81f9e8ee1c5950bafd35c23c86a1 71794 net optional openvpn-dco-dkms_0.0+git20260519.orig.tar.gz
 d88da5691ae136355d3f070b1dccddd6 3712 net optional openvpn-dco-dkms_0.0+git20260519-1.debian.tar.xz
 651d6f7e10388407448ae594bc0c4008 5833 net optional openvpn-dco-dkms_0.0+git20260519-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCgAvFiEE1uAexRal3873GVbTd1B55bhQvJMFAmo69nkRHGJlcm5pQGRl
Ymlhbi5vcmcACgkQd1B55bhQvJPcuA//ae9CKuwZOEIWkIoMHS9vpGi8/kmtUpJb
F1de1og36gerGVY4C4JgrGIA7bM1hR6Fr3HFaxqa9s4oqctzNsFMLo80RMJ/WeJJ
oOjFKOFok2xOictZlJ6j/C28qQH8izyh+hAGwTe7siQGYvZ69kVv/EXKFCEJ6gCE
ivJzimYX7ixMazsQ3iLGb/JG8HSJ+RWcGdLDy7g3K6YyfcRTCNlnICu3buRt0FED
omk7AvRNEZVgvOdYbD/vUyVxnavNKrc9pRjxgAHkL9Zkjk96rpYbr6Dihv/9UlEZ
+rm/gGH77U8N9kQmSwnf5Taj0FFjUKwwvkz1/7TJdrAW2XAe9bO9+5Hc/qyFrvX0
G7OAWu/c6Xf8AeJYvBg7Y0jhiX+L1J0KpJEd96QGYSchInDR6hx7tDsCUSwUGetV
R5qlSAM48sxN9ncMRHhkNq2M77vTEkT1hgWifq81gD+xIQGJ6asRmogwtZIfB1Ly
bicrIjpl9Dk+De+TZcJ9BOU5+MtdU/BO98O4Nh8MCMteuas8XkpSpkHsRw23SGXv
ijxYkw9I3fremd7xGPPY16bTQDwwdXmKUiuDQVhZp80N5kXLvEcuUbhtAu1A7NpL
EAU9CFGVZL0Qk7bdFYFMi8IJETWQZ6S+x1qDhGmW/3bWoZA5hqardptljs1j8ie8
kYDMRBc+bNc=
=zYnd
-----END PGP SIGNATURE-----

Dear Thomas,

 > The ovpn_dco_v2 module built from the snapshot in trixie/stable

Thanks for reporting this.

While I agree with Fabio's statement that bpo kernel+openvpn is a viable
alternative and possibly more battle-tested than ovpn-dco-v2 already,
this is still a bug that should be fixed in stable.

I have uploaded the most recent upstream version to unstable and I have
prepared a version for trixie cherry-picking both commits you mention. A
test package is available at

https://people.debian.org/~berni/openvpn-dco-dkms/openvpn-dco-dkms_0.0+git20241121-1+deb13u1_all.deb

Could you please give this package a test-run?

Bernhard

Hi Bernhard,

Thanks for the quick turnaround on this. I've tested
0.0+git20241121-1+deb13u1 under the same load that originally triggered
the crash -- 1024 DCO clients, server under heavy CPU load (stress-ng),
repeated peer-deletion storms (blocking inbound packets so all peers
time out at once) -- and the kernel use-after-free is gone. I'm happy
with it and convinced you definitely should release it.

One heads-up that came out of the same load testing: there is a
separate, userspace-side bug in the openvpn package itself. With this
kernel module fixed the box no longer crashes, but under the same load
openvpn drops some of the kernel's DEL_PEER notifications and leaks
client instances, until it reaches --max-clients and starts refusing
new/reconnecting clients (recoverable only by restarting openvpn). It is
fixed upstream in 2.7 (commit 7791f535, openvpn issue #919) but not in 2.6.

I've filed that as a separate Debian bug against src:openvpn, with a
tested patch: #1140745 <https://bugs.debian.org/1140745>. I've also
raised it upstream on openvpn-devel:

https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/5afdb852-eabf-4829-b95f-6a322ed5d56a%40midjourney.com/#msg59351167

So this kernel-module fix is necessary but not sufficient for a DCO
server under load -- both fixes are needed. Flagging it here for
cross-reference, since the two came out of the same investigation.

Thanks again,
Thomas