From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S935013AbcJTMoK (ORCPT <rfc822;w@1wt.eu>);
        Thu, 20 Oct 2016 08:44:10 -0400
Received: from mail-lf0-f67.google.com ([209.85.215.67]:32813 "EHLO
        mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933043AbcJTMoJ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 20 Oct 2016 08:44:09 -0400
Date: Thu, 20 Oct 2016 14:44:06 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Leon Yu <chianglungyu@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>, Kees Cook <keescook@chromium.org>,
        Oleg Nesterov <oleg@redhat.com>, John Stultz <john.stultz@linaro.org>,
        Mateusz Guzik <mguzik@redhat.com>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Janis Danisevskis <jdanis@google.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: fix NULL dereference when reading /proc/<pid>/auxv
Message-ID: <20161020124405.GL14609@dhcp22.suse.cz>
References: <1476885580-7612-1-git-send-email-chianglungyu@gmail.com>
 <20161019171748.GO24393@dhcp22.suse.cz>
 <CAP06WZy2wdcKx70xTihw4U3Z7Vo=9CHSmzL4b-rWVcCxa0M=VQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAP06WZy2wdcKx70xTihw4U3Z7Vo=9CHSmzL4b-rWVcCxa0M=VQ@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu 20-10-16 20:32:43, Leon Yu wrote:
> On Thu, Oct 20, 2016 at 1:17 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > So here is my RFC as an alternative. Thoughts? Please note that we
> > currently have only very few users of use_mm() API in the kernel
> > so a risk of a regression is not really high. usb/gadget are using it
> > only temporarily. The remaining is vhost which operates on a remote mm
> > and I have no idea whether somebody might abuse /proc/vhost/mem or
> > anything - let's add Michael to the CC list. I am pretty sure nobody
> > abuse oom_reaper proc directory as this one is pretty new and such a
> > usage would be pretty much undefined as the reaper unmaps the address
> > space.
> 
> With this patch I cannot tell the difference between a) the thread is
> exiting and b) it's a kernel thread,
> besides, getting "no such process" while the kthread does exist is a
> bit confusing.

Do we really need to distinguish those two cases? In other words under
which conditions something would fail when seeing a pid directory and
ESRCH when opening a file?

> IMO, reading /proc/<kthread_pid>/auxv and getting empty output are
> quite straightforward,
> it doesn't seem to be that "abusive".

Then we need to teach all those implementations to check for kthread
explicitly and return an empty output rather than relying on mm == NULL
because that, as explained, might belong to some process.

-- 
Michal Hocko
SUSE Labs