linux-kernel - Re: [PATCH] ARM: amba: Fix leak of driver

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180920072428.GA12411@kroah.com>
Date:   Thu, 20 Sep 2018 09:24:28 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Trent Piepho <tpiepho@...inj.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Todd Kjos <tkjos@...gle.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH] ARM: amba: Fix leak of driver_override attribute value

On Thu, Sep 20, 2018 at 09:16:36AM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Thu, Sep 20, 2018 at 9:09 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> > On Thu, Sep 20, 2018 at 08:48:36AM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Sep 20, 2018 at 1:48 AM Trent Piepho <tpiepho@...inj.com> wrote:
> > > > If driver_override was set when a device was released the string would
> > > > not be kfree'ed in amba_device_release and thus leaked when the amba
> > > > device was freed.
> > > >
> > > > Cc: Russell King <linux@...linux.org.uk>
> > > > Cc: Todd Kjos <tkjos@...gle.com>
> > > > Cc: Geert Uytterhoeven <geert+renesas@...der.be>
> > > > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > > Signed-off-by: Trent Piepho <tpiepho@...inj.com>
> > >
> > > Reported-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > > Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device
> > > binding path 'driver_override'")
> >
> > Then it should also have a cc: stable, right?
> 
> Perhaps. I usually leave that up to the maintainer, else git send-email sends
> it to stable immediately.

That's fine, no one ever complains about that.  In fact it is _good_ to
have that happen, as it gives us stable people a "heads up" that
something is coming to resolve a reported problems.

> The modern backporting AI will consider it anyway, due to the subject, and
> the Fixes tag, right?

Don't count on the "AI" to pick things up if you _know_ it resolves a
problem, like you have said here.

So please, just add it when you know it needs to be backported,
otherwise it might never get backported.

thanks,

greg k-h