Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1584426607-89366-1-git-send-email-xiyuyang19@fudan.edu.cn>
 <20200318110204.GB2305113@kroah.com> <20200323045302.GA117440@sherlly> <20200323065506.GA131098@kroah.com>
In-Reply-To: <20200323065506.GA131098@kroah.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 23 Mar 2020 10:20:28 +0100
Message-ID: <CAK8P3a29230XO8W2SWMQ-5z0nrtfWjPmh_4jrhjew+C=Qoaw-Q@mail.gmail.com>
Subject: Re: Re: [PATCH] VMCI: Fix NULL pointer dereference on context ptr
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Xiyu Yang <xiyuyang19@fudan.edu.cn>,
        Xin Tan <tanxin.ctf@gmail.com>,
        Alexios Zavras <alexios.zavras@intel.com>,
        Vishnu DASA <vdasa@vmware.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Allison Randal <allison@lohutok.net>,
        Ira Weiny <ira.weiny@intel.com>,
        Mike Marshall <hubcap@omnibond.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        yuanxzhang@fudan.edu.cn, kjlu@umn.edu
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 23, 2020 at 7:55 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.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