Re: [patch 27/95] scanf: fix type range overflow

[Linus Torvalds]

On Wed, Sep 9, 2015 at 3:36 PM,  <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> From: Alexey Dobriyan <adobriyan@xxxxxxxxx>
> Subject: scanf: fix type range overflow

This is another patch that claims to fix a bug, but looks
fundamentally broken unless I'm misreading something.

Like it or not, people write code like

    unsigned int x;

and then may well initialize it with "-1" or with 0xffffffff depending
on how they feel and what helper macros etc they used.

And I see no reason to believe that the same wouldn't be true of
sscanf().  In fact, I'm pretty sure it happens exactly for things like
initializing bitmasks etc.

But you seem to want to make this an error, because your seem to
verify that the underlying numerical value it fits in whatever
(signed/unsigned) type that is being converted.

Maybe I misread the code, but that's what it looks like.

And it's wrong. People may use "%d" for "unsigned int" exactly because
they want the "-1" to work, but "4294967294" should work too.

> Fun fact:
>
>         uint8_t val;
>         sscanf("256", "%hhu", &val);
>
> will return 1 and make val=0 (clearly bogus).

Fun fact: overflows are not at all always clearly bogus.

Come to think of it, I think that the parse_integer() interface may
have had the same bug.

Too much "I know better than you" is actually a bug.

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/