{
  "affected": [
    {
      "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"
            },
            {
              "fixed": "7.0.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net/handshake: hand off the pinned file reference to accept_doit  handshake_req_next() removes the request from the per-net pending list and drops hn_lock before handshake_nl_accept_doit() reads req-\u003ehr_sk-\u003esk_socket and dereferences sock-\u003efile (once in FD_PREPARE() and again in get_file()).  In that window a consumer running tls_handshake_cancel() followed by sockfd_put() (svc_sock_free) or __fput_sync() (xs_reset_transport) releases sock-\u003efile.  sock_release() then runs sock_orphan(), zeroing sk_socket, and frees the struct socket.  The accept-side code either reads NULL through sk_socket or chases freed memory.  The submit-side sock_hold() does not prevent this.  sk_refcnt protects struct sock, but struct socket and sock-\u003efile are independently refcounted via the file descriptor the consumer owns.  Pinning sk leaves sock and sock-\u003efile unprotected.  Retarget the accept-side dereferences at req-\u003ehr_file, which was pinned at submit time, instead of req-\u003ehr_sk-\u003esk_socket-\u003efile. Pinning on its own is not sufficient: a consumer that cancels between handshake_req_next() returning and accept_doit reaching FD_PREPARE() takes the !remove_pending() branch in handshake_req_cancel() and drops hr_file before the accept side takes its own reference.  Hand off an additional file reference inside handshake_req_next(), under hn_lock, so the accept side operates on a reference that no concurrent handshake_req_cancel() can revoke.  FD_PREPARE() consumes that handed-off reference, either by transferring it to the new fd in fd_publish() or by dropping it in the cleanup destructor on error; the explicit get_file() that previously balanced FD_PREPARE() is therefore redundant and goes away.  Update handshake_req_cancel_test2 and _test3 to simulate the FD_PREPARE() consumption with an fput() so the kunit file-count assertions stay balanced.",
  "id": "DEBIAN-CVE-2026-63979",
  "modified": "2026-09-14T16:47:31.276877291Z",
  "published": "2026-07-19T16:17:17.070Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-63979"
    }
  ],
  "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-63979"
  ]
}