From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92A7138A72A for ; Wed, 13 May 2026 22:25:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778711155; cv=none; b=MtlsIwSOhs4CWiXCjb4lbNRdVqkKRpIkHOc0hUJwKBrOiTH33idk2lWBfuAdP+SjbNeo+4OpiIwK7EFfQuHpzrkZDQSG9ss520MEc0vZ1V+yh+CwbbHiAPXMLwFx3tVsvAXssGMV/eFGA8KtH1X/fFrPad03bRWLLLo7ac/sdBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778711155; c=relaxed/simple; bh=noh7GRB1Gf7yGrwZfJwFyhDDj5+mcLq1/fBuJK9XvXU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=AQAny6XEO1166aq+oD0OoSQcstzDa9B77f4WmmqbAPyJ7Bqi7PMjWszNdw0XXMTnhCkSPjb/hCdceP0oEP2FCygi5l4y2kGnzi7kf5A89hHUaDSJq5pajTqColYIZDKgo2FueJPMlp30mPx0AjH+oK5ypujbzMG15OyEKXgZdlY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ApOfw2Ez; arc=none smtp.client-ip=209.85.222.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ApOfw2Ez" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8cb40149037so678935685a.2 for ; Wed, 13 May 2026 15:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778711151; x=1779315951; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=49hbsMefGeWZo+jLb2kzmTEJRaJFF0WB/q/qItccdrw=; b=ApOfw2Ezlhlk/bhZ+k4A9DXKuzIsHxYyeL3jIDngqqWS3mTj67YbVZVmzn3IYVuAho 12WiQOeoJzyKXDjjzTZIQczNQUAlDkbMdjjKoIxisviEc/ZG+AVyZF9jvm+tKjLSW/Rx 2nTqMwrGG8UpAmsn5YSitKAecC3ZbRHFxPfWcPLUGpMvOv07mkRkTasO8i9O0YdaAZin 0wKqrM0ymuh7zOhaMyV7NmddcxE9veRGv8guxZHm5QjUVZ8P5XfsF2D5Cp7fDIXP3eKI Ii5wdvIjlizIR7byg2XVsJO4Qe2by/+GvPEACnVHFv4IBeaNvakT2bSwiONWBPDCpqs6 Hvmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778711151; x=1779315951; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=49hbsMefGeWZo+jLb2kzmTEJRaJFF0WB/q/qItccdrw=; b=O46AZwOOmkWvy0k+oQCzhJ845+D/jcjHNG/4Mkco2dyNdkeXXLazfLsDtT1K7VJ91T JEDM3SubWpovRCMjjopL/5Q4x7RcFxRdNaZ2cO+g8QlGX0zFXXNij2DykV3XDNka0MNT 0uZTcYGLpveeSAzDkVMYQppH6LrUqBKSaN2IjsKc3V6S5dZzgsdrS47VbK5411xgniL2 d6dSkWLrG5ngDyVm1UWhE6zav1mEbSWHyNX0N2l43cq3ul3/quHbIbKwaf3ZTaUO/Hyj XL12y1zynTFvYdJkeZvvMN1AaR3U4/7x41z77WYJw5P/wyopOZb2fVxO17rATe/iOlyZ eCVQ== X-Forwarded-Encrypted: i=1; AFNElJ+Uz2Z6S7vPXktWY17bNpSRo2FuxS/wQkWLJnocMPMm2jrNKiMCNGUYzq8nnfHmDMuOYiKoi1XiPEvNzlk=@vger.kernel.org X-Gm-Message-State: AOJu0YyMuXDizOnKdcs1yxCvZ8i7S4qTG9JLTh9dD1Q+X5LMnbencExq hlVdG3cvrqYJWL8r0qwB0qF+lxJdT5zZB1oFsBtEDFLWilNmhzSDPsZb X-Gm-Gg: Acq92OF5iknELXOXl2ofkddr0prwuJ+zzy5VeTTVbATZP5JvVQhkGp6Ww3A3xMw3ekA 9htza5eyDmY4Uj+BHwzK+QW4aqh1KksGthz131W11H74zTiL+O4H07c9Q7t8t+CICbqSXP4cr8P CH0i23PrB+nvjOhE/+v9KknUXMXeY+lXwf+XX2Pdkuzjr3QnTDnW4hVZymnOHSf9+8ALqglMnpQ SqFnFKo8rdjEXhQTOdPm3hWAR+3j56mqANYTwF46MQiVvsbjrRqENNSPZ7JRlGYHQlVZy+/dx0a ErAyA3r/MMi193BoTH40lDywpdm4nDOqTSPvK+G/iqBzomjtdyr8RmhY0grBDhfv1eZIOD5pNTg Zv8LoUawIV6raf625O2Q9zkT2TODdcTF6ZiCRkAVJAAm10B6yi0P3eugCBKx6zeRCpO4WN6g4vp AM/++of6aBQmPkZOY1USeeYG9yBe3wA+GKmPlTPkxTVU6uc84ux5B6k17oI5Fo29BeyICWTZ/eU KhgXcCaWSgMh7SXAdGrxWJSuOalDEc8lc0cic9bAS0= X-Received: by 2002:a05:620a:4808:b0:8d7:531:cb8e with SMTP id af79cd13be357-90f8b5c66efmr851275285a.49.1778711151563; Wed, 13 May 2026 15:25:51 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-910ba9454basm81938685a.12.2026.05.13.15.25.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 15:25:51 -0700 (PDT) From: Michael Bommarito To: Sakari Ailus , Bingbu Cao , Tianshu Qiu , Mauro Carvalho Chehab , linux-media@vger.kernel.org Cc: Hongju Wang , Hans Verkuil , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH] media: ipu6: return -EBUSY from busy video S_FMT Date: Wed, 13 May 2026 18:25:34 -0400 Message-ID: <20260513222534.2787169-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit ipu6_isys_vidioc_try_fmt_vid_cap() rejects video format changes once the vb2 queue is busy, but ipu6_isys_vidioc_s_fmt_vid_cap() ignores that return value and still commits the user supplied format to av->pix_fmt: ipu6_isys_vidioc_try_fmt_vid_cap(file, fh, f); av->pix_fmt = f->fmt.pix; That lets userspace allocate and queue buffers under one capture geometry, then change av->pix_fmt before STREAMON. The queued vb2 buffers keep their original plane sizes and payloads, while the IPU6 stream setup later derives firmware output width, height and stride from the mutated av->pix_fmt. On a Dell Precision 5490 with a Meteor Lake IPU (8086:7d19), Ubuntu 26.04's 7.0.0-14-generic kernel, and an ov01a10 sensor path through IVSC to /dev/video32, the following sequence reproduced the bad state: 1. set /dev/video32 to 640x480 BG10 2. REQBUFS and QBUF two mmap buffers 3. call VIDIOC_S_FMT again with 1280x800 BG10 The second S_FMT returned success and G_FMT reported 1280x800, while QUERYBUF still reported the old 615680 byte queued buffer lengths. A subsequent STREAMON on the same live sensor route wedged the host display/system hard enough to require a power cycle. No KASAN, IOMMU, oops or persistent crash record was captured, so this should be treated as a local availability failure rather than a demonstrated privilege escalation primitive. Return the try-format error before committing av->pix_fmt. This matches the metadata S_FMT path, which already checks vb2_is_busy() before assigning av->meta_fmt, and preserves the intended "no format changes while buffers exist" invariant. Tested on the same machine: with the patched modules loaded the busy S_FMT sequence above now returns -EBUSY and av->pix_fmt is left alone, while v4l2-compliance -d /dev/video0 still reports 48/48 pass. The existing compliance suite does not exercise S_FMT after REQBUFS, so adding a busy-queue case there would catch future regressions of this shape. Fixes: d3bd039cd2a0 ("media: intel/ipu6: support line-based metadata capture support") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Assisted-by: Claude:claude-opus-4-7 Assisted-by: Codex:gpt-5-5-xhigh --- drivers/media/pci/intel/ipu6/ipu6-isys-video.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/intel/ipu6/ipu6-isys-video.c b/drivers/media/pci/intel/ipu6/ipu6-isys-video.c index 3ac48d2076da..88fceab6ed86 100644 --- a/drivers/media/pci/intel/ipu6/ipu6-isys-video.c +++ b/drivers/media/pci/intel/ipu6/ipu6-isys-video.c @@ -323,8 +323,12 @@ static int ipu6_isys_vidioc_s_fmt_vid_cap(struct file *file, void *fh, { struct ipu6_isys_video *av = video_drvdata(file); + int ret; - ipu6_isys_vidioc_try_fmt_vid_cap(file, fh, f); + ret = ipu6_isys_vidioc_try_fmt_vid_cap(file, fh, f); + if (ret) + return ret; + av->pix_fmt = f->fmt.pix; return 0; } -- 2.53.0