All of lore.kernel.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: 5+ 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

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.