linux-kernel - Re: Re: [PATCH] VMCI: Fix NULL pointer dereference on context ptr

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] [day] [month] [year] [list]

Date:   Mon, 23 Mar 2020 10:20:28 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Xiyu Yang <xiyuyang19@...an.edu.cn>,
        Xin Tan <tanxin.ctf@...il.com>,
        Alexios Zavras <alexios.zavras@...el.com>,
        Vishnu DASA <vdasa@...are.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Allison Randal <allison@...utok.net>,
        Ira Weiny <ira.weiny@...el.com>,
        Mike Marshall <hubcap@...ibond.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        yuanxzhang@...an.edu.cn, kjlu@....edu
Subject: Re: Re: [PATCH] VMCI: Fix NULL pointer dereference on context ptr

On Mon, Mar 23, 2020 at 7:55 AM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Mon, Mar 23, 2020 at 12:53:02PM +0800, Xiyu Yang wrote:
> > On Wed, Mar 18, 2020 at 12:02:04PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Mar 17, 2020 at 02:29:57PM +0800, Xiyu Yang wrote:
> > >
> > > Same comment as on your other patch.
> > >
> > > And is this a v2?
> >
> > Thanks! Yes, this is a v2.
> >
> > According  to our observation, vmci_ctx_rcv_notifications_release()
> > currently is only called by vmci_host_do_recv_notifications() which
> > guarantees a valid context object can be acquired with this context_id.
> >
> > However, we argue that a NULL-check here is still necessary because
> > this function may be called by other functions in the future who may
> > fail/forget to provide such guarantee.
>
> No, that's not how we write code in the kernel, if it does not need to
> be checked for because this can not happen, then do not check for it.
>
> Don't try to plan for random users of your code in the future when you
> control those users directly :)

Just saw this reply after replying to the other mail. I guess I picked
a bad example ;-)

If there was in fact a report about a NULL pointer at put() time
somewhere, that would be the first thing to fix, and it may still
make sense to review the other code paths to see if there
are additional cases that can go wrong.

      Arnd