From: Wolfram Sang wsa+renesas@sang-engineering.com
[ Upstream commit b5ae5a79825ba8037b0be3ef677a24de8c063abf ]
This driver passes the length of an i2c_msg directly to usb_control_msg(). If the message is now a read and of length 0, it violates the USB protocol and a warning will be printed. Enable the I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length read messages altogether.
Signed-off-by: Wolfram Sang wsa+renesas@sang-engineering.com Signed-off-by: Hans Verkuil hverkuil@xs4all.nl Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Now I have enough information to provide a comprehensive analysis:
## Backport Status: YES
This commit should be backported to stable kernel trees. Here's my extensive analysis:
### 1. Bug Fix Nature The commit fixes a **protocol violation bug** where the hdpvr driver passes zero-length read messages directly to `usb_control_msg()`. Looking at line 122-123 in `hdpvr_transfer()`: ```c retval = hdpvr_i2c_read(dev, 1, addr, NULL, 0, msgs[0].buf, msgs[0].len); ``` When `msgs[0].len` is 0, this results in a zero-length USB control message being sent at line 71 in `hdpvr_i2c_read()`: ```c ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0), REQTYPE_I2C_READ, CTRL_READ_REQUEST, (bus << 8) | addr, 0, dev->i2c_buf, len, 1000); ```
### 2. USB Protocol Violation Zero-length read control messages violate the USB protocol specification. This isn't just a theoretical issue - the kernel now warns about these violations, and they can cause actual communication problems with USB devices.
### 3. Similar Stable Backports The pattern of this fix is identical to other drivers that have already been backported to stable: - `i2c: robotfuzz-osif: disable zero-length read messages` (commit 8bc5879c038f) - `i2c: tiny-usb: disable zero-length read messages` (commit 4e093e67e5a9)
Both of these commits explicitly included `Cc: stable@vger.kernel.org` tags and have been backported to stable trees.
### 4. Small and Contained Fix The fix is minimal and safe: - Adds a simple quirks structure with `I2C_AQ_NO_ZERO_LEN_READ` flag - Only adds 6 lines of code (quirks structure definition and reference) - Doesn't change any logic flow or introduce new features - The I2C subsystem respects this quirk and prevents zero-length reads from reaching the driver
### 5. Real User Impact This bug can cause: - Warning messages in kernel logs that alarm users - Potential USB communication errors - Incorrect behavior when I2C devices attempt zero-length reads
### 6. No Architectural Changes The commit: - Doesn't introduce new features - Doesn't change existing APIs - Doesn't modify core kernel infrastructure - Only adds a defensive measure using existing I2C quirk infrastructure
### 7. Clear Backport Criteria Match The commit meets stable kernel rules: - **Fixes a real bug**: USB protocol violation - **Already causing problems**: Warnings are being printed - **Obviously correct**: Uses standard I2C quirk mechanism - **Small change**: Only 6 lines added - **Tested solution**: Same fix pattern already in stable for other drivers
The commit should be backported to all stable kernels that include the hdpvr driver, particularly those where USB core started warning about zero-length control messages.
drivers/media/usb/hdpvr/hdpvr-i2c.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/media/usb/hdpvr/hdpvr-i2c.c b/drivers/media/usb/hdpvr/hdpvr-i2c.c index 070559b01b01..54956a8ff15e 100644 --- a/drivers/media/usb/hdpvr/hdpvr-i2c.c +++ b/drivers/media/usb/hdpvr/hdpvr-i2c.c @@ -165,10 +165,16 @@ static const struct i2c_algorithm hdpvr_algo = { .functionality = hdpvr_functionality, };
+/* prevent invalid 0-length usb_control_msg */ +static const struct i2c_adapter_quirks hdpvr_quirks = { + .flags = I2C_AQ_NO_ZERO_LEN_READ, +}; + static const struct i2c_adapter hdpvr_i2c_adapter_template = { .name = "Hauppauge HD PVR I2C", .owner = THIS_MODULE, .algo = &hdpvr_algo, + .quirks = &hdpvr_quirks, };
static int hdpvr_activate_ir(struct hdpvr_device *dev)