{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89530",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89530"
  ],
  "published": "2026-09-11T19:47:07Z",
  "summary": "svcrdma: Reject inline replies that overflow the pull-up buffer",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Reject inline replies that overflow the pull-up buffer\n\nAn RPC-over-RDMA client can request a reply, such as an NFS READ\npayload, without providing a Write list or a Reply chunk to carry\nit. When such a reply needs more scatter/gather entries than the\ndevice's Send Queue supports, svc_rdma_pull_up_needed() selects\npull-up and svc_rdma_pull_up_reply_msg() linearizes the whole\nreply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size\nbytes, while the reply on this path is bounded only by the client's\nrequest, so svc_rdma_xb_linearize() copies past the end of the\nbuffer and corrupts adjacent slab memory. The oversized length is\nthen stored in sc_sges[0].length and posted, so the device also\nreads beyond the mapped region.\n\nThe SGE-exhaustion branch is the only pull-up path that can exceed\nthe buffer: the threshold branch pulls up only replies smaller\nthan RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE\nbudget are sent directly without linearization. Make\nsvc_rdma_pull_up_needed() report -E2BIG when the reply it would\npull up cannot fit sc_max_req_size, and fail the request with\nERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping\nthe connection.\n\nThe helper no longer answers a simple yes/no question: it now\nreports pull-up, no pull-up, or -E2BIG for a reply too large to\nlinearize. Rename svc_rdma_pull_up_needed() to\nsvc_rdma_check_pull_up() so its name no longer implies a boolean\npredicate.",
  "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-2026-89530"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/fcd91b9957462d398792201c239dffaeff1cc8b2"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1949dd1576f7a8aa161b1330c6125df9d53046d5"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8ec60eb51fae37cd3d334ff26e4a7d6fb21ff7cf"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/0fbe20dfe74b783d255bf389a6ea77aa25dc7860"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-13T06:49:25Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 9.8,
      "cvss_v3_severity": "Critical",
      "scenario": "AV:N - svcrdma is nfsd's RPC-over-RDMA server transport; a remote NFS/RDMA client reaches svc_rdma_sendto over InfiniBand, RoCE, or iWARP, including IP-routable RoCEv2/iWARP and Soft-RoCE, so this is a network attack.\nAC:L - The attacker fully controls omitting the Write list and Reply chunk and the NFS READ size; with the default 4096-byte pull-up buffer and ~5 Send SGEs, a multi-page inline READ deterministically takes the SGE-exhaustion pull-up path and overflows, with no race or uncontrollable layout.\nPR:N - RDMA-CM accept has no credential check, and AUTH_NULL/AUTH_UNIX need no real account; default NFS exports accept those flavors, so a fabric peer can drive a large READ reply without local or init-namespace privileges.\nUI:N - Exploitation requires only attacker-sent RPC-over-RDMA Calls that elicit a large inline reply; no victim mount, click, or other user action is needed beyond nfsd already listening on RDMA.\nS:U - The kmalloc overflow and oversized RDMA Send stay inside the host kernel's security authority; this is not a VM, IOMMU, or sandbox escape.\nC:H - svc_rdma_xb_linearize() copies past kmalloc sc_xprt_buf, then the inflated sc_sges[0].length is posted with the PD local DMA lkey, so the device reads adjacent kernel memory onto the wire; the heap smash is also leveragable for disclosure.\nI:H - The unbounded memcpy is a heap out-of-bounds write of attacker-influenced NFS READ payload into adjacent slab objects, enabling corruption of neighboring kernel state and control-flow hijacking.\nA:H - Overflowing a 4KB send buffer by up to the NFS/RDMA max payload smashes adjacent slab and can oops or panic, and posting an SGE longer than the DMA mapping can also fault the device or kernel."
    }
  }
}