On Wed, May 15, 2019 at 04:55:16PM +0300, Dan Carpenter wrote:
> On Wed, May 15, 2019 at 03:40:14PM +0200, Daniel Vetter wrote:
> > On Wed, May 15, 2019 at 03:29:25PM +0200, Noralf Trønnes wrote:
> > > drm_fb_helper_hotplug_event() should tolerate the fb_helper argument being
> > > NULL. Commit 03a9606e7fee ("drm/fb-helper: Avoid race with DRM userspace")
> > > introduced a fb_helper dereference before the NULL check.
> > > Fixup by moving the dereference after the NULL check.
> > >
> > > Fixes: 03a9606e7fee ("drm/fb-helper: Avoid race with DRM userspace")
> > > Reported-by: kbuild test robot <l...@intel.com>
> > > Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
> > > Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
> >
> > Ah the classic "I spotted a deref before your NULL check, I'm going to
> > optimize this all away because you got it wrong" nonsense from gcc. I
> > thought the kernel uses a special compile flag to avoid this optimization
> > ...
>
> This is just a normal NULL dereference bug.
>
> You're thinking of the old tun.c vulnerability. That was back in the
> day before we started using -fno-delete-null-pointer-checks. What
> happened there was the code should have NULL dereferenced and Oopsed but
> GCC optimized it away and it ended up being a privilege escalation bug
> instead.
Hm right, I got confused.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
