GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

FKIE_CVE-2026-72139

Vulnerability from fkie_nvd - Published: 2026-08-15 06:21 - Updated: 2026-08-17 06:18
Severity
9.8 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: if (needs_md5) { tcp_ao_destroy_sock(sk, false); } else if (needs_ao) { tcp_clear_md5_list(sk); kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...)); } Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock destructor when the socket is already unhashed and unreachable; the extra grace period there is unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO key); however the symmetric race exists and a maintainer touching this code should not have to think about which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with tcp-diag]
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/33a1bee413628378fd036a4f2b17ba86b0bc560c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b74cd55038905d5e74c1de109ab78a30b2ea0e1f
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/da48b9bf1eb95a9cfd09d615ca58cfc2b03de369
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/ipv4/tcp_ipv4.c",
            "net/ipv4/tcp_output.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "33a1bee413628378fd036a4f2b17ba86b0bc560c",
              "status": "affected",
              "version": "51e547e8c89c661f6fbede4a28b1d33b13625683",
              "versionType": "git"
            },
            {
              "lessThan": "da48b9bf1eb95a9cfd09d615ca58cfc2b03de369",
              "status": "affected",
              "version": "51e547e8c89c661f6fbede4a28b1d33b13625683",
              "versionType": "git"
            },
            {
              "lessThan": "b74cd55038905d5e74c1de109ab78a30b2ea0e1f",
              "status": "affected",
              "version": "51e547e8c89c661f6fbede4a28b1d33b13625683",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/ipv4/tcp_ipv4.c",
            "net/ipv4/tcp_output.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.18"
            },
            {
              "lessThan": "6.18",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.40",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: defer md5sig_info kfree past RCU grace period in tcp_connect\n\nThe md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c)\nhas two symmetric branches:\n\n\tif (needs_md5) {\n\t\ttcp_ao_destroy_sock(sk, false);\n\t} else if (needs_ao) {\n\t\ttcp_clear_md5_list(sk);\n\t\tkfree(rcu_replace_pointer(tp-\u003emd5sig_info, NULL, ...));\n\t}\n\nBoth branches free a per-socket auth-info object while the socket is\nin TCP_SYN_SENT and is already on the inet ehash (inserted by\ninet_hash_connect() in tcp_v4_connect()). Both branches are reachable\nby softirq RX-path readers that load the corresponding info pointer\nvia implicit RCU before bh_lock_sock_nested() is taken.\n\nThe needs_md5 branch is fixed in the prior patch by re-introducing\nthe call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key\nloop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the\ntime it frees each tcp_ao_key all softirq readers that captured the\ncontainer have already completed rcu_read_unlock().\n\nThe needs_ao branch is not symmetric in the same way. The container\nfree can be deferred via kfree_rcu(md5sig, rcu) -- struct\ntcp_md5sig_info already has the required rcu member\n(include/net/tcp.h:1999-2002), and the rest of the tree already does\nthis in the tcp_md5sig_info_add() rollback paths\n(net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done\nby tcp_clear_md5_list() in process context BEFORE the container\u0027s\nRCU grace period: it walks \u0026md5sig-\u003ehead and frees each\ntcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq\nreader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact()\n(tcp_ipv4.c:1253, 1298) walks the same list via\nhlist_for_each_entry_rcu() and races with that bare kfree on the\nkeys themselves -- a per-key slab use-after-free of the same class\nas the TCP-AO bug, on the same race window.\n\nFix this in two halves:\n\n  1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the\n     md5sig_info container joins the rest of the md5sig lifecycle.\n     The local-variable lift is mechanical and required because\n     kfree_rcu() is a macro that expects an lvalue.\n\n  2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del +\n     kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct\n     tcp_md5sig_key already carries the rcu member\n     (include/net/tcp.h:1995) and tcp_md5_do_del()\n     (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this\n     restores the lifecycle invariant the rest of the file follows\n     rather than introducing a one-off.\n\nThe other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock()\n(net/ipv4/tcp.c:412), which runs from the sock destructor when the\nsocket is already unhashed and unreachable; the extra grace period\nthere is unnecessary but harmless. Making the helper unconditionally\nRCU-safe is the cleaner contract.\n\nThe needs_ao branch is not reachable by the userns reproducer used\nto demonstrate the AO-side splat (the repro installs both keys but\nends up in the needs_md5 branch because the connect peer matches\nthe MD5 key, not the AO key); however the symmetric race exists\nand a maintainer touching this code should not have to think about\nwhich branch escapes RCU and which one does not.\n\n[also credits to Qihang, who found that this races with tcp-diag]"
    }
  ],
  "id": "CVE-2026-72139",
  "lastModified": "2026-08-17T06:18:13.823",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 9.8,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-08-15T06:21:31.460",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/33a1bee413628378fd036a4f2b17ba86b0bc560c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b74cd55038905d5e74c1de109ab78a30b2ea0e1f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/da48b9bf1eb95a9cfd09d615ca58cfc2b03de369"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.