question about potential integer truncation in default_erasesize

[PaX Team]

On 28 Sep 2015 at 19:02, Brian Norris wrote:

> On Sat, Sep 26, 2015 at 03:18:08PM +0200, PaX Team wrote:
> > hi all,
> > 
> > drivers/mtd/chips/map_rom.c:default_erasesize can truncate map_info.size
> > from unsigned long to unsigned int on 64 bit archs and i'm wondering if
> > this is intentional or should/could map_info.size be turned into an unsigned
> > int field? FTR, this issue was detected with the upcoming version of the
> > size overflow plugin we have in PaX/grsecurity and there're a handful of
> > similar cases in the tree where potentially unwanted or unnecessary integer
> > truncations occur, this being one of these. any opinion/help is welcome!
> 
> This is being assigned to the erasesize, which is 32-bit already, and
> all of MTD expects a 32-bit erasesize, so it'd be a pretty big job to
> "fix" the truncation.

to make sure i got this right, map_info.size in other uses can hold a
value larger than 4GB (so it has to stay 64 bit, at least on 64 bit
archs) but for erasesize it should never have such a big value? that'd
actually be fine for us since it means when the overflow plugin instruments
this code any runtime trigger means a real problem, not a false positive.

cheers,
 PaX Team