{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-64541",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-64541"
  ],
  "published": "2026-07-27T20:10:44Z",
  "summary": "net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket\n\nsmc_cdc_rx_handler() looks up the connection by token under the link\ngroup's conns_lock, drops the lock, and then dereferences conn and the\nsmc_sock derived from it, ending in sock_hold(&smc->sk) inside\nsmc_cdc_msg_recv(). No reference is held across the lock release.\n\nThe only reference pinning the socket while the connection is\ndiscoverable in the link group is taken in smc_lgr_register_conn()\n(sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both\nunder conns_lock. Once the handler drops conns_lock, a concurrent\nclose() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn()\ncan drop that reference and free the smc_sock, so the handler's later\nsock_hold() runs on freed memory:\n\n  WARNING: lib/refcount.c:25 at refcount_warn_saturate\n  Workqueue: rxe_wq do_work\n   refcount_warn_saturate (lib/refcount.c:25)\n   smc_cdc_msg_recv (net/smc/smc_cdc.c:430)\n   smc_cdc_rx_handler (net/smc/smc_cdc.c:502)\n   smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445)\n   tasklet_action_common (kernel/softirq.c:938)\n   handle_softirqs (kernel/softirq.c:622)\n  Kernel panic - not syncing: panic_on_warn set\n\nOnly SMC-R is affected. The SMC-D receive tasklet is stopped by\ntasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection\nis unregistered, so it cannot run concurrently with the free.\n\nTake the socket reference while still holding conns_lock, so the\nregistration reference can no longer be the last one, and drop it once\nthe handler is done.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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.178",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64541"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8de4f665d0febfb92803dece377791a563fc7041"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8145b432136285e01091815b48ceb2dae261f262"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1951bffbc6493ec34cff3956b29d4bc6606904a6"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/647b19e5cc145a2f1f685ae8ff3805a17356888c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/472e9d7c0d5b03be3ff91ff941f57da822b031bc"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3bfb96d9bc6a7ed0b99c7db329cc2e22a28d84bb"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ce5aa8084329351086894aa34d77e40301d5bd3d"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/9d160b35cc34a2ba8229d07651468a7848325135"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-17T05:24:08Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 9.8,
      "cvss_v3_severity": "Critical",
      "scenario": "AV:N - The vulnerable handler is driven entirely by a CDC control message sent by the remote SMC-R peer over the RDMA link, with an attacker-chosen `token` field and no local syscall involvement. SMC-R runs over RoCEv2 (IP/UDP-routable, port 4791) with the CLC handshake over plain TCP, and SMC-Rv2 explicitly supports non-local/routed peers, so the attacker need not share an L2 segment.\nAC:L - The attacker controls both sides of the race: it chooses when to emit CDC messages and which connection to target (the alert token is disclosed to it in the CLC accept/confirm), and it can drive the teardown side itself via CDC close/abort flags into `smc_close_passive_work()` or a stale seqno with `failover_validation` into `abort_work` -> `smc_conn_kill()`. The race can be retried indefinitely across many connections in the same link group, and was reproduced in practice with soft-RoCE.\nPR:N - Establishing an SMC-R connection to a listening SMC socket requires no credentials \u2014 SMC has no authentication layer of its own, exactly like plain TCP. Everything after connection establishment (sending CDC messages with a chosen token, signalling close/abort) is available to an unauthenticated peer.\nUI:N - The CDC message is processed in a softirq tasklet from the RDMA completion queue with no involvement from any local user or application action. No victim interaction of any kind is needed.\nS:U - The corruption is confined to kernel memory within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed. This is a standard in-kernel use-after-free.\nC:H - The freed `smc_sock` is reused type-safely as another live socket, so attacker-supplied cursors applied by `smc_cdc_msg_recv_action()` break the `0 <= bytes_to_rcv <= rmb_desc->len` invariant and make `smc_rx_recvmsg()` hand stale RMB contents to userspace, while the urgent-data path reads `*(base + conn->urg_curs.count - 1)` at an attacker-chosen offset. Once the slab page is reclaimed after the RCU grace period, reuse is unconstrained, giving a general kernel-memory read primitive.\nI:H - `sock_hold()` on an already-zero refcount followed by `sock_put()` re-enters `sk_free()`, yielding a double free, and the handler additionally writes `sk_err`/`sk_shutdown`, makes indirect calls through `sk_data_ready()`/`sk_write_space()`, and `queue_work()`s a freed `work_struct`. These are classic heap-spray and control-flow-hijack primitives leading to arbitrary kernel write.\nA:H - The reported symptom is `refcount_warn_saturate` from `smc_cdc_msg_recv()`, which is an immediate kernel panic on `panic_on_warn` systems, and dereferencing freed memory in softirq context otherwise oopses. The attacker can trigger it repeatedly without authentication."
    }
  }
}