[Skiboot] [PATCH] core/bitmap: fix bitmap iteration limit corruption

[Stewart Smith]

Stewart Smith <stewart at linux.vnet.ibm.com> writes:
> Nicholas Piggin <npiggin at gmail.com> writes:
>> The bitmap iterators did not reduce the number of bits to scan
>> when searching for the next bit, which would result in them
>> overruning their bitmap.
>>
>> These are only used in one place, in xive reset, and the effect
>> is that the xive reset code will keep zeroing memory until it
>> reaches a block of memory of MAX_EQ_COUNT >> 3 bits in length,
>> all zeroes.
>>
>> Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
>> ---
>>  include/bitmap.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Nice!
>
> It seems that this test case modification would find it and check it's
> fixed too.
>
> With this patch (but without yours), a standard 'make check' would
> explode appropriately revealing the bug:
>
> ==17110== Invalid read of size 8
> ==17110==    at 0x400849: __bitmap_find_bit (bitmap.c:31)
> ==17110==    by 0x400900: bitmap_find_zero_bit (bitmap.c:49)
> ==17110==    by 0x400E50: main (run-bitmap.c:77)
> ==17110==  Address 0x5221048 is 0 bytes after a block of size 8 alloc'd
> ==17110==    at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
> ==17110==    by 0x40093F: main (run-bitmap.c:24)

Thanks! Merged to master as of 2df2407375963ab08bcb3c62eb7230c07e734687
with the test going in just after it as
2be4422dace9960b56f27cc611644ca5fdd292d9


-- 
Stewart Smith
OPAL Architect, IBM.