Re: Re: signed integer overflow in common_timer_get on linux 4.15.0-rc1

[Daniel Micay <danielmicay () gmail com>]

On Fri, 2017-12-08 at 12:09 +0300, Dan Carpenter wrote:
> On Thu, Dec 07, 2017 at 12:17:18PM +0100, Greg KH wrote:
> > On Thu, Dec 07, 2017 at 06:01:43PM +0800, at zhou wrote:
> > > Hi all,
> > >
> > > credit   to   L5@360vulcan team
> > >
> > > I fuzzed the linux kernel and find signed integer overflow on
> > > linux
> > > 4.15.0-rc1+.
> > > the crash log can see below, the .config and the poc file ,please
> > > see the
> > > attachments.
> >
> > Odd, doesn't seem to affect a 4.9 or 4.15-rc2 kernel here on my
> > machines, is there something specific in the .config that might be
> > triggering this?
>
> Greg, you're running with UBSAN?
>
> I've always wondered how UBSAN was going to work because there are
> *so*
> many harmless integer overflows in the kernel.  That's my main
> challenge
> with trying to use static analysis for integer overflows.
>
> regards,
> dan carpenter

There are options for marking intended overflows to start moving towards
it being more useful. There's no_sanitize for marking intended overflow,
etc. at a function scope. The overflow intrinsics bypass the checks so
they can be used to mark specific operations as having intended overflow
for more clarity and better coverage.

Of course, people would need to agree that it has enough value to be
worth putting in this effort. It can improve code readability despite
the extra verbosity in these cases too, especially with good taste when
choosing no_sanitize vs. marking specific operations.

Android uses both signed + unsigned overflow checks in production for
their media stack via the trapping mode (debugging mode used more
broadly) so it can be quite successful and can go beyond just using it
for debugging.