Hi,
On Sun, 2 Jan 2022 at 17:21, Pavel Skripkin <paskripkin@xxxxxxxxx> wrote:
>
> On 1/3/22 01:15, Alexander Aring wrote:
> > Hi,
> >
> > On Sun, 2 Jan 2022 at 12:19, Pavel Skripkin <paskripkin@xxxxxxxxx> wrote:
> >>
> >> Alexander reported a use of uninitialized value in
> >> atusb_set_extended_addr(), that is caused by reading 0 bytes via
> >> usb_control_msg().
> >>
> >
> > Does there exist no way to check on this and return an error on USB
> > API caller level?
> >
> >> Since there is an API, that cannot read less bytes, than was requested,
> >> let's move atusb driver to use it. It will fix all potintial bugs with
> >> uninit values and make code more modern
> >>
> >
> > If this is not possible to fix with the "old" USB API then I think the
> > "old" USB API needs to be fixed.
> > Changing to the new USB API as "making the code more modern" is a new
> > feature and is a candidate for next.
> >
>
> It can be fixed with the old one. Something like that should work:
>
> - if (ret < 0) {
> - atusb->err = ret;
> + if (ret < size) {
> + atusb->err = ret < 0: ret: -ENODATA;
>
> But I thought, that moving to new API is better fix, just because old
> one prone to uninit value bugs if error checking is wrong
A fix should have the smallest changes as possible and not use "new
stuff" which might break other things. Also I am not sure since "when"
this new USB API exists. To backport the fix into stable send a fix
using the "old USB API".
If the fix is upstream you can send patches to use the new API and
remove the additional check if this is done by using the new API.
Maybe it's worth checking that the errno stays the same.
Thanks.
- Alex
