From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (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 05797379979 for ; Thu, 30 Apr 2026 20:48:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777582138; cv=none; b=rFoI+cwMEiFwTws2T81E/u6Yqhhh5JX95BInpIzyB9CC4kRrcX47P706xstYNLTuYnQj/v9onySBfKlSjSa28JmR8e/qPacl3Z4tCZi5OW1jEm3ADbllePeyEtiE+e25ROBFH14IaMpAucHMrvUdDl2MlZFyIzV0kMjalPMuBlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777582138; c=relaxed/simple; bh=0aYvI5HJx2a7Ye/kV+wVSKCdA0MdaGoGJgH54BhO0Fc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mFJuKnahk67KUgHU0mSjXMHca3eKsY9kJMsEaKOH33FryNC0R82eSKyXlwXnQZ59lZJFh9HpbFipTi5BQMI8rs0fOCMvS1+eGGryPNBYeBdAPB0rtAVgP862+u3p5BZzdREq/L8wo7s7E5UBf4Jx9ppv9s7ys0PiaH0oyY3vpIc= 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=tIYlj4AI; arc=none smtp.client-ip=209.85.208.169 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="tIYlj4AI" Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-38e97e73234so13468341fa.1 for ; Thu, 30 Apr 2026 13:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777582135; x=1778186935; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=rC73R2jno3BsE6Xg9/1+V+UkWHqOyAMiHRyysx7QLyw=; b=tIYlj4AIR1na9BZ9ZXYo30nuKAAFofpUbDBpBFPI9KJiqasZtvhq1GtCmctoXAUQjU c4Oen961tgYBfWhgTINhpAnZji3T9KIdbmk5k3cY4TRgDSACLZGdncdPi8ynvGZxmXfu bs0GNEw6nnceDdYn6KYjyZhNzz9wY02Pws4S7V7l7eWqEuAwYPXlaNHpFNZ+gg+eFwP8 B+Rac9kzr0wGx9cLSrV6a9Ns1Hn2hw1kQEbEZzWw7jEJNZew8n/lLiga27lQpLEQoLvg jW3MsYPbYbnlV5COHPqxuJpvxhIkctA+akjtqbpKdsPYOiz+neGXbfaldR57/M16BFur dn0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777582135; x=1778186935; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=rC73R2jno3BsE6Xg9/1+V+UkWHqOyAMiHRyysx7QLyw=; b=OMEQXRpOLCGJozFD75srwclHiudt3nOBeUvfFYJ3ypwDGsc9utMUiMK4vxZQgA1gL8 +xTBSrw760Tk7J4e+SFBpNwnRw4w4kc99Bw806mjhGab0VVXHFsEfZvkp3HGKv6B5f89 q0929btPDSgNVLNVtdptutRCfs+FUo4KcJQ1dpoJ0Lv02Nd/9rODGMcYKv97XvTP/5C8 IilZ3Vqu7VMjYAkhWd8oYC99HwOKIpUzA1G9sP9j7D8Ey3WGMCBqkOU45OrBQ6cOJUuY E2irHIuOonYgIZOvxck77k19YBUW4qBjleRf7saHmaHobCKngcdTS9Kvvk58h9qOb/Fe CDUg== X-Forwarded-Encrypted: i=1; AFNElJ+hcoEdT9ntoxzg7nw4qC+44zizRuQMCbpDoObU+ltW1e2J6cCf0no0kpO/q0RKu6Wr7GyeUm4jq6XDAsg=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5zAYKEpRN3vm/qutgs76gw44eF02LzwfhRkCZpzD2j7Dp6Gzt Dk8gyBIuQ6hqr1See5lwgXbcNVKDvCtLkDS1knv/LlcYpzC+OS03f+4q X-Gm-Gg: AeBDietwcC5fDZDDGBqRXJK+vul8rnjXUTLPnZPFL+zl6OqR8yGzlIM/94HvGRi4y56 6KyQKzHetN2YZdy4f+CA4/b6j5ngAF4xhY8s2QL0LZnhWvWIggKE1UakmALwxWKuf0ptNVFLSt3 Ln5difj9rHqsLWOl96S4uby9wUo+pmba5i2DtBGmDCnwAu8+NfbIOXIIWoL3PzW3KNuEXwYR1U3 XepHOdvEli8WCKKpr/wBCHDdO7XYDW5rByMhAwmXgfbpyonsYWmjSBHLNvEBqzaiepd3Hcjgo+I mDdYssJQ/RYW1c7RwYMqgfZGRqgSF1Z6WVdNMBd6OPEgUBfwHVcoINlRo9j66fCW2D73cq7mbyZ i8N+e19n47bts8Hcev4gk424+wQ487B0b7ltASDJNhsFyMNN45z/eukBXv7CjD7eTh0aReaBDXj oTL7q64lKi1QpgPjgq6Q/GCaXSGfeS986YxJFwnvCphvs= X-Received: by 2002:a2e:a54c:0:b0:38d:e977:5533 with SMTP id 38308e7fff4ca-3934e26fe64mr16249081fa.26.1777582134864; Thu, 30 Apr 2026 13:48:54 -0700 (PDT) Received: from foxbook (bfh75.neoplus.adsl.tpnet.pl. [83.28.45.75]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3936108fb80sm2811171fa.6.2026.04.30.13.48.52 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 30 Apr 2026 13:48:54 -0700 (PDT) Date: Thu, 30 Apr 2026 22:48:49 +0200 From: Michal Pecio To: "Heitor Alves de Siqueira" Cc: "Greg Kroah-Hartman" , , , , , Subject: Re: [PATCH v2] usb: usbtmc: reject invalid interrupt endpoints Message-ID: <20260430224849.3322afb0.michal.pecio@gmail.com> In-Reply-To: References: <20260423-usbtmc-iin-size-v2-1-31afa4874f71@igalia.com> <20260424002839.5ad25517.michal.pecio@gmail.com> <20260429001626.2f08b991.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 30 Apr 2026 15:31:55 -0300, Heitor Alves de Siqueira wrote: > > I think a minimal fix which mostly preserves existing behavior would > > be adding "urb->actual_length == 2" as a requirement for all USB488 > > notifications. Then any truncated message will be ignored and logged. > > Yes, that's my understanding as well! Although I don't think bNotify2 > would ever be zero in practice, this sounds like a good approach. I'll > submit a v3 with this change plus the endpoint check from v2, hopefully > that'll improve things for these edge cases. With actual_length check, wMaxPacketSize check isn't critical anymore because actual_length won't exceed URB buffer size. > > wMaxPacketSize is a separate issue indeed and it seems that a USB488 > > device could legally set it to 1, though it would be crazy. Your v1 > > patch would probably make such devices work, if anyone cares. > > Honestly, I'm also more inclined to just reject endpoints with this > configuration. This seems like a very niche edge-case, I'd be surprised > if real hardware operated like this (famous last words? heh). I'm not > sure if this would even be valid/legal, given your previous point on > bNotify2 being one byte. USBTMC spec refers to USB 2.0 section 5.7.3, which states that an interrupt transfer may take multiple packets until either the IRP (URB) is filled or a packet shorter than wMaxPacketSize (possibly 0) is sent. So slow, inefficient and unlikely to exist - yes. But illegal - not really. Such endpoint can deliver 2 byte messages. Also, a non-USB488 device may be sending different, very simple 1 byte messages, perhaps vendor specific ones. None of them are recognized by the driver, but other functionality of such device could still work, so rejecting it is overkill. > Considering these devices do not work at all currently, checking if > wMaxPacketSize and urb->actual_length are big enough seems like a > saner approach and won't require bigger changes to the driver. The only change to support USB488 devices with wMaxPacketSize == 1 should be increasing URB size to at least 2 bytes. But I wouldn't bother when no such HW is known to exist, and surely not as part of a barely related bugfix patch. Regards, Michal