ghsa-6237-rh4h-82p6
Vulnerability from github
Published
2025-09-05 18:31
Modified
2025-09-05 18:31
Details

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nf_conntrack_cleanup_net_list() will wait forever.

This can be reproduced by running conntrack_resize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.

One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlink_exp_dump_table, it looks to me as if this has the same problem and like ctnetlink_dump_table, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-38721"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T16:15:41Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: fix refcount leak on table dump\n\nThere is a reference count leak in ctnetlink_dump_table():\n      if (res \u003c 0) {\n                nf_conntrack_get(\u0026ct-\u003ect_general); // HERE\n                cb-\u003eargs[1] = (unsigned long)ct;\n                ...\n\nWhile its very unlikely, its possible that ct == last.\nIf this happens, then the refcount of ct was already incremented.\nThis 2nd increment is never undone.\n\nThis prevents the conntrack object from being released, which in turn\nkeeps prevents cnet-\u003ecount from dropping back to 0.\n\nThis will then block the netns dismantle (or conntrack rmmod) as\nnf_conntrack_cleanup_net_list() will wait forever.\n\nThis can be reproduced by running conntrack_resize.sh selftest in a loop.\nIt takes ~20 minutes for me on a preemptible kernel on average before\nI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.\n\nOne fix would to change this to:\n        if (res \u003c 0) {\n\t\tif (ct != last)\n\t                nf_conntrack_get(\u0026ct-\u003ect_general);\n\nBut this reference counting isn\u0027t needed in the first place.\nWe can just store a cookie value instead.\n\nA followup patch will do the same for ctnetlink_exp_dump_table,\nit looks to me as if this has the same problem and like\nctnetlink_dump_table, we only need a \u0027skip hint\u0027, not the actual\nobject so we can apply the same cookie strategy there as well.",
  "id": "GHSA-6237-rh4h-82p6",
  "modified": "2025-09-05T18:31:17Z",
  "published": "2025-09-05T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38721"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/19b909a4b1452fb97e477d2f08b97f8d04095619"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30cf811058552b8cd0e98dff677ef3f89d6d34ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/41462f4cfc583513833f87f9ee55d12da651a7e3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/586892e341fbf698e7cbaca293e1353957db725a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/962518c6ca9f9a13df099cafa429f72f68ad61f0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a2cb4df7872de069f809de2f076ec8e54d649fe3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a62d6aa3f31f216b637a4c71b7a8bfc7c57f049b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de788b2e6227462b6dcd0e07474e72c089008f74"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e14f72aa66c029db106921d621edcedef68e065b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.