From nobody Fri Jul 24 21:53:01 2026 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 D9D4A4908B5 for ; Thu, 23 Jul 2026 20:55:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784840122; cv=none; b=HlAHVkcI/SanhmZR364/mXJ8CxVu71y2VzpWaTgdyU7kqyit90Uc5iHMb0EBNTXnPVQQfrh99gZqqUNjiCuY8Dc55OJVWu5JaZJzD0ktAHr6VYDWkasZ+my+o9lSxuZLnu1y/WucptSD/m2FOXrQ3R0uqqtty3yTULkSB/WWBAM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784840122; c=relaxed/simple; bh=kpNpmXP2zUcfvgI+VUB/mqBaz21ktP2Izhk8EyYE0Ng=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mhYikhvvQPagUNwj1CkO2fwQ1TIxy45l8meD5ce1oM70D62oha5ih4E60/WqzrjeYOE4Mie6iYFDjqRZX9e+E6evo7rri0cC33BgAA3y4FhJkRq0F2U0UrkZpOucpRRGcwniIk1HNbXuv+YH2NM/4pZhrzAiNnxK+DgtpkHqiNw= 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=dwP/4SFp; arc=none smtp.client-ip=209.85.222.182 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="dwP/4SFp" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-92f03daaa97so105755685a.2 for ; Thu, 23 Jul 2026 13:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784840120; x=1785444920; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZLkFGK35XJxgAtHBySSU6z2wsXFjqNEj24rUwtelC/Y=; b=dwP/4SFp/Kl/ZP8TH8yvyCAr0AKapl/J/FzcRiUzzYLqRjqZi9/bRKxUYcd082yDPd D7LfRtY+W85sBMrzWwR6bvtYht7MQvxvC8Q7PlDqGsrJnz2g06NIPbGbKGcQ8BUKtrTF GsHroYrbBby4cnFnRD6aeKQ7TzXMYgST7HDVWAPUjKpucLUe38a9SUEeZl5UBYEwhiGg OWafKL1pmt/vynfh5GX37Gu/bc4jK2xfbBnF+SLYqi4xUoxpQUsoN47+bsPs8+ljmIQb 5o/G9GqGVb4dnm/gHwo61z51tsp7pyXfXdPp/OpxbSu1jCwqzgle7QV0XKxg9U9ptYXZ 2XEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784840120; x=1785444920; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ZLkFGK35XJxgAtHBySSU6z2wsXFjqNEj24rUwtelC/Y=; b=pUi2tGULUXCgi/zTeNmhpj2MBxO8RFbNuZUOGqIV54QibauA1WY1qECuc9bion1+rk jU52osgfX1pBN0503xZojiXzLue06+Z8ykdA5+pph3ZHax7f16NpfJdMA+YaOwN59hyh kQS/bmYNc417g9G6GNQS+WQgz8VhtSRhZpi0qq+99yrcKFSO0XtHbROZsBiXja4OoMz0 YMFCWUgd49S/MgHqmcFO0o6UGSw/iUT+RftclXAYe4fEcXah76XCefBWF9WEoLHy/R/k LjL3jUV7qWXqn6lMpmMCjmNchH3KQuM6GYegl0qrCYlyl6il0pTKrVxG3Zi8AKUZuz9v D7lA== X-Forwarded-Encrypted: i=1; AHgh+RqBubYj6KzzsIhjIM6jR0rMspso6FNqSkHtwsn/eASoBqT9TDnPh12NpPOXGcN02A+3/xNpXJqIMcQlTTo=@vger.kernel.org X-Gm-Message-State: AOJu0YyfCnwWirk7WS16bHh3CchW0XTMp69rR8bJRg7ZGq5vXXZOaNvW 4fNyXIqilG+YZHohOmQhA5avC6llLen5YDsC73k6OsbspC4hbARbkHg5 X-Gm-Gg: AR+sD13Turckg3reHfYb/XoixztqHT2oqFo9sUxpGteG+w++euO/aUejC/OXIqmatCW UeiDtL9e4fDibL2PibD1ZQCq922AdcbdS3hv5nnynVVfv22YwIKmg3vJyx7yar6LITv9tUrl8Oc p6AO30v9x54eKdusb8N51OiWHvygIyi7WZOWJ2CyKpgtqD9nx2LoAlE8kftmj0Th5rEvxscFMaL MhqwMRjEKh6MLQYMMfuzO5T8qcEFrCWBSuD+vbtriPzYyzBg+rQ6aSmb/04/vNi9hVgHs8MIP7y AYomBoZPEdLHWWAHj7LoJur4f4zkNiyyMrelX9GMeAyh+ZkTXhZl0UsoIlZmT6DthjatBqms7hC dYotB+Qm7JtUWvsVpMcty3A5HbHYzKPjQsxpeFeThidn0hRpvnDbArQHJlVRTAA62+8Z5RqL/rT F0Q4DuCOqu0pCDPfAcAXcnrQ5tjKwLo2qCitTQXbXp/0nxkgJaXd7Pc7U3X0zbxS4ELDORlzDtx g== X-Received: by 2002:a05:620a:3945:b0:92e:c116:bf11 with SMTP id af79cd13be357-93103aa2d39mr458620285a.90.1784840119399; Thu, 23 Jul 2026 13:55:19 -0700 (PDT) Received: from Ai-Server.tail94eb8c.ts.net (131-193-45-111.cs.uic.edu. [131.193.45.111]) by smtp.gmail.com with ESMTPSA id af79cd13be357-930f687a6aasm501134585a.9.2026.07.23.13.55.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 13:55:19 -0700 (PDT) From: Luyao Bai To: Mauro Carvalho Chehab , Henri A Cc: linux-media@vger.kernel.org, Patrick Boettcher , linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, syzbot+0cd0fb4cf3f4722d6663@syzkaller.appspotmail.com Subject: [PATCH] media: dib0700: reject zero-length I2C reads in both transfer paths Date: Thu, 23 Jul 2026 20:55:10 +0000 Message-ID: <20260723205510.662761-1-bailuyao1997@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260621192222.337738-1-contact@henrialfonso.com> References: <20260621192222.337738-1-contact@henrialfonso.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A zero-length I2C read (I2C_M_RD with len =3D=3D 0), issued from user space through /dev/i2c-N with the I2C_RDWR ioctl, is translated by the dib0700 bridge into a control-IN usb_control_msg() whose wLength is the I2C message length, i.e. 0. usb_submit_urb() treats a zero-length control transfer as OUT, so the pipe direction (IN) and the setup-packet direction (bRequestType =3D 0xc0, IN) disagree and trip the WARN() in usb_submit_urb(): usb 4-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: drivers/usb/core/urb.c:411 at usb_submit_urb+0x1573/0x1910 usb_submit_urb usb_start_wait_urb usb_control_msg dib0700_ctrl_rd drivers/media/usb/dvb-usb/dib0700_core.c:95 dib0700_i2c_xfer_legacy drivers/media/usb/dvb-usb/dib0700_core.c:315 dib0700_i2c_xfer drivers/media/usb/dvb-usb/dib0700_core.c:361 __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr drivers/i2c/i2c-dev.c:306 The .master_xfer entry point dib0700_i2c_xfer() dispatches to one of two transfer routines depending on the device firmware: dib0700_i2c_xfer_new() (firmware >=3D 1.20) and dib0700_i2c_xfer_legacy(). Both build a control-IN usb_control_msg() from the I2C read length, so both can submit the bogus zero-length transfer; the syzbot reproducer happens to take the legacy path. Guarding a single path therefore leaves the other exposed. Reject zero-length reads in the shared dispatcher, before the firmware split, so neither path can submit such a transfer. -EOPNOTSUPP is returned because the adapter cannot express a zero-length read, matching the error the i2c core returns for the I2C_AQ_NO_ZERO_LEN_READ quirk. The i2c core can enforce this centrally via the I2C_AQ_NO_ZERO_LEN_READ adapter quirk, but the dib0700 bridge reuses the i2c adapter registered by the dvb-usb core (dvb-usb-i2c.c), and the dvb-usb framework provides no hook for an individual driver to set adapter quirks; using the quirk would require a dvb-usb framework change. Rejecting the read in the driver's own .master_xfer keeps the fix local and minimal. Reported-by: syzbot+0cd0fb4cf3f4722d6663@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D0cd0fb4cf3f4722d6663 Fixes: b7f54910ce01 ("V4L/DVB (4647): Added module for DiB0700 based device= s") Signed-off-by: Luyao Bai --- This is an alternative to Henri A's patch for the same syzbot report [1], which places the guard inside dib0700_i2c_xfer_legacy(). That fix is correct for the reproducer, but dib0700_i2c_xfer_new() builds its control-IN transfer from the read length in the same way, so a device running firmware >=3D 1.20 can still submit the bogus zero-length transfer. Checking in the shared .master_xfer entry point covers both paths with a single guard. Henri: happy for you to fold the second path into a v2 of yours instead if you prefer, whichever lands the complete fix. Tested with the syzbot reproducer under QEMU: the "BOGUS control dir" WARNING at drivers/usb/core/urb.c fires on a clean mainline build and no longer fires with this patch applied. [1] https://lore.kernel.org/linux-media/20260621192222.337738-1-contact@hen= rialfonso.com/ drivers/media/usb/dvb-usb/dib0700_core.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c b/drivers/media/usb/d= vb-usb/dib0700_core.c index 1caabb51ea47..084c56e734e6 100644 --- a/drivers/media/usb/dvb-usb/dib0700_core.c +++ b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -352,6 +352,20 @@ static int dib0700_i2c_xfer(struct i2c_adapter *adap, = struct i2c_msg *msg, { struct dvb_usb_device *d =3D i2c_get_adapdata(adap); struct dib0700_state *st =3D d->priv; + int i; + + /* + * Both transfer paths translate an I2C read into a control-IN + * usb_control_msg() whose wLength is the message length. A + * zero-length read produces a control URB whose pipe direction + * (IN) disagrees with a zero-length setup packet (which + * usb_submit_urb() treats as OUT), tripping its "BOGUS control + * dir" WARN(). Reject such reads up front so neither path can + * submit one. + */ + for (i =3D 0; i < num; i++) + if ((msg[i].flags & I2C_M_RD) && msg[i].len =3D=3D 0) + return -EOPNOTSUPP; if (st->fw_use_new_i2c_api =3D=3D 1) { /* User running at least fw 1.20 */ -- 2.43.0