linux-kernel - Re: [PATCH] fbmem: prevent potential use-after-free issues with console

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y7ik3ONV5ba7UXQB@phenom.ffwll.local>
Date:   Fri, 6 Jan 2023 23:46:52 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Hang Zhang <zh.nvgt@...il.com>
Cc:     Helge Deller <deller@....de>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Sam Ravnborg <sam@...nborg.org>,
        Alex Deucher <alexander.deucher@....com>,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] fbmem: prevent potential use-after-free issues with
 console_lock()

On Fri, Jan 06, 2023 at 05:12:57PM -0500, Hang Zhang wrote:
> On Fri, Jan 6, 2023 at 4:19 PM Daniel Vetter <daniel@...ll.ch> wrote:
> > On Fri, Jan 06, 2023 at 03:25:14PM -0500, Hang Zhang wrote:
> > > On Fri, Jan 6, 2023 at 3:05 PM Daniel Vetter <daniel@...ll.ch> wrote:
> > > > On Fri, Jan 06, 2023 at 02:58:27PM -0500, Hang Zhang wrote:
> > > > > On Fri, Jan 6, 2023 at 1:59 PM Daniel Vetter <daniel@...ll.ch> wrote:
> > > > > BTW, if this is worthed a fix and the performance of console_lock() is a
> > > > > major concern, then I think there may be alternative solutions like adding
> > > > > a lock_fb_info() to the free call chain - if that's better in performance,
> > > > > or maybe selectively protect the matroxfb ioctl but not vblank ioctl as you
> > > > > mentioned.
> > > >
> > > > Please start out with explaining what kind of bug your checker is seeing,
> > > > and why. Not how you're trying to fix it. Because I'm pretty sure there
> > > > isn't a bug, but since I've already spent a pile of time looking at this,
> > > > I want to make sure.
> > >
> > > We are sorry for the inconvenience caused, we'll follow these practices and
> > > guidelines in the future. Thank you!
> >
> > Once more: Please explain what you're static checker is seeing. I want to
> > understanding this, and I'm hoping at least someone involved in this
> > static checker can explain what it thinks is going on.
> >
> > Thanks, Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> Thank you for your interest, Daniel. The checker tries first to find
> the free and
> use sites of a certain object (in this case "fb_info"), then reason
> about whether
> the use can actually happen after the free (e.g., taking into account
> factors like
> state set/check, locks, etc.), if so, it will flag a potential
> use-after-free. As a static
> checker, is doesn't execute a program or generate a PoC. We then manually
> review each flagged issue by inspecting all related code. In this
> case, the checker
> (and us) are unaware of the lifetime management logic, which may cause
> problems.

Lifetime management is and absolute basic part in the linux kernel. So if
your checker flags every free which isn't protected by a lock, then you'll
creating endless amounts of false positives. Is this really what you're
doing?

I'm still very confused ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch