GHSA-HC39-XG82-JGF4

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-19 15:30
VLAI?
Details

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

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fib_table_flush() is called to flush all the routes that are using the dead nexthop.

The current logic in fib_table_flush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flush_all=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71097"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T16:16:09Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: Fix reference count leak when using error routes with nexthop objects\n\nWhen a nexthop object is deleted, it is marked as dead and then\nfib_table_flush() is called to flush all the routes that are using the\ndead nexthop.\n\nThe current logic in fib_table_flush() is to only flush error routes\n(e.g., blackhole) when it is called as part of network namespace\ndismantle (i.e., with flush_all=true). Therefore, error routes are not\nflushed when their nexthop object is deleted:\n\n # ip link add name dummy1 up type dummy\n # ip nexthop add id 1 dev dummy1\n # ip route add 198.51.100.1/32 nhid 1\n # ip route add blackhole 198.51.100.2/32 nhid 1\n # ip nexthop del id 1\n # ip route show\n blackhole 198.51.100.2 nhid 1 dev dummy1\n\nAs such, they keep holding a reference on the nexthop object which in\nturn holds a reference on the nexthop device, resulting in a reference\ncount leak:\n\n # ip link del dev dummy1\n [   70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2\n\nFix by flushing error routes when their nexthop is marked as dead.\n\nIPv6 does not suffer from this problem.",
  "id": "GHSA-hc39-xg82-jgf4",
  "modified": "2026-01-19T15:30:36Z",
  "published": "2026-01-13T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71097"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30386e090c49e803c0616a7147e43409c32a2b0e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/33ff5c207c873215e54e6176624ed57423cb7dea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5979338c83012110ccd45cae6517591770bfe536"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5de7ad7e18356e39e8fbf7edd185a5faaf4f385a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ac782f4e3bfcde145b8a7f8af31d9422d94d172a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e3fc381320d04e4a74311e576a86cac49a16fc43"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee4183501ea556dca31f5ffd8690aa9fd25b609f"
    }
  ],
  "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 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.