linux-kernel - Re: [PATCH v4 1/3] usb: typec: ucsi: Limit read size on v1.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANFp7mW0F_zyaKJg0LusT6Cp4h0_8Z4jq+R1GUGtpyZrv99iVw@mail.gmail.com>
Date: Fri, 9 Feb 2024 10:01:07 -0800
From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>, linux-usb@...r.kernel.org, 
	jthies@...gle.com, pmalani@...omium.org, 
	Neil Armstrong <neil.armstrong@...aro.org>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, 
	Fabrice Gasnier <fabrice.gasnier@...s.st.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hans de Goede <hdegoede@...hat.com>, 
	Rajaram Regupathy <rajaram.regupathy@...el.com>, Saranya Gopal <saranya.gopal@...el.com>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/3] usb: typec: ucsi: Limit read size on v1.2

On Fri, Feb 9, 2024 at 6:28 AM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Thu, Feb 08, 2024 at 10:02:38PM -0800, Abhishek Pandit-Subedi wrote:
> > Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was
> > increased from 16 to 256. In order to avoid overflowing reads for older
> > systems, add a mechanism to use the read UCSI version to truncate read
> > sizes on UCSI v1.2.
>
> ...
>
> > +     if (ucsi->version <= UCSI_VERSION_1_2)
> > +             buf_size = min_t(size_t, 16, buf_size);
>
> Please, avoid using min_t(). Here the clamp() can be used.
I think this is likely the 4th time I've been tripped up by an
undocumented practice in this patch series. <linux/minmax.h> says
nothing about avoiding min_t -- why prefer clamp()? Please add the
recommendation here
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/minmax.h#n10)
and I am more than happy to change it after.

> Shouldn't magic number be defined?
The comment right above this line documents the number.
As this is the only use right now, I don't see a need to make it a
macro/constant yet.

>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Cheers,
Abhishek