Hi Nathan,
On 02/10/2024 17:22, Nathan Chancellor wrote:
> Hi Andrej,
>
> On Wed, Oct 02, 2024 at 04:12:17PM +0200, Andrej Shadura wrote:
>> Commit 9bf4e919ccad worked around an issue introduced after an innocuous
>> optimisation change in LLVM main:
>>
>>> len is defined as an 'int' because it is assigned from
>>> '__user int *optlen'. However, it is clamped against the result of
>>> sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit
>>> platforms). This is done with min_t() because min() requires compatible
>>> types, which results in both len and the result of sizeof() being casted
>>> to 'unsigned int', meaning len changes signs and the result of sizeof()
>>> is truncated. From there, len is passed to copy_to_user(), which has a
>>> third parameter type of 'unsigned long', so it is widened and changes
>>> signs again. This excessive casting in combination with the KCSAN
>>> instrumentation causes LLVM to fail to eliminate the __bad_copy_from()
>>> call, failing the build.
>>
>> The same issue occurs in rfcomm in functions rfcomm_sock_bind and
>> rfcomm_sock_getsockopt_old.
> Was this found by inspection or is there an actual instance of the same
> warning? For what it's worth, I haven't seen a warning from this file in
> any of my build tests.
We’ve seen build errors in rfcomm in the Chromium OS 4.14 kernel.
>> Change the type of len to size_t in both rfcomm_sock_bind and
>> rfcomm_sock_getsockopt_old and replace min_t() with min().
>>
>> Cc: stable@xxxxxxxxxxxxxxx
>> Fixes: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()")
> I am not sure that I totally agree with this Fixes tag since I did not
> have a warning to fix but I guess it makes sense to help with
> backporting.
It’s a shame there isn’t a Complements: or Improves: tag :)
--
Cheers,
Andrej
