linux-kernel - Re: [PATCH] ipc/sem: ensure we left shift a ULL rather than a 32 bit integer

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: <8570d3d4-aeaf-7d2e-7d04-3234264959fd@colorfullife.com>
Date:   Fri, 28 Oct 2016 21:21:58 +0200
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Colin King <colin.king@...onical.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

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?

--
     Manfred