{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-35882",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-35882"
  ],
  "published": "2024-05-19T08:35:32Z",
  "summary": "SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix a slow server-side memory leak with RPC-over-TCP\n\nJan Schunk reports that his small NFS servers suffer from memory\nexhaustion after just a few days. A bisect shows that commit\ne18e157bb5c8 (\"SUNRPC: Send RPC message on TCP with a single\nsock_sendmsg() call\") is the first bad commit.\n\nThat commit assumed that sock_sendmsg() releases all the pages in\nthe underlying bio_vec array, but the reality is that it doesn't.\nsvc_xprt_release() releases the rqst's response pages, but the\nrecord marker page fragment isn't one of those, so it is never\nreleased.\n\nThis is a narrow fix that can be applied to stable kernels. A\nmore extensive fix is in the works.",
  "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.6.20-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-2712",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v6",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v7",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v7l",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v8",
            "binary_version": "1:6.6.20-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.6.20-1+rpt1": {
            "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668",
            "upstream_version": "6.6.20",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.6.26"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-35882"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1ba1291172f935e6b6fe703161a948f3347400b8"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a2ebedf7bcd17a1194a0a18122c885eb578ee882"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/05258a0a69b3c5d2c003f818702c0a52b6fea861"
    }
  ],
  "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 in the server-side SUNRPC transmit path used by nfsd/lockd over TCP; it is triggered by sending an RPC to the listening socket from any remote host that can reach the service.\nAC:L - No race, timing, or memory-layout condition is involved \u2014 every RPC reply leaks the record-marker fragment deterministically, and every new TCP connection leaks a full 32 KB page.\nPR:N - svc_process_common() emits a reply (and thus allocates the leaked marker) via its err_bad_prog/err_bad_vers/err_bad_proc/err_bad_auth paths and for the NULL procedure, so no valid credentials or export membership are needed.\nUI:N - The attacker drives the entire sequence by connecting and sending RPC traffic; no action by a local user or administrator is required.\nS:U - The leaked memory and the resulting exhaustion are confined to the kernel of the NFS server itself, with no crossing of a virtualization, IOMMU, or sandbox boundary.\nC:N - The bug only fails to release a reference on a page fragment; no kernel memory contents are disclosed to the attacker and there is no out-of-bounds read.\nI:N - No memory is corrupted or overwritten \u2014 the fragment is simply never freed, so no data or control-flow integrity is affected.\nA:H - __page_frag_cache_drain() cannot free the 32 KB order-3 page because the never-released marker fragment holds the last reference, so each unauthenticated connection permanently leaks up to 32 KB; a remote attacker looping connect/send/close exhausts server memory and triggers OOM, and real deployments died of memory exhaustion under normal load."
    }
  }
}