linux-kernel - Re: CVE-2022-49623: powerpc/xive/spapr: correct bitmap allocation size

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: <0bea64d3-34bd-4c4f-8386-ce29acaf5f6c@huawei.com>
Date: Fri, 7 Mar 2025 11:16:29 +0800
From: "zhangjianhua (E)" <chris.zjh@...wei.com>
To: Greg KH <gregkh@...uxfoundation.org>, <nathanl@...ux.ibm.com>,
	<mpe@...erman.id.au>
CC: <cve@...nel.org>, <linux-cve-announce@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, "youbowen (A)" <youbowen2@...wei.com>
Subject: Re: CVE-2022-49623: powerpc/xive/spapr: correct bitmap allocation
 size

Yes, there is still some confusion about this bugfix patch. Hope Nathan 
and Michael can explain and give more details.

在 2025/3/6 21:58, Greg KH 写道:
> On Thu, Mar 06, 2025 at 09:41:41PM +0800, zhangjianhua (E) wrote:
>> Hi Greg，
>>
>> The commit message of this patch show that it occurs out-of-bounds of
>> xibm->bitmap，the reason is that the allocated object can be smaller than
>> sizeof(long) while bits is small.
>>
>> However, it is incorrect.  The kzalloc interface allocates memory in the
>> unit of byte while bitmap_zalloc does based on the number of bits after
>> rounded up, the space allocated by the kzalloc is not less than that
>> allocated by the bitmap_zalloc. Therefore, replacing the kzalloc with the
>> bitmap_zalloc does not solve the problem. In fact, the problem of
>> out-of-bounds access does not exist. For instance the xibm->count is
>> 3，kzalloc and bitmap_zalloc both return 8 bytes，it's enough for all
>> bitmap. Although using the kzalloc wastes some memory, it does not create
>> any real problems.
>>
>> Maybe this CVE should be rejected?
> We will be glad to reject this if you think this does not actually fix
> anything at all.  If so, just let us know.
>
> thanks,
>
> greg k-h
>
>