summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/wd33c93.c
diff options
context:
space:
mode:
authorGeert Uytterhoeven <geert@linux-m68k.org>2011-04-03 14:00:10 +0200
committerGeert Uytterhoeven <geert@linux-m68k.org>2011-05-19 18:19:09 +0200
commitf82a519f1262963d6ab30fa238721463fad2e0c8 (patch)
treec7808cc9a265b923a20d96d5a9aff2c2f1669d4a /drivers/scsi/wd33c93.c
parentm68k: bitops - offset == ((long)p - (long)vaddr) * 8 (diff)
downloadlinux-f82a519f1262963d6ab30fa238721463fad2e0c8.tar.xz
linux-f82a519f1262963d6ab30fa238721463fad2e0c8.zip
m68k: bitops - Never step beyond the end of the bitmap
find_next bitops on m68k (find_next_zero_bit, find_next_bit, and find_next_bit_le) may cause out of bounds memory access when the bitmap size in bits % 32 != 0 and offset (the bitnumber to start searching at) is very close to the bitmap size. For example, unsigned long bitmap[2] = { 0, 0 }; find_next_bit(bitmap, 63, 62); 1. find_next_bit() tries to find any set bits in bitmap[1], but no bits set. 2. Then find_first_bit(bimap + 2, -1) 3. Unfortunately find_first_bit() takes unsigned int as the size argument. 4. find_first_bit will access bitmap[2~] until it find any set bits. Add missing tests for stepping beyond the end of the bitmap to all find_{first,next}_*() functions, and make sure they never return a value larger than the bitmap size. Reported-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Diffstat (limited to 'drivers/scsi/wd33c93.c')
0 files changed, 0 insertions, 0 deletions