public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Berkant Koc <me@berkoc.com>
To: security@kernel.org
Cc: Zack Rusin <zack.rusin@broadcom.com>,
	bcm-kernel-feedback-list@broadcom.com,
	dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	David Airlie <airlied@gmail.com>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: [REPORT] drm/vmwgfx: vmw_cmd_draw header.size lower-bound missing - guest-local OOB-read/write
Date: Sun, 17 May 2026 15:00:00 +0200	[thread overview]
Message-ID: <20260517-vmwgfx-uaf-report@berkoc.com> (raw)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi all,

Following the drm/qxl apply_reloc report from 14 May 2026
(prior thread: https://lore.kernel.org/virtualization/36acd33982bfdce04090e17294596ff8@berkoc.com/T/),
I audited the DRM cousin-drivers for the same bug-class. vmwgfx exposes a
stronger instance.

Primary site: `vmw_cmd_draw` in
`drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:1558-1607`. The verifier does

    maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl);
    if (cmd->body.numVertexDecls > maxnum) return -EINVAL;

Commit `32b415a9dc2c` ("drm/vmwgfx: Validate command header size against
SVGA_CMD_MAX_DATASIZE", Oct 2025) added the upper bound but not the
lower bound. With `header->size < sizeof(cmd->body)` the size_t
subtraction wraps, `maxnum` becomes ~SIZE_MAX, and the loop walks
attacker-chosen `numVertexDecls` entries past the cmd-buffer. Each
iteration is a 4-byte OOB-read via `vmw_cmd_res_check`; on a handle
collision `vmw_resource_relocation_add` records the OOB address as
`rel->offset` (29-bit), and `vmw_resource_relocations_apply` later does
a 32-bit kernel write at `cb + rel->offset` within a 512 MiB window.

Exploitability split:
  - OOB-read at first iteration is deterministic.
  - OOB-write requires `id_loc` to resolve to a valid surface handle;
    surface-spray makes this practical but the write side is probabilistic.

Two cousin sites share the same root cause (details in BUG.md):
  - `vmw_cmd_dma` (line 1495): pointer underflow -> 4-byte OOB-read of
    `suffix->suffixSize`.
  - `vmw_cmd_shader_define` (line 1898): `size = header.size - sizeof(body)`
    wraps and reaches `vmw_compat_shader_add`; ENOMEM-bounded DoS.

Reachability: DRM_VMW_EXECBUF, DRM_RENDER_ALLOW. Any `/dev/dri/renderD128`
user (default `video` group) on a VMware or KVM SVGA-II guest. No DRM_AUTH,
no DRM_MASTER, no root.

CVSS 3.1: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` -> 7.8 High
(deterministic OOB-read, probabilistic 32-bit kernel write within 512 MiB;
guest-local LPE, no host escape claimed).

Suggested fix: per-site lower-bound check on `header->size` before the
subtraction, or the safe pattern using `check_mul_overflow` /
`check_add_overflow`. A draft patch is sent as the follow-up RFC in
this thread.

Attachments: BUG.md (full trace) and repro.c (KASAN-trigger PoC, no
exploitation).

Happy to follow your standard timeline per Documentation/process/security-bugs.rst
(typically <=7 days post-fix-merge).

Berkant Koc <me@berkoc.com>
GPG: 0C58 8DFD 7620 4987 2842 13EA 0AC5 29C4 1F8A A5D6
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQMWI39diBJhyhCE+oKxSnEH4ql1gUCagm/bwAKCRAKxSnEH4ql
1i1PAQCXhrf6CdxpwCifgpjYZJdzspd9dckht9le4AeUJpKRpwD/csbOYVl+oMDY
mekPtFhNq+TujSRVzvRZ0MKzOawzAwU=
=7oh3
-----END PGP SIGNATURE-----

             reply	other threads:[~2026-05-17 13:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-17 13:00 Berkant Koc [this message]
2026-05-17 13:37 ` [REPORT] drm/vmwgfx: vmw_cmd_draw header.size lower-bound missing - guest-local OOB-read/write Greg KH
2026-05-17 13:05   ` [PATCH] drm/vmwgfx: validate execbuf header.size lower bound Berkant Koc
2026-05-17 23:23     ` Zack Rusin
2026-05-18  0:56       ` Berkant Koc
2026-05-18  6:07     ` Claude review: " Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260517-vmwgfx-uaf-report@berkoc.com \
    --to=me@berkoc.com \
    --cc=airlied@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=security@kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=zack.rusin@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox