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: <86085f85-e60f-8942-ccdd-a545a7c949ce@canonical.com>
Date:   Fri, 28 Oct 2016 20:29:03 +0100
From:   Colin Ian King <colin.king@...onical.com>
To:     Manfred Spraul <manfred@...orfullife.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Nikolay Borisov <kernel@...p.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipc/sem: ensure we left shift a ULL rather than a 32 bit
 integer

On 28/10/16 20:21, Manfred Spraul wrote:
> Hi Colin,
> 
> On 10/28/2016 08:11 PM, Colin King wrote:
>> From: Colin Ian King <colin.king@...onical.com>
>>
>> The left shift amount is sop->sem_num % 64, which is up to 63, so
>> ensure we are shifting a ULL rather than a 32 bit value.
> Good catch, thanks.
>> CoverityScan CID#1372862 "Bad bit shift operation"
>>
>> Fixes: 7c24530cb4e3c0ae ("ipc/sem: optimize perform_atomic_semop()")
>> Signed-off-by: Colin Ian King <colin.king@...onical.com>
>> ---
>>   ipc/sem.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ipc/sem.c b/ipc/sem.c
>> index ebd18a7..ca4aa23 100644
>> --- a/ipc/sem.c
>> +++ b/ipc/sem.c
>> @@ -1839,7 +1839,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct
>> sembuf __user *, tsops,
>>         max = 0;
>>       for (sop = sops; sop < sops + nsops; sop++) {
>> -        unsigned long mask = 1 << ((sop->sem_num) % BITS_PER_LONG);
>> +        unsigned long mask = 1ULL << ((sop->sem_num) % BITS_PER_LONG);
>>   
> Why 1ULL? Is 1UL not sufficient?

For example, 1UL i386 is 32 bits, where as 1ULL is 64.
> 
> -- 
>     Manfred

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ