Skip to contentSkip to conversation

m68k: fix find_next bitops

PATCH Geert Uytterhoeven 3 participants 4 messages Mar 30, 2011 – Mar 31, 2011 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Geert Uytterhoeven

author
#1 lore raw
Quoted 13 lines · Akinobu Mita

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.

Quoted 8 lines

2. Then find_first_bit(bimap + 2, -1)

3. Unfortunately find_fist_bit() takes unsigned int as the size argument.

4. find_first_bit will access bitmap[2~] until it find any set bits.

This switches find_next bitops to use generic implementation of find bitops to fix the problem.

Andreas, do you think it's worth keeping (and fixing) the m68k "optimized" versions?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

#2 lore raw
Quoted 2 lines · Geert Uytterhoeven

Andreas, do you think it's worth keeping (and fixing) the m68k "optimized" versions?

Should be easy to add the required offset >= size checks.

Andreas.

Signature · 3 lines
Andreas Schwab, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
#3 lore raw

2011/3/31 Andreas Schwab <[email protected]>:

Quoted 6 lines
Quoted 2 lines · Geert Uytterhoeven

Andreas, do you think it's worth keeping (and fixing) the m68k "optimized" versions?

Should be easy to add the required offset >= size checks.

OK, I'll try to fix the optimized version.
Or, could someone who can test on the real hardware fix this problem?

author
#4 lore raw
Quoted 10 lines · Akinobu Mita

2011/3/31 Andreas Schwab <[email protected]>:

Quoted 6 lines
Quoted 2 lines · Geert Uytterhoeven

Andreas, do you think it's worth keeping (and fixing) the m68k "optimized" versions?

Should be easy to add the required offset >= size checks.

OK, I'll try to fix the optimized version.
Or, could someone who can test on the real hardware fix this problem?

I'll have a look...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds