{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  vsock: treat TCP_CLOSING as once-established  Handle the TCP_ESTABLISHED -\u003e TCP_CLOSING transition on OP_RST, which can race with the connect loop. Immediately break and return 0 on ESTABLISHED/CLOSING. The return value of connect() should reflect what happened up to the point the connection was established or failed. Events that occur afterwards must not affect it. E.g. even if OP_RW has already set sk_err, connect() should still return 0, not ENOBUFS because of it. Adapt the inaccurate comment above signal_pending().  Resetting a socket that is still present in connected_table can lead to memory corruption. The reporter noted lost transports for in-flight skbs, and I have reproduced crashes caused by re-insertion into connected_table.    list_add double add: new=, prev=, next=.   kernel BUG at lib/list_debug.c:35!   Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI   Workqueue: vsock-loopback vsock_loopback_work   RIP: 0010:__list_add_valid_or_report+0x11f/0x130   Call Trace:    vsock_insert_connected.cold+0xe/0x13    virtio_transport_recv_pkt+0x10e9/0x1460    vsock_loopback_work+0x305/0x480    process_one_work+0xe4c/0x1560    worker_thread+0x4f1/0xd60    kthread+0x36e/0x470    ret_from_fork+0x47b/0x6b0    ret_from_fork_asm+0x1a/0x30  This fix is supplementary to commit 002541ef650b (\"vsock: Ignore signal/timeout on connect() if already established\"). Details under Link.",
  "id": "DEBIAN-CVE-2026-99213",
  "modified": "2026-10-29T05:47:33.445205068Z",
  "published": "2026-10-28T11:17:42.770Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-99213"
    }
  ],
  "upstream": [
    "CVE-2026-99213"
  ]
}