{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89793",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89793"
  ],
  "published": "2026-09-16T09:52:57Z",
  "summary": "ublk: clear VM_MAYWRITE on read-only ublk char device mmap",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nublk: clear VM_MAYWRITE on read-only ublk char device mmap\n\nublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never\nclears VM_MAYWRITE on the resulting read-only mapping. This allows\na userspace daemon to mmap the per-queue command buffer PROT_READ,\nthen upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was\nnever cleared.\n\nThe command buffer holds struct ublksrv_io_desc entries that are\nkernel-written ABI; a writable mapping lets an unprivileged daemon\nprocess corrupt fields such as addr, op_flags, nr_sectors, and\nstart_sector.\n\nSame bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and\nthe 2026-08-13 ptp/vmclock fix (a5edadbae57e).\n\nVerified via mprotect() PoC: before the fix, a PROT_READ mapping can\nbe upgraded to PROT_READ|PROT_WRITE and a write into the command\nbuffer corrupts io_desc fields (confirmed under KASAN). After the\nfix, mprotect() returns -EACCES.",
  "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-2026-89793"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/be41733c24be58e2a1ef718c80fafdfb98a40d5e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5befd06a72216869b607cf7724a4f16c6a2d3999"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/e373c1acdbcf88cec533ece9f589020adaed0a78"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/fa5e1bc673ca59722608af67b27e65dba0c97926"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/6e2b571b0a54755b06e092501913e1dfefe75d6c"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-10-05T05:43:20Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The bug is reached only through local syscalls: open of /dev/ublkcN (created via /dev/ublk-control), mmap(PROT_READ) of the per-queue command buffer in ublk_ch_mmap(), then mprotect(PROT_WRITE). There is no network, Bluetooth, or physical-bus path into this mmap handler.\nAC:L - The attacker fully controls every step: mmap PROT_READ, mprotect PROT_WRITE, and write through the remap_pfn_range PFNMAP. mprotect upgrades the VMA because VM_MAYWRITE was left set (mm/mprotect.c), with no race, special layout, or victim state required.\nPR:L - ublk_ctrl_add_dev() lets a caller without CAP_SYS_ADMIN create a device with UBLK_F_UNPRIVILEGED_DEV, and ublk_ch_open() has no capability check, so an ordinary local user or a delegated unprivileged ublk daemon can open /dev/ublkcN and mmap the command buffer.\nUI:N - The attacking process performs the full create/open/mmap/mprotect/write sequence itself and can issue I/O to its own ublk disk to drive kernel re-reads of the corrupted descriptors. No other user must mount, open, or otherwise interact.\nS:U - The corrupted io_cmd_buf pages and the ublk/block I/O path that consumes them all sit in the host kernel's security authority. This is standard local kernel memory corruption, not a VM, IOMMU, or hypervisor boundary escape.\nC:H - The kernel re-reads iod->op_flags via ublk_iod_is_shmem_zc() on completion; setting UBLK_IO_F_SHMEM_ZC skips ublk_unmap_io(), so READ bios complete with uninitialized request/page-cache pages. That is the same uninitialized kernel-memory leak UBLK_F_SUPPORT_ZERO_COPY was denied to unprivileged devices to prevent.\nI:H - After mprotect, userspace has a writable PFNMAP of kernel-allocated io_cmd_buf pages and can overwrite kernel-written ublksrv_io_desc fields (op_flags, addr, nr_sectors, start_sector). The kernel then trusts op_flags to skip map/unmap, corrupting the block I/O data path for every consumer of that ublk disk.\nA:H - Clearing SHMEM_ZC with a null io->buf.addr forces ublk_start_io() into the mapped_bytes==0 requeue loop and stalls the request queue; completing I/O against corrupted descriptors or uninitialized pages can oops or hang the kernel. Attacker-triggerable kernel hang or crash is High."
    }
  }
}