[{"id":3675382,"web_url":"http://patchwork.ozlabs.org/comment/3675382/","msgid":"<2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>","list_archive_url":null,"date":"2026-04-09T15:50:27","subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length\n in raw_event","submitter":{"id":67576,"url":"http://patchwork.ozlabs.org/api/people/67576/","name":"Jiri Kosina","email":"jikos@kernel.org"},"content":"On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:\n\n> ft260_raw_event() casts the raw data buffer to a\n> ft260_i2c_input_report struct and accesses its fields without\n> validating the size parameter. Since __hid_input_report() invokes\n> the driver's raw_event callback before hid_report_raw_event()\n> performs its own report-size validation, a device sending a\n> truncated HID report can cause out-of-bounds heap reads.\n> \n> Additionally, even with a full-sized report, a corrupted\n> xfer->length field can cause memcpy to read beyond the report\n> buffer. The existing check only validates against the destination\n> buffer size, not the source data available in the report.\n> \n> Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,\n> and verify that xfer->length does not exceed the actual data\n> available in the report. Log warnings to aid debugging.\n> \n> Cc: stable@vger.kernel.org\n> Signed-off-by: Sebastian Josue Alba Vives \n> ---\n> drivers/hid/hid-ft260.c | 11 +++++++++++\n> 1 file changed, 11 insertions(+)\n> \n> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c\n> index 333341e80..68008a423 100644\n> --- a/drivers/hid/hid-ft260.c\n> +++ b/drivers/hid/hid-ft260.c\n> @@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,\n> \tstruct ft260_device *dev = hid_get_drvdata(hdev);\n> \tstruct ft260_i2c_input_report *xfer = (void *)data;\n> \n> +\tif (size < FT260_REPORT_MAX_LENGTH) {\n> +\t\thid_warn(hdev, \"short report: %d\\n\", size);\n> +\t\treturn 0;\n\nMichael, can you please confirm whether the device can never legitimately \nsend shorter than FT260_REPORT_MAX_LENGTH reports?\n\nThanks,","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=DH87QZ7N;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17004-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"DH87QZ7N\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs4N35zd3z1yD3\n\tfor ; Fri, 10 Apr 2026 01:58:11 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id E891A31181DA\n\tfor ; Thu, 9 Apr 2026 15:51:28 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id C20D43242A4;\n\tThu, 9 Apr 2026 15:50:31 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C7893DBD7C;\n\tThu, 9 Apr 2026 15:50:30 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id DA5A4C4CEF7;\n\tThu, 9 Apr 2026 15:50:29 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775749830; cv=none;\n b=ZqGRlPa7E2X1e7cQQRLsHieApA1wY1mihkP1Xryj6R2TJ7eJFXXjLYDkcoQS8J7mx5DnpdtTovoCASk+JHHeLRY34j71BU6RvNn1R0+L7u+MCzCU61qVr4HUtaNopTnb5Kwih8tQrbNly8MPDI4E06mR0G2WVIQLRH32HaZgcqI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775749830; c=relaxed/simple;\n\tbh=rX48IB2IMYPI8ssHHUyPf1RQIH+r7jVnPzWySnEGRM4=;\n\th=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=bnwTcPqB8GZtxZ6S5ogkFFtgxwCGKLpBZg8WuAj6o66gq+BmMXQPirdStcyRkL4OHB7/4TYoeUiypY9s1ml9RIkE1Jn8iDinToEfysBmD6EJdVRRGMTAcsM5TRvGtTyAZfEMr1fPw5Oitwphvi4QaPg57Ksn/6NKatPw+0lwrKI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=DH87QZ7N; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775749830;\n\tbh=rX48IB2IMYPI8ssHHUyPf1RQIH+r7jVnPzWySnEGRM4=;\n\th=Date:From:To:cc:Subject:In-Reply-To:References:From;\n\tb=DH87QZ7N6UcwtKUBAr0wpcBi/Xu6vuM5dbUfRNcjafYFQqaDtqjkrtzOmPBK9Ob44\n\t Lexi64L8VLvmpCrkwglBxgdxKh8/iu8Jc9oWrDrlVruud9M8R3J7uPNIw5D9q0gEmZ\n\t IVW1BNeMDwWcW1eOvr+1d3jwpAgMYXHa+ZXiQqE073o88VmlpFA8B01v31gbgLWViY\n\t YlWsIoieOfv2bMem+D8QdUwgj2lkFuWfniXCmPMISa362NEFHd+lIBOIp6ZrNOEYhQ\n\t QeTH+xu49d9IlyfubVOrBepMdSHwnN9G56W3USD89L7nJk9oBSf75UnU6Sleio9MyZ\n\t 9hhCpc0BXUYvA==","Date":"Thu, 9 Apr 2026 17:50:27 +0200 (CEST)","From":"Jiri Kosina ","To":"Sebastian Josue Alba Vives ","cc":"michael.zaidman@gmail.com, Benjamin Tissoires ,\n linux-i2c@vger.kernel.org, linux-input@vger.kernel.org,\n linux-kernel@vger.kernel.org, stable@vger.kernel.org","Subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length\n in raw_event","In-Reply-To":"<20260324201858.46591-1-sebasjosue84@gmail.com>","Message-ID":"<2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>","References":"<20260324173527.11321-1-sebasjosue84@gmail.com>\n <20260324201858.46591-1-sebasjosue84@gmail.com>","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}},{"id":3675451,"web_url":"http://patchwork.ozlabs.org/comment/3675451/","msgid":"","list_archive_url":null,"date":"2026-04-09T18:24:59","subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length in\n raw_event","submitter":{"id":5876,"url":"http://patchwork.ozlabs.org/api/people/5876/","name":"Michael Zaidman","email":"michael.zaidman@gmail.com"},"content":"On Thu, Apr 9, 2026 at 6:50 PM Jiri Kosina wrote:\n>\n> On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:\n>\n> > ft260_raw_event() casts the raw data buffer to a\n> > ft260_i2c_input_report struct and accesses its fields without\n> > validating the size parameter. Since __hid_input_report() invokes\n> > the driver's raw_event callback before hid_report_raw_event()\n> > performs its own report-size validation, a device sending a\n> > truncated HID report can cause out-of-bounds heap reads.\n> >\n> > Additionally, even with a full-sized report, a corrupted\n> > xfer->length field can cause memcpy to read beyond the report\n> > buffer. The existing check only validates against the destination\n> > buffer size, not the source data available in the report.\n> >\n> > Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,\n> > and verify that xfer->length does not exceed the actual data\n> > available in the report. Log warnings to aid debugging.\n> >\n> > Cc: stable@vger.kernel.org\n> > Signed-off-by: Sebastian Josue Alba Vives \n> > ---\n> > drivers/hid/hid-ft260.c | 11 +++++++++++\n> > 1 file changed, 11 insertions(+)\n> >\n> > diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c\n> > index 333341e80..68008a423 100644\n> > --- a/drivers/hid/hid-ft260.c\n> > +++ b/drivers/hid/hid-ft260.c\n> > @@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,\n> > struct ft260_device *dev = hid_get_drvdata(hdev);\n> > struct ft260_i2c_input_report *xfer = (void *)data;\n> >\n> > + if (size < FT260_REPORT_MAX_LENGTH) {\n> > + hid_warn(hdev, \"short report: %d\\n\", size);\n> > + return 0;\n>\n> Michael, can you please confirm whether the device can never legitimately\n> send shorter than FT260_REPORT_MAX_LENGTH reports?\n>\n> Thanks,\n>\n> --\n> Jiri Kosina\n> SUSE Labs\n>\n\nHi Jiri,\n\nThe FT260 uses different report IDs (0xD0 through 0xDE) for different payload\nlengths, with each report ID defining a different report size in the HID\ndescriptor. So yes, the device can legitimately send reports shorter than\nFT260_REPORT_MAX_LENGTH, and a blanket size < 64 check would break valid\nshort transfers.\n\nLooking at __hid_input_report(), the HID core could validate size against\nhid_compute_report_size(report) before the raw_event call - essentially\nmoving the check that hid_report_raw_event() already does to happen earlier.\nThat would handle truncated reports generically for all HID drivers. However,\nsuch a change would affect all HID drivers and require broad testing, so that\nis your call.\n\nWhat the HID core cannot validate is driver-specific payload semantics. In\nft260, the I2C input report has a length field at byte 1 that indicates the\npayload size, and the driver uses it as the memcpy length without checking\nit against the actual report size or against the expected data capacity for\nthe specific report ID.\n\nI will submit a per-driver fix with two checks, both essential:\nFirst, a minimum size check before accessing any header fields. Currently,\nthe HID core does not validate report size before calling raw_event, so a\n1-byte report would cause an OOB read just from accessing the length field\nat byte 1. This check is necessary regardless of the second check.\n\nSecond, a validation of xfer->length against the expected data capacity for\nthe given report ID. Each I2C input report ID defines a specific data capacity\n(report 0xD0 holds up to 4 bytes, 0xDE up to 60 bytes). A corrupted length\nfield exceeding this capacity would cause an OOB read from the source buffer\nduring memcpy, even if the report itself is full-sized. Only the driver knows\nthese per-report-ID limits.\n\nI have the hardware to test this change. I will credit Sebastian with\nReported-by for identifying the issue.\n\nThanks,\nMichael","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=LzLxomTq;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17010-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"LzLxomTq\"","smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=209.85.208.54","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs7dt6pssz1yCv\n\tfor ; Fri, 10 Apr 2026 04:25:22 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 855C630107C1\n\tfor ; Thu, 9 Apr 2026 18:25:15 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 8479F3E0C5D;\n\tThu, 9 Apr 2026 18:25:14 +0000 (UTC)","from mail-ed1-f54.google.com (mail-ed1-f54.google.com\n [209.85.208.54])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id C23F3250C06\n\tfor ; Thu, 9 Apr 2026 18:25:12 +0000 (UTC)","by mail-ed1-f54.google.com with SMTP id\n 4fb4d7f45d1cf-66c05fb27e4so2199230a12.2\n for ; Thu, 09 Apr 2026 11:25:12 -0700 (PDT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775759114; cv=pass;\n b=bEjXU8KNqPOphvvW3zgGATE/8SkALvh7YH/EHBRuEPKQ/XRoal9XPhKLV7gF7nBTIoXcCj+jfOk/p1Xwcz4XQjTWBFXWIhQTvKYn2z6A+alQCx3yIJR0X4PdiRs0ePYw5mNdjaWxqOJUt9a4CpoqxnU2lQD3AudIZ+6F1kMRjo4=","i=1; a=rsa-sha256; t=1775759111; cv=none;\n d=google.com; s=arc-20240605;\n b=JxdcKHwwuw2eI34jKybmLS1tgdI5XV2Outn8ivWckHSzbMi7fdpGH5qbCymN4U23BU\n bhcLQZhI5bkzwfuLn8OylpvKSPpnmT9YxUGa/DzY7r+uaK3FvFZEuVN3re5lwW390gGX\n Z3gLweqbrgz1j0mpm069d4ihyLgWHS6gdcHheJU3ijs87dbQps6EfqGEI33mqg85fr8y\n oG3QeJog0TXqI9B9Lcc0uDWeJ31JHB7s7mB6NOLod7la//pVNxQu7ThfO5nksV59P/lo\n H/b7numuWiUE/AtlqTJ+GOoQfTOqh2cR0IVu6UwwliH/9dq+dy56rxgI/Q2RN1IxgggE\n elng=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775759114; c=relaxed/simple;\n\tbh=uRIpHIXY1Jgv/tUqLrduouxc+mc9S9SHsVuyZmzj/QA=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=FbNMKsX14X3BWeYDyBvnYGJ/+v3QrgD9gOhXU04cngbUcgrM08urWeSAZ0XvKH4xs5HcsU7ZWT/Qc3AmtveWinjcKTrmhFP7gCht6ZYsXaxi7OA9Vvy90hfnzL8GyB0YtLDkdg+JO00QxtCn/NWgt+dfFYqLRq8Q2oScC5/RuGA=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=bxi0Dq/1cOaYc6y9Kzzau5RxO3/CNiO8acCYH60FkGo=;\n fh=7GqoOszeECRSqXzepREz3bG+CkpTi/4PxNEdoNn9WU0=;\n b=DDTZatCMWo2ySsAuT5Ghk6PAy2EObc0l779q1+cP3Sj8mwQK2orYCr80RF+aOptP+F\n MKQj0G/Ot9cMVhT81aoxA2GjlWhkF8vINkSeBDRkkOmQEOpdRcQfQq7S9ysV0U/0wQ6R\n LnndhK+IgaBhx0Ts4RQj4bPfRvmOlWD40TSdlZpUVuApRdDr1aApm0hX1q2kjpJCV9Xc\n K1YM+JqKMhZn4HE7KDBtquh+haWxkGQatBQV7gjgVXDQ+WJL9VomVwn8scru+abe/mrP\n CU4OMNfed/vmey6JAgWPVug2ccSiXmzxun108h5IFdJij+k2dclZs91HvB8vGY7sWGSe\n 2Qsw==;\n darn=vger.kernel.org"],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=LzLxomTq; arc=pass smtp.client-ip=209.85.208.54","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775759111; x=1776363911;\n darn=vger.kernel.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=bxi0Dq/1cOaYc6y9Kzzau5RxO3/CNiO8acCYH60FkGo=;\n b=LzLxomTqu3hI303cqh2kQu4o2QnX1b75nZh+6sCJ14WZQWRlau3rNtsEsjvR8ReWl4\n P5xC3YMB1IhHq1kdyBqUhi2nCBOXRxuHWNcvMIXZyADz281HJsOEBMIAhEbVLPuXaj7J\n ndczERAsnqnzXca/SLqO1WOQjw4VQ/7YKEkd22YnM6sYbeRUXQaUnNyqN0w7Lcn2ONgO\n 9Opx+SCMutnon9umjt7iexP3KFc5RVv8ATMueCPD8aQA7XrarOswzjrs1YW9Uqa7YAFb\n Pf5B0nrRwGHlRmvI0+M/4f8iueNgVYY+xRf+APnq7COAdYqymyaDyL+0WTbNtiDuuvu8\n JF1A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775759111; x=1776363911;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=bxi0Dq/1cOaYc6y9Kzzau5RxO3/CNiO8acCYH60FkGo=;\n b=XomQ0vHj5aFq1AXjRfCE4ZHCTjqO2LEsLYXvV5U3ilGl4IFwKUtvutC0oenWZms6nM\n vr/VLp7z3c8D+GPucrSVhGYQ8I75Ze91E4PNjr9QXVmzThHa4T9qdsNCPlA9Nq2d87D7\n mByG+Fos6Hq6FS3lVX4TRBxyetwHwXDcNOsK2ABL0dP1sH+1Du3Kmm87T0frB+mvZezE\n GNS9aBwB7HWqAuyUlrZCq+YT87AMEarDDoB10y6N21mqNMctu9v5NndGDpMO3i7DXdoM\n iuZl6+t3QBxOJoy+eiagz4PyKh5ISrC2HZnYkcpX9fQ23tcbY7Q9k4qW68jNtNDPaOF8\n xiZQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCUKMOsyxZ0EACAnTHIRGhQp2WxYyfxJygPNqZqyd9dzooO6ft+skWvSOHdiRUehcMdwiIFLz9yLpS0=@vger.kernel.org","X-Gm-Message-State":"AOJu0YzPZsOBkBqmZ9LemUF9/L6oVtFuxVGXNOMTlt1ChbfyC7oGnyD9\n\t6Cf+fOeODc8Zql10hZsKZ/+9CXEUqxh3GC1KATRNgapF0cMWE/Q825+SmeLDepyqZukJxJY07Y/\n\tvFzefJpigMPtqHJbhBolJIkkxFOg6sMsAWN8m","X-Gm-Gg":"AeBDiev+6seL571jywqRbnQs9wuDk0Mh0EM1pR+LV8UhYMZAm+cZFQbQlNtuBr3HWZn\n\twcsU4xNQI05X+E6Zf99ZgzCkPif52GAjaBbGLUs1ow19ZPWW2oAcrUYXrVBrdCU81MAPhvVzydP\n\tdPTPUqSSoux6S/2OaXayHaeoBZAFhQEMxOQ/WeKUp4hjt1f5neeSOjsOX77JFTEEpfxCL2ZMexs\n\tF41ekNBtJFuPiNZGgNNMNxL7u0IH/xf+4xjwUxWRUx6Ht9S4UnslQwPDd5BtyRP/Ew36vp0T/9Q\n\t6+oEaYY=","X-Received":"by 2002:a05:6402:358e:b0:66e:f4c0:c348 with SMTP id\n 4fb4d7f45d1cf-66ef4c0c5a1mr8652002a12.7.1775759110757; Thu, 09 Apr 2026\n 11:25:10 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260324173527.11321-1-sebasjosue84@gmail.com>\n <20260324201858.46591-1-sebasjosue84@gmail.com>\n <2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>","In-Reply-To":"<2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>","From":"Michael Zaidman ","Date":"Thu, 9 Apr 2026 21:24:59 +0300","X-Gm-Features":"AQROBzD5ryy57P3iGUvqLsmBCdxSK-kLXMP5Y7ZvC8lV482_vL8uUBuQIdBTpOA","Message-ID":"\n ","Subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length in\n raw_event","To":"Jiri Kosina ","Cc":"Sebastian Josue Alba Vives ,\n Benjamin Tissoires ,\n\tlinux-i2c@vger.kernel.org, linux-input@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, stable@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}},{"id":3675453,"web_url":"http://patchwork.ozlabs.org/comment/3675453/","msgid":"<7qr72215-4q40-qon4-808o-7o639qq90q3s@xreary.bet>","list_archive_url":null,"date":"2026-04-09T18:28:58","subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length\n in raw_event","submitter":{"id":67576,"url":"http://patchwork.ozlabs.org/api/people/67576/","name":"Jiri Kosina","email":"jikos@kernel.org"},"content":"On Thu, 9 Apr 2026, Michael Zaidman wrote:\n\n> The FT260 uses different report IDs (0xD0 through 0xDE) for different payload\n> lengths, with each report ID defining a different report size in the HID\n> descriptor. So yes, the device can legitimately send reports shorter than\n> FT260_REPORT_MAX_LENGTH, and a blanket size < 64 check would break valid\n> short transfers.\n\nPerfect, thanks a lot for the detailed writeup! I was rather suspicious \nabout the bold statement in the changelog.\n\nSimilarly to other Sebastián's fixes to various other drivers. This will \nneed more thorough check.\n\nThanks,","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=PXR37xns;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17011-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"PXR37xns\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs7kh4XTPz1yCv\n\tfor ; Fri, 10 Apr 2026 04:29:32 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id F1BDB3021715\n\tfor ; Thu, 9 Apr 2026 18:29:02 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E34623E1D0C;\n\tThu, 9 Apr 2026 18:29:01 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 88B3E2248A3;\n\tThu, 9 Apr 2026 18:29:01 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id DA336C4CEF7;\n\tThu, 9 Apr 2026 18:29:00 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775759341; cv=none;\n b=omTV5wEVorhSrLMiJFi31SV3+kEpKLZaX+KvJioY56X9GdW4pOTbO8qqrved34gyT/J5vP6wJhJgFOx0ksUNxxPsi7Go4UyKL7SMRhbQOpTqGJsNO8kXtXxpjVMa8m2uUhtCr9AIGz5GARe1eEPXTobR20qIjU3f9AOiT44s3yU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775759341; c=relaxed/simple;\n\tbh=0AqsaCjs/tsyiHjFNYYlGjRToMZssCVn6w9EUxIWAvU=;\n\th=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=U6+tNSwVTmOF8xHx6HsXICYj2bM8Itpw5xSqXoeQIBtAOXfcJe4RWLNk5uYvaYvDMhNaDHULc0RMGrwVKISXOyh0UO2/ByEEBUFCCxcaQ7zzsYtHpROwYvaBT9ou5ROrvC2OmFnfmbG5Jf+Q4TshYWyiYW+eeZjuNuZg7fyUSTk=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=PXR37xns; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775759341;\n\tbh=0AqsaCjs/tsyiHjFNYYlGjRToMZssCVn6w9EUxIWAvU=;\n\th=Date:From:To:cc:Subject:In-Reply-To:References:From;\n\tb=PXR37xnswF1OPt9Ff/ix7mzS4fsQDqAJaJ8OOKycyv4OLM+L5gnLxAnQH7UhwSzgd\n\t /ruxXwtsaCgGannct1CKnX8gFaZfszUTHSBrol1iWWjQlWr9O2QlmwW2eaV/zyiJvG\n\t z/zxRBS+dx/oPxDYT/dKsSHC9d3ezY/tdsNxRiGDSVw5GO40DpGgDR2EaxS1gmp8uZ\n\t jQP0bNf24yFcfOiMFxgCFQ6qHuETyS2/QLoClwwdX9e+6VD2k68x3VZjdri87GFN2f\n\t 32nKHKv+uhYGneDIi3uPKk+B2apcF9DZC6/w+yndwwm3dA9WxgqlC1p37E66/dn+eF\n\t p3NcwTVtmLutQ==","Date":"Thu, 9 Apr 2026 20:28:58 +0200 (CEST)","From":"Jiri Kosina ","To":"Michael Zaidman ","cc":"Sebastian Josue Alba Vives ,\n Benjamin Tissoires , linux-i2c@vger.kernel.org,\n linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,\n stable@vger.kernel.org","Subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length\n in raw_event","In-Reply-To":"\n ","Message-ID":"<7qr72215-4q40-qon4-808o-7o639qq90q3s@xreary.bet>","References":"<20260324173527.11321-1-sebasjosue84@gmail.com>\n <20260324201858.46591-1-sebasjosue84@gmail.com>\n <2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>\n ","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=ISO-8859-15","Content-Transfer-Encoding":"QUOTED-PRINTABLE"}},{"id":3675474,"web_url":"http://patchwork.ozlabs.org/comment/3675474/","msgid":"","list_archive_url":null,"date":"2026-04-09T19:17:33","subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length in\n raw_event","submitter":{"id":5876,"url":"http://patchwork.ozlabs.org/api/people/5876/","name":"Michael Zaidman","email":"michael.zaidman@gmail.com"},"content":"On Thu, Apr 9, 2026 at 9:29 PM Jiri Kosina wrote:\n>\n> On Thu, 9 Apr 2026, Michael Zaidman wrote:\n>\n> > The FT260 uses different report IDs (0xD0 through 0xDE) for different payload\n> > lengths, with each report ID defining a different report size in the HID\n> > descriptor. So yes, the device can legitimately send reports shorter than\n> > FT260_REPORT_MAX_LENGTH, and a blanket size < 64 check would break valid\n> > short transfers.\n>\n> Perfect, thanks a lot for the detailed writeup! I was rather suspicious\n> about the bold statement in the changelog.\n>\n> Similarly to other Sebastián's fixes to various other drivers. This will\n> need more thorough check.\n>\n> Thanks,\n>\n> --\n> Jiri Kosina\n> SUSE Labs\n>\n\nHi Jiri,\n\nIndeed. The original patch would have been easily caught by testing on actual\nFT260 hardware - short transfers using report IDs 0xD0 through 0xD3 carry well\nunder 64 bytes and are part of normal I2C operation. A blanket size < 64 check\nwould break them immediately.\n\nI'll submit a proper fix with per-report-ID capacity validation based on the\nHID descriptor.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-i2c@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=mRxOTARa;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-i2c+bounces-17014-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"mRxOTARa\"","smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=209.85.218.44","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fs8pZ58YSz1xy1\n\tfor ; Fri, 10 Apr 2026 05:17:58 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 6288F3012A8D\n\tfor ; Thu, 9 Apr 2026 19:17:54 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id CADC93090CC;\n\tThu, 9 Apr 2026 19:17:49 +0000 (UTC)","from mail-ej1-f44.google.com (mail-ej1-f44.google.com\n [209.85.218.44])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 41D2F29AAF3\n\tfor ; Thu, 9 Apr 2026 19:17:48 +0000 (UTC)","by mail-ej1-f44.google.com with SMTP id\n a640c23a62f3a-b9c3a9fe80fso164655866b.3\n for ; Thu, 09 Apr 2026 12:17:48 -0700 (PDT)"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775762269; cv=pass;\n b=Kc6LsCUP7FS0xwc8KghREfe1Y+liW3N24qQhQpUwh86vE8NIHPOhospQQtWwERPIcNM2jZ6YtZ75BIZlGlemRkTvuwsfvmuuuk8VWVVu5mDSknXntTfSTKzovF5jgov1cJeg9RNvgPVWRYbNNcAwAd8wWzzgBkPN/qYP+TVxSAs=","i=1; a=rsa-sha256; t=1775762267; cv=none;\n d=google.com; s=arc-20240605;\n b=JFTsYBOFG6SAdL1TzAjGOTj+PjUkiF0y0V+fTLbzcQ9/GPQTgJVDm9NzCmmaD6QEAX\n M5yrpZ+PREGfFDKend4fCXu4eyeSUuTusUoh7vpCfcGIC4tHlxoygIvyMR4QVctpEZWR\n w2TTTuIWEPqN4G+N7FPmwHY0X/hMmWjGsFTXq4YsHPsaKI7+tike5vvfEQcg7N8Ntgoo\n LN7/JedbsR5xQz/X+xewTDWckQaBfKmgpHv0LVyWK6fsWef3kbH8etc2+H0xDLuc4nl3\n Xi7E3qheQK2EJVF9ofpUBHvWx/KCbFpmfkOA44mGnj9hOoabP7ZBq1ZVDpphzR+wi/4t\n ZrKA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775762269; c=relaxed/simple;\n\tbh=AEYSbrTBOCDSCGJnM9iFBLwN4LBHhV86/lUpZVRVxGY=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=RffLi8svbj42sgqetJjv1qL0m3q5qldFF3zPYQuczBi8+RZ8JJRZxk1kyODY1jzCFwQIeo7NkYE0tRG500PD4VwbGTzPnIV6f4ecUR68mVegrl+gV/ddzvfyTfpBhpXuTOPQDZ4hDFvriM7iKv3uB5fnyhdG6UIXLFJ36AyhyP8=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:dkim-signature;\n bh=AEYSbrTBOCDSCGJnM9iFBLwN4LBHhV86/lUpZVRVxGY=;\n fh=uZoRMUKY+ZNVfNfeNup0IH8KUHZG1QqmyIl4bKmbn1s=;\n b=WC5VycCYTBEFUkbs0LvbylOBp8SBIKR2xDogrQqcSOSGmgFAJxDys8VfFRzS41AHZ3\n roTSiyNJWggPCDExCJ2G6JcBHVr9kZQOV1C9XDylBTt+6zcRx1I/mH4Rvjevfj/QUpJa\n Ry21cMbRDvgSCJHwiNYxMuJ5f5ipENSGB56JOcK16AIB1/jjwLKhz5q4rf1gudMYjAMz\n w6E6BMnN4/Is9iRsFkx8adPZmvmv+EAzjBlc1QKxQqgPTQukaNDatZHKnQNFduIawONi\n koK0UZJW8wUSTsUfUwUYIcYmX8Pwx/g6l4P0VDKIreQtoZl3bMu/WroJ+LibEMOsEyLr\n oHaQ==;\n darn=vger.kernel.org"],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=mRxOTARa; arc=pass smtp.client-ip=209.85.218.44","i=1; mx.google.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1775762267; x=1776367067;\n darn=vger.kernel.org;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=AEYSbrTBOCDSCGJnM9iFBLwN4LBHhV86/lUpZVRVxGY=;\n b=mRxOTARa7KEK/i89Nt5wG/esGfHtqRc+wZKzGDt8l+Mf4F47U59XvNjN4jbdK/lFHs\n lYSqDbgpTyAUrkAZHaUxGbQdrh/T0yN9u4CKjdu9DO1Dw5kteYdPnsZyZuLjsqzLj2Kg\n eyYANlMC3dKz0kCiAmf1O03gdy+XLwwslVsH7yXxfYAyizb5H1rFTNW3AXP2D+7lGJor\n 7bZ92RNiycke3zY/JjVCA2323jSIetsrvz/M7e8cquGcTetTTtvJQzoNLyXnOMAr7cTH\n 2eZvN4UMtNcAbLACq2RgzcvU9uEqq1vjUsfx3/69fDbKzretMvMRgnzK5Em1dmA1FoHP\n rfYA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775762267; x=1776367067;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=AEYSbrTBOCDSCGJnM9iFBLwN4LBHhV86/lUpZVRVxGY=;\n b=epC8ubVSF0FjzN+WkAvKkYIjHSusgB4CaxG/bsVeHww3VxrETYk3UD62rhrC1wynke\n ftVIYZQEgR6BaQYYIBmBJcvZrE8E5hHfmKNdHHv4TLnLf3eXrg786O7dEh9sfCojMewq\n op+p7rm88gwqxSONZFY1qM+rJgYd/c65ot6ToSVGOKmxyoVPcxVJoT5rV9mhjZob9DZT\n nFCqapnP+OAuzsu5l24sEOVjhaQl0Pwk6K976POIhO5rRoVb4c6rLaeb5To+1kUiMGkg\n KWb61HGX2YVWdx1AXzs5LVL8/4XRNLWKH5ElLNo2g11uicoB7wqGnaLgrsCNT7PKBvTi\n 41rQ==","X-Forwarded-Encrypted":"i=1;\n AJvYcCV4ZmpQ2Eoang/nXJuGOpzVD6kFfEmRSL3OtyGCekFSMi09ePXOJNftOu1zPQY7yRrn9HV9w2I3zQY=@vger.kernel.org","X-Gm-Message-State":"AOJu0YyzmHF5mj5X8wxGT0JCFouGghTNBhJ7iGxSYz2gMvERJ+zLFkIT\n\tFMmRzVVM2OOFJOyCUSljueaibE4MUM1i6lkwVQBnSq/njiIg3mI/cfceZLGgbem2cTwUvMzCXvB\n\tnwO2URK3oz6JvllODvNMxT0t0T+fxUV0=","X-Gm-Gg":"AeBDieuYvZWqasug1YjgVsfbY5ZvevryW+OK0dedd+3HWhN1KZbMBvkyRoMEkODEBgw\n\tfj7lKZd4q2go03oD27rHuyOQWygS3kRq9QxCV7/a7kol2L7OOBY3/tOtU0YuR1SaC1Rp3oonJoU\n\thpsmytzpfjURraWzQ4DYWNuBVH0NM1gtBHUJUoFHr+PIBrjTCxn31JSl+8T4g5duCZTq2gmyF3Q\n\tqlUfiGTnuTCYzvlEE6HNDEkfNeehe6qXgCKpKz9B+RkqC0sx6mxl3g99rUKNngz1PfKtr7Reuvu\n\tsBENYjVJz+AQ3yHAIg==","X-Received":"by 2002:a17:907:3ea5:b0:b9c:80d5:f01d with SMTP id\n a640c23a62f3a-b9d7248489amr28294266b.15.1775762266312; Thu, 09 Apr 2026\n 12:17:46 -0700 (PDT)","Precedence":"bulk","X-Mailing-List":"linux-i2c@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","References":"<20260324173527.11321-1-sebasjosue84@gmail.com>\n <20260324201858.46591-1-sebasjosue84@gmail.com>\n <2o8np813-n9n6-32sn-922p-6qnrq45s7rs7@xreary.bet>\n \n <7qr72215-4q40-qon4-808o-7o639qq90q3s@xreary.bet>","In-Reply-To":"<7qr72215-4q40-qon4-808o-7o639qq90q3s@xreary.bet>","From":"Michael Zaidman ","Date":"Thu, 9 Apr 2026 22:17:33 +0300","X-Gm-Features":"AQROBzDUKfzKx0I6op-NC1K0D3CmW-7Z4_EpR32Zz1oP0pvTVWsGpsyO6bE_-Mk","Message-ID":"\n ","Subject":"Re: [PATCH v2] HID: ft260: validate report size and payload length in\n raw_event","To":"Jiri Kosina ","Cc":"Sebastian Josue Alba Vives ,\n Benjamin Tissoires ,\n\tlinux-i2c@vger.kernel.org, linux-input@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, stable@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable"}}]