{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.6-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  ovpn: fix peer refcount leak in TCP error paths  When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(\u0026peer-\u003etcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object.  The race window:    CPU0 (strparser/RX error):       CPU1 (tcp_tx_work/TX error):   ovpn_peer_hold()   \u003c- refcnt+1   ovpn_peer_hold()   \u003c- refcnt+2   schedule_work()    \u003c- queued      schedule_work()    \u003c- NO-OP                                     (work already pending)   ovpn_tcp_peer_del_work runs:     ovpn_peer_del()     ovpn_peer_put()  \u003c- refcnt+1                                    \u003c- peer never freed  Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point.",
  "id": "DEBIAN-CVE-2026-68122",
  "modified": "2026-09-14T16:47:44.514288533Z",
  "published": "2026-08-10T13:19:57.317Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-68122"
    }
  ],
  "upstream": [
    "CVE-2026-68122"
  ]
}