{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-38595",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-38595"
  ],
  "published": "2025-08-19T17:19:12Z",
  "summary": "xen: fix UAF in dmabuf_exp_from_pages()",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: fix UAF in dmabuf_exp_from_pages()\n\n[dma_buf_fd() fixes; no preferences regarding the tree it goes through -\nup to xen folks]\n\nAs soon as we'd inserted a file reference into descriptor table, another\nthread could close it.  That's fine for the case when all we are doing is\nreturning that descriptor to userland (it's a race, but it's a userland\nrace and there's nothing the kernel can do about it).  However, if we\nfollow fd_install() with any kind of access to objects that would be\ndestroyed on close (be it the struct file itself or anything destroyed\nby its ->release()), we have a UAF.\n\ndma_buf_fd() is a combination of reserving a descriptor and fd_install().\ngntdev dmabuf_exp_from_pages() calls it and then proceeds to access the\nobjects destroyed on close - starting with gntdev_dmabuf itself.\n\nFix that by doing reserving descriptor before anything else and do\nfd_install() only when everything had been set up.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/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-38595"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/e5907885260401bba300d4d18d79875c05b82651"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3edfd2353f301bfffd5ee41066e37320a59ccc2d"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d59d49af4aeed9a81e673e37c26c6a3bacf1a181"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/532c8b51b3a8676cbf533a291f8156774f30ea87"
    }
  ],
  "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": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerability is reached through `IOCTL_GNTDEV_DMABUF_EXP_FROM_REFS` on the local `/dev/xen/gntdev` misc device, requiring local access to the machine (dom0 or a HVM/PVH guest). No network-facing path reaches `dmabuf_exp_from_pages()`.\nAC:L - The attacker controls both sides of the race \u2014 one thread issues the export ioctl while another closes the freshly installed fd, whose number is deterministic (lowest free descriptor) \u2014 and the window spans a sleepable `mutex_lock()`, making it wide; the ioctl can be retried indefinitely until it wins.\nPR:L - `gntdev_ioctl()` contains no `capable()` or `CAP_*` checks at all, so any user able to open `/dev/xen/gntdev` can trigger it; Xen stacks that use this exact dma-buf path (automotive display virtualization, Qubes vchan) grant unprivileged users access to that node.\nUI:N - Exploitation is entirely self-contained within the attacker's own multi-threaded process issuing an ioctl and a concurrent `close()`; no victim action is required.\nS:U - The freed objects (`struct gntdev_dmabuf`, the gntdev `struct file`) and the resulting corruption all live in the same kernel's memory as the attacker's own domain; nothing crosses the hypervisor or IOMMU boundary.\nC:H - `get_file(gntdev_dmabuf->priv->filp)` reads a pointer out of freed, attacker-groomable `kmalloc-96` memory, and `list_add()` writes kernel heap pointers into that freed slot which can be read back via a resprayed object, yielding kernel memory disclosure; the resulting `struct file` UAF permits arbitrary kernel read.\nI:H - The unmatched `fput()` on `priv->filp` underflows the gntdev file refcount and frees a `struct file` still referenced by an open fd, and the code writes into the freed `gntdev_dmabuf` (`->fd = ret`, `list_add`) \u2014 a classic UAF/DirtyCred-style write primitive leading to control-flow hijack and privilege escalation.\nA:H - Losing the race before `list_add()` makes `dmabuf_exp_release()` run `list_del()` on a zeroed `list_head`, causing a NULL-pointer write oops (or a corruption WARN plus heap/list corruption), and the general UAF and file refcount underflow readily panic the kernel."
    }
  }
}