linux-kernel - Re: linux-6.19-rc8/kernel/liveupdate/kexec_handover.c:1089: Possible 32/64 bit mixup ?

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: <2vxzzf5gsolq.fsf@kernel.org>
Date: Tue, 10 Feb 2026 14:41:05 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: David Binderman <dcb314@...mail.com>
Cc: "graf@...zon.com" <graf@...zon.com>,  "rppt@...nel.org"
 <rppt@...nel.org>,  "pasha.tatashin@...een.com"
 <pasha.tatashin@...een.com>,  "pratyush@...nel.org" <pratyush@...nel.org>,
  "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
  "linux-mm@...ck.org" <linux-mm@...ck.org>,  LKML
 <linux-kernel@...r.kernel.org>
Subject: Re: linux-6.19-rc8/kernel/liveupdate/kexec_handover.c:1089:
 Possible 32/64 bit mixup ?

Hi David,

On Thu, Feb 05 2026, David Binderman wrote:

> Hello there,
>
> Source code analyser cppcheck says:
>
> linux-6.19-rc8/kernel/liveupdate/kexec_handover.c:1089:15: style: int result is
> assigned to long variable. If the variable is long to avoid loss of information,
> then you have loss of information. [truncLongCastAssignment]
>
> Source code is
>
>     contig_pages = (1 << order);
>
> I admit the error message is hard to understand, but AFAIK
> if local variable order remains under 30 or so, then there is no problem.
>
> However, if it goes above 32, then there will be loss of data. 
> Expression 1 << order is type int.
>
> Suggest add some code or comment to document the expected range
> of local variable order. If it ever goes above 32, suggest new code
>
>     contig_pages = 1UL << order;

If order is 32, with 4k pages, that means 16 TiB. It is unlikely that we
will see vmalloc area backed by pages this large any time soon. So I am
not worried about any practical problems.

But I think this is still a good idea to do for code hygiene. So a patch
would be much appreciated.

-- 
Regards,
Pratyush Yadav