question about potential integer truncation in default_erasesize

[Brian Norris]

On Tue, Sep 29, 2015 at 10:56:25PM +0200, PaX Team wrote:
> 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?

Correct.

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

OK, good. As long as you aren't going to start complaining about
theoretical concerns we're OK, but a dynamic check is cool.

Brian