From: Natasha Klaus <natalie.klaus@runtimeverification.com>
To: laurent.pinchart@ideasonboard.com, hansg@kernel.org, mchehab@kernel.org
Cc: ribalda@chromium.org, noambs2999@gmail.com,
david.laight.linux@gmail.com, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org,
Natasha Klaus <natalie.klaus@runtimeverification.com>
Subject: [PATCH 3/3] media: uvcvideo: Skip frame descriptors with a zero computed size
Date: Thu, 20 Aug 2026 12:56:26 +0300 [thread overview]
Message-ID: <20260820095626.111196-4-natalie.klaus@runtimeverification.com> (raw)
In-Reply-To: <20260820095626.111196-1-natalie.klaus@runtimeverification.com>
For uncompressed formats uvc_parse_frame() recomputes
dwMaxVideoFrameBufferSize from the frame dimensions and the bits per
pixel. All three operands are read straight from the descriptor bytes
with no range check, so the computed size is zero whenever any of them
is zero.
A zero size is not harmless. It is copied into
ctrl->dwMaxVideoFrameSize by uvc_fixup_video_ctrl() and reaches
uvc_queue_setup() as the vb2 plane size, where it trips
WARN_ON(!plane_sizes[i]) in vb2_core_reqbufs() at
drivers/media/common/videobuf2/videobuf2-core.c:951 and fails
VIDIOC_REQBUFS with -EINVAL. On a kernel built with panic_on_warn that
WARN is fatal.
Such a frame can also become the active one without any application
asking for it: when no frame matches the device's default bFrameIndex,
uvc_video_init() falls back to frames[0], so a device that also has
usable frames can come up unusable.
Skip the frame rather than rejecting the descriptor, which would discard
the whole streaming interface and every valid format on it. This follows
commit 81f3affa19d6 ("media: uvcvideo: Don't expose unsupported formats
to userspace"), which drops a format descriptor the driver cannot use
for the same reason: to keep it from reaching userspace and triggering a
WARN_ON.
Signed-off-by: Natasha Klaus <natalie.klaus@runtimeverification.com>
---
Depends on 1/3 for -EINVAL to mean "skip this frame", and on 2/3 for the
bufsize local.
After 2/3 rounds up instead of truncating, the computed size is zero only
when one of bpp, wWidth or wHeight is zero; the "product below 8 truncates
to zero" case no longer exists.
drivers/media/usb/uvc/uvc_driver.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index eb7177ea291d..3bd8d31e1378 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -308,6 +308,20 @@ static int uvc_parse_frame(struct uvc_device *dev,
return -EINVAL;
}
+ /*
+ * A zero-sized frame is unusable: it reaches vb2 as a zero
+ * plane size, and it is reported to userspace as a 0x0 frame
+ * with a zero sizeimage. Skip the frame descriptor, the
+ * caller moves on to the next one.
+ */
+ if (!bufsize) {
+ dev_warn(&streaming->intf->dev,
+ "UVC non compliance: FRAME %u has zero size (%ux%u, %u bpp), skipping it.\n",
+ frame->bFrameIndex, frame->wWidth,
+ frame->wHeight, format->bpp);
+ return -EINVAL;
+ }
+
frame->dwMaxVideoFrameBufferSize = bufsize;
}
--
2.34.1
next prev parent reply other threads:[~2026-08-20 9:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 9:56 [PATCH 0/3] media: uvcvideo: harden the frame buffer size computation Natasha Klaus
2026-08-20 9:56 ` [PATCH 1/3] media: uvcvideo: Let uvc_parse_frame() report a skipped frame Natasha Klaus
2026-08-20 10:29 ` Ricardo Ribalda
2026-08-20 9:56 ` [PATCH 2/3] media: uvcvideo: Fix integer overflow in frame buffer size calculation Natasha Klaus
2026-08-20 10:26 ` Ricardo Ribalda
2026-08-20 9:56 ` Natasha Klaus [this message]
2026-08-20 10:31 ` [PATCH 3/3] media: uvcvideo: Skip frame descriptors with a zero computed size Ricardo Ribalda
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=20260820095626.111196-4-natalie.klaus@runtimeverification.com \
--to=natalie.klaus@runtimeverification.com \
--cc=david.laight.linux@gmail.com \
--cc=hansg@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=noambs2999@gmail.com \
--cc=ribalda@chromium.org \
/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