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  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]
Date:   Tue, 29 Dec 2020 12:22:16 +0000
From:   Carsten Haitzler <>
To:     Yury Norov <>,
        Andy Shevchenko <>
CC:     Liviu Dudau <>,
        Linux Kernel Mailing List <>,
        Andrew Morton <>,
        Rasmus Villemoes <>
Subject: Re: [PATCH] drm/komeda: use bitmap API to convert U32 to bitmap

On 12/28/20 8:10 PM, Yury Norov wrote:
> On Mon, Dec 28, 2020 at 11:49 AM Andy Shevchenko
> <> wrote:
>> On Mon, Dec 28, 2020 at 11:43:43AM -0800, Yury Norov wrote:
>>> The commit be3e477effba636ad25 ("drm/komeda: Fix bit
>>> check to import to value of proper type") fixes possible
>>> out-of-bound issue related to find_first_bit() usage, but
>>> does not address the endianness problem.
>> Hmm... Can you elaborate?
>> ...
>>>                                    u32 comp_mask)
>>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
>> Here we convert u32 to unsigned long (LSB is kept LSB since it happens in
>> native endianess).
>>> -     id = find_first_bit(&comp_mask_local, 32);
>> Here it takes an address to unsigned long and tries only lower 32 bits.
>> Are you telling that find_first_bit() has an issue?
> It seems you're right, there's no issue with endianness in existing code.
> In fact, the line

Indeed Andy covered this. Take LSB32 with the cast to "local on-stack
long" and possible extend upper 32bits with 0's if needed (64bit longs).

>>> -     unsigned long comp_mask_local = (unsigned long)comp_mask;
> is an opencoded version of bitmap_from_arr32(dst, src, 32).
> Maybe it would be better to use the bitmap API here, but existing code is
> correct. Sorry for the noise.
While your code is seemingly also valid (I can check to be sure with
KASAN if you want still), it does seem a little less "nice to read" with
more lines of code for the same work. Is it worth making the code a
little longer here as it's not actually fixing anything to do it this
other way? DECLARE_BITMAP() is a bit of an obscure way to declare a
single unsigned long (in this case) where the compiler does the right
thing anyway with a simple assign+cast making it easier to read/follow IMHO.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Powered by blists - more mailing lists