{
  "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"
            },
            {
              "fixed": "6.12.94-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  bpf, skmsg: fix verdict sk_data_ready racing with ktls rx  sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock-\u003esaved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, \"bpf: Fix running sk_skb program types with ktls\").  sk_psock_verdict_data_ready() has no equivalent guard.  When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx-\u003esaved_data_ready.  On data arrival:    tls_data_ready -\u003e tls_strp_data_ready -\u003e tls_rx_msg_ready     -\u003e saved_data_ready() = sk_psock_verdict_data_ready()       -\u003e tcp_read_skb() drains sk_receive_queue via __skb_unlink()          without calling tcp_eat_skb(), so copied_seq is not advanced.  tls_strp_msg_load() then finds tcp_inq() \u003e= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx-\u003estrp.anchor.frag_list pointing at a psock-owned (potentially freed) skb.  tls_decrypt_sg() subsequently walks that frag_list: use-after-free.  Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock-\u003esaved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched.  TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().",
  "id": "DEBIAN-CVE-2026-64025",
  "modified": "2026-09-14T16:47:45.955364371Z",
  "published": "2026-07-19T16:17:42.527Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-64025"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-64025"
  ]
}