On Mon, Mar 03, 2025 at 11:30:46AM +0100, Uwe Kleine-König wrote:
> On Mon, Mar 03, 2025 at 01:08:29PM +0300, Dan Carpenter wrote:
> > On Mon, Mar 03, 2025 at 10:19:06AM +0100, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > On Sun, Mar 02, 2025 at 07:02:12PM +0100, Markus Elfring wrote:
> > > > From: Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
> > > > Date: Thu, 13 Apr 2023 21:35:36 +0200
> > > >
> > > > The address of a data structure member was determined before
> > > > a corresponding null pointer check in the implementation of
> > > > the function “au1100fb_setmode”.
> > > >
> > > > Thus avoid the risk for undefined behaviour by moving the assignment
> > > > for the variable “info” behind the null pointer check.
> > > >
> > > > This issue was detected by using the Coccinelle software.
> > > >
> > > > Fixes: 3b495f2bb749 ("Au1100 FB driver uplift for 2.6.")
> > > > Signed-off-by: Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
> > >
> > > Acked-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxx>
> > >
> > > Should also get
> > >
> > > Cc: stable@xxxxxxxxxxxxxxx
> > >
> > > to ensure this is backported to stable.
> >
> > It's not a bugfix, it's a cleanup. That's not a dereference, it's
> > just pointer math. It shouldn't have a Fixes tag.
> >
> > Real bugs where we dereference a pointer and then check for NULL don't
> > last long in the kernel. Most of the stuff Markus is sending is false
> > positives like this.
>
> I thought a compiler translating the code
>
> struct fb_info *info = &fbdev->info;
>
> if (!fbdev)
> return -EINVAL;
>
> is free (and expected) to just drop the if block.
If you dereference a pointer then it doesn't make sense to have a NULL
check after that because the kernel would already have crashed.
In 2009, we had the famous tun.c bug where there was a dereference
followed by a NULL check and the compiler deleted it as you say.
And then, it turned out that you could remap the NULL pointer to and so
the NULL dereference didn't lead to a crash and the missing NULL meant
the kernel kept running happily. The remapped memory was full of
function pointers to get root.
We changed min_mmap_addr so that we can't remap the NULL pointer and
we started using the -fno-delete-null-pointer-checks compiler option so
that it wouldn't remove the NULL check even in places where it didn't
make sense. We also started doing more static analysis. We've also
tried to randomize where functions are in the memory so it's trickier
to hardcode function pointers.
A couple years later we had another bug where it turned out you could
still remap NULL. I forget how the details. No one wrote an exploit
and it wasn't publicized as much.
Anyway, none of that applies here, because this is just pointer math.
regards,
dan carpenter
