{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-39932",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-39932"
  ],
  "published": "2025-10-04T07:33:57Z",
  "summary": "smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [    T138]  process_one_work+0x629/0xf80\n[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info->workqueue, &info->post_send_credits_work);",
  "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": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6ae90a2baf923e85eb037b636aa641250bf4220f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3fabb1236f2e3ad78d531be0a4ad9f4a4ccdda87"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d9dcbbcf9145b68aa85c40947311a6907277e097"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T12:19:11Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 9.8,
      "cvss_v3_severity": "Critical",
      "scenario": "AV:N - The vulnerable teardown path is the client's SMB Direct (RDMA) transport, driven entirely by the remote SMB server peer over iWARP/RoCE/IB \u2014 the peer triggers the disconnect that enters `smbd_destroy()` via `cifs_reconnect()`/`smbd_reconnect()` and controls the receive-credit traffic that requeues `post_send_credits_work`. This matches the established scoring of other client-side smbdirect flaws (e.g. CVE-2026-31609, CVE-2026-31535) as network-reachable.\nAC:L - The attacker owns both sides of the race: it initiates the RDMA disconnect that starts `smbd_destroy()`, it controls how many receive buffers are outstanding (and therefore how many `put_receive_buffer()` \u2192 `queue_work()` requeues `ib_drain_qp()` flushes), and it can force reconnect cycles indefinitely until it wins. The window is not narrow \u2014 the reporter hit it during ordinary rxe testing, and the worker's status check is a TOCTOU that a preempted worker bypasses without any signal or unusual state.\nPR:N - The SMB Direct transport connect/teardown and credit machinery sits below SMB session setup, so no credentials, capability, or account on the target are validated anywhere on the path to `smbd_post_send_credits()`. The remote peer needs no privileges on the client to reset the connection and drive the teardown.\nUI:N - Against an already-established SMB Direct mount \u2014 persistent deployment state, not participation in the compromise \u2014 the attacker completes the whole sequence by resetting the RDMA connection; the client's demultiplex thread enters `smbd_reconnect()` \u2192 `smbd_destroy()` automatically with no victim action.\nS:U - The freed QP, protection domain and receive buffers are all kernel-internal objects belonging to the same security authority as the faulting code. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - This is a use-after-free of the `ib_qp` freed by `rdma_destroy_qp()`, whose contents are read back by `ib_post_recv()`/`ib_post_send()` (`qp->device`, `qp->valid`, queue pointers) along with a stale `sc->ib.pd->local_dma_lkey`; reclaiming that slab lets an attacker read and exfiltrate kernel memory, and stale DMA mappings can expose freed receive buffers.\nI:H - `ib_post_recv()` dispatches through `qp->device->ops.post_recv` \u2014 a function pointer loaded from freed memory \u2014 giving a control-flow hijack primitive once the QP slab is sprayed, and the driver additionally writes a WQE and producer index into the freed ring, yielding a write primitive into reclaimed memory.\nA:H - The observed result is a kernel WARN/oops inside the workqueue worker, and after `sc->ib.qp = NULL` the same path is an outright NULL dereference; either panics the machine under `panic_on_oops` and otherwise wedges the SMB Direct connection, and the attacker can retrigger it on every reconnect."
    }
  }
}