{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-36945",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-36945"
  ],
  "published": "2024-05-30T15:36:11Z",
  "summary": "net/smc: fix neighbour and rtable leak in smc_ib_find_route()",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix neighbour and rtable leak in smc_ib_find_route()\n\nIn smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable\nresolved by ip_route_output_flow() are not released or put before return.\nIt may cause the refcount leak, so fix it.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.91",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d5a466ab6e78d6f2e0f64435f1e17246c8e941ff"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5df93c029a907b0ff5a4eeadd77ba06ff0a277d2"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/da91e447d06dc649fcf46e59122e7bf8f0b2e0db"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2ddc0dd7fec86ee53b8928a5cca5fbddd4fc7c06"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.5,
      "cvss_v3_severity": "High",
      "scenario": "AV:N - The leak is triggered while processing SMC CLC handshake messages received over TCP from a remote peer \u2014 the server path takes `daddr` straight from the peer's CLC Proposal v2 extension GID (`af_smc.c:2323`) and the client path from the peer's CLC Accept GID (`af_smc.c:1245`). No local access, and no RDMA fabric connectivity to the attacker is needed since the handshake is ordinary TCP.\nAC:L - The missing `neigh_release()`/`ip_rt_put()` is unconditional \u2014 every successful route resolution leaks, with no race to win and no memory-layout dependency, and the attacker fully controls `daddr` via the GID it advertises. In an SMC-Rv2 deployment (the scenario in which this code runs at all) the attacker just opens TCP connections in a loop to accumulate leaked references.\nPR:N - `smc_listen_work()` processes the CLC Proposal immediately after TCP accept, before any credential check exists \u2014 SMC has no authentication, and the UEID compared in `smc_clc_match_eid()` is a cleartext fabric identifier the client itself broadcasts in its proposal, not a secret. The client-side path via `smc_connect_rdma_v2_prepare()` requires no EID from the attacker at all.\nUI:N - The attacker initiates the TCP connection to a victim SMC listener and drives the entire handshake itself; the listen worker runs asynchronously with no action by any local user.\nS:U - The leaked `rtable`, `neighbour` and pinned `net_device` references all remain within the kernel's own resource domain, and no VM/host, IOMMU, or sandbox boundary is crossed.\nC:N - Only reference counts are leaked \u2014 no freed or out-of-bounds memory is read, and nothing from kernel memory is copied back to the peer or to userspace. `nexthop_mac` is filled from a validly-held neighbour before the leak occurs.\nI:N - The bug is a missing decrement, which is the safe direction \u2014 no object is freed early, so there is no UAF, write primitive, or control-flow impact, and both `rcuref` (dst) and `refcount_t` (neigh) saturate with a warning rather than wrapping to zero.\nA:H - Each leaked `dst` and `neighbour` permanently pins a `net_device` reference (`netdev_hold()` in `dst_init()`/`neigh_alloc()`), so device unregistration and network-namespace teardown hang forever in the `unregister_netdevice: waiting for %s to become free` loop, blocking the global `cleanup_net` worker. Additionally, `neigh_forced_gc()` skips any entry with refcount > 1, so an unauthenticated peer varying its advertised GID mints unreclaimable ARP entries until `gc_thresh3` overflow breaks all neighbour resolution on the host, alongside unbounded kernel memory growth."
    }
  }
}