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

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

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

powerpc/xive/spapr: correct bitmap allocation size

kasan detects access beyond the end of the xibm->bitmap allocation:

BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140
Read of size 8 at addr c00000001d1d0118 by task swapper/0/1

CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28
Call Trace:
[c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable)
[c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710
[c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354
[c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0
[c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140
[c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260
[c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450
[c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118
[c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac
[c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640
[c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0
[c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64

Allocated by task 0:
 kasan_save_stack+0x34/0x70
 __kasan_kmalloc+0xb4/0xf0
 __kmalloc+0x268/0x540
 xive_spapr_init+0x4d0/0x77c
 pseries_init_irq+0x40/0x27c
 init_IRQ+0x44/0x84
 start_kernel+0x2a4/0x538
 start_here_common+0x1c/0x20

The buggy address belongs to the object at c00000001d1d0118
 which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
 8-byte region [c00000001d1d0118, c00000001d1d0120)

The buggy address belongs to the physical page:
page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d
flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff)
raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480
raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
>c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc
                            ^
 c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc
 c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc

This happens because the allocation uses the wrong unit (bits) when it
should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small
numbers of bits, the allocated object can be smaller than sizeof(long),
which results in invalid accesses.

Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with
bitmap_free() for consistency.

The Linux kernel CVE team has assigned CVE-2022-49623 to this issue.


Affected and fixed versions
===========================

	Fixed in 5.15.56 with commit 10f2cd373e65bcd3be8f3cdc71c330c25763dfd8
	Fixed in 5.18.13 with commit 99d1c36bddd93919072b5a51a89297bbb5ad6a6f
	Fixed in 5.19 with commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49623
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/powerpc/sysdev/xive/spapr.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/10f2cd373e65bcd3be8f3cdc71c330c25763dfd8
	https://git.kernel.org/stable/c/99d1c36bddd93919072b5a51a89297bbb5ad6a6f
	https://git.kernel.org/stable/c/19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe

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

[zhangjianhua (E)]

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?


Jianhua Zhang

Best regards.

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

[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

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

[zhangjianhua (E)]

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
>
>