linux-kernel - Re: [PATCH] usb: functionfs: avoid memcpy() field overflow warning

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] [day] [month] [year] [list]

Message-Id: <8af6715a-8dc9-4cd4-9a83-acc27e539c54@app.fastmail.com>
Date:   Mon, 03 Jul 2023 15:05:14 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Arnd Bergmann" <arnd@...nel.org>
Cc:     "Udipto Goswami" <quic_ugoswami@...cinc.com>,
        "John Keeping" <john@...ping.me.uk>,
        "Linyu Yuan" <quic_linyyuan@...cinc.com>,
        "Dan Carpenter" <error27@...il.com>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: functionfs: avoid memcpy() field overflow warning

On Mon, Jul 3, 2023, at 14:45, Greg Kroah-Hartman wrote:
> On Mon, Jul 03, 2023 at 02:30:32PM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@...db.de>
>> 
>> __ffs_func_bind_do_os_desc() copies both the CompatibleID and SubCompatibleID
>> fields of the usb_ext_compat_desc structure into an array, which triggers
>> a warning in the fortified memcpy():
>> 
>> In file included from drivers/usb/gadget/function/f_fs.c:17:
>> In file included from include/linux/string.h:254:
>> include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
>>                         __read_overflow2_field(q_size_field, size);
>> 
>> Usually we can avoid this by using a struct_group() inside of the structure
>> definition, but this might cause problems in userspace since it is in a uapi
>> header.
>
> We use this in other uapi .h files, what is unique about these fields
> that makes it so that they can not be used?  Because it's not the last
> field?

It's probably ok, and I was overly cautious. I'll send a new version after
some more testing.

       Arnd