Skip to content

(release/25.2) Xext: xvmc: guard against NULL screen private in ProcXvMCGetDRInfo#3111

Open
metux wants to merge 1 commit into
release/25.2from
pr/release/25.2-xext-xvmc-guard-against-null-screen-private-in-procxvmcgetdrinfo-_2026-06-23_20-00-37
Open

(release/25.2) Xext: xvmc: guard against NULL screen private in ProcXvMCGetDRInfo#3111
metux wants to merge 1 commit into
release/25.2from
pr/release/25.2-xext-xvmc-guard-against-null-screen-private-in-procxvmcgetdrinfo-_2026-06-23_20-00-37

Conversation

@metux

@metux metux commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Backport dashboard

Master: #2970 ✅ merged

Branch PR Status
release/25.2 #3111 ⬜ open ← this PR

Auto-generated backport dashboard — links the source master PR and sibling backports with their merge status.


Backport of #2970 to release/25.2.

Clean cherry-pick — release/25.2 carried the identical pre-fix code at the same path. (release/25.1 already contains the fix; release/25.0 already contains it or predates the affected code — see the backport dashboard on #2970.)


ProcXvMCGetDRInfo() fetched the per-screen XvMC private with
XVMC_GET_PRIVATE() and immediately dereferenced it
(strlen(pScreenPriv->clientDriverName)). The private is NULL for any screen on
which XvMCScreenInit() was never called, while the extension and its private
key become available globally as soon as any screen enables XvMC.

A local client owning a valid Xv port on a non-XvMC screen (e.g. a multi-GPU
setup where only one screen has XvMC) could thus crash the server. The three
other port-taking XvMC handlers already check for NULL; do the same here and
return BadMatch.

Fixes: 3b0dce3 ("lib/XvMC/Imake Added support for automatic loading of the correct hardware XvMC driver.")
Signed-off-by: Enrico Weigelt, metux IT consult info@metux.net
(cherry picked from commit 6db14d0)

ProcXvMCGetDRInfo() fetched the per-screen XvMC private with
XVMC_GET_PRIVATE() and immediately dereferenced it
(strlen(pScreenPriv->clientDriverName)). The private is NULL for any screen on
which XvMCScreenInit() was never called, while the extension and its private
key become available globally as soon as any screen enables XvMC.

A local client owning a valid Xv port on a non-XvMC screen (e.g. a multi-GPU
setup where only one screen has XvMC) could thus crash the server. The three
other port-taking XvMC handlers already check for NULL; do the same here and
return BadMatch.

Fixes: 3b0dce3 ("lib/XvMC/Imake Added support for automatic loading of the correct hardware XvMC driver.")
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
(cherry picked from commit 6db14d0)
@metux

metux commented Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Automated review — generated by Claude Code on behalf of @metux. Not a human review.

Backport review — #3111release/25.2 (cherry-pick of #2970).

Applicability: confirmed. release/25.2's Xext/xv/xvmc.c ProcXvMCGetDRInfo() does pScreenPriv = XVMC_GET_PRIVATE(pScreen); then immediately strlen(pScreenPriv->clientDriverName) / strlen(pScreenPriv->busID) with no NULL check — the deref of a NULL per-screen private (port on a non-XvMC screen) is present.

Correctness: good. Adding if (!pScreenPriv) return BadMatch; before the dereference matches the three sibling port-taking XvMC handlers and the master fix. CI green.

Backport-worthiness: yes — NULL-pointer deref / server crash (DoS) reachable by a local client with a valid Xv port on a non-XvMC screen (multi-GPU).

Driver/NVIDIA ABI: no impact — local NULL guard in an Xv/XvMC handler; no public struct or _X_EXPORT symbol touched.

Verdict: PASS. Merge decision is the maintainer's (release lines are manual-merge only).

@metux metux added the bot-review-passed Automated bot review found no blocking issues label Jun 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bot-review-passed Automated bot review found no blocking issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant