Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 15 Mar 2021 15:54:50 +0300
From:   Cyrill Gorcunov <gorcunov@gmail.com>
To:     Oleg Nesterov <oleg@redhat.com>
Cc:     Alexey Dobriyan <adobriyan@gmail.com>, akpm@linux-foundation.org,
        linux-kernel@vger.kernel.org, security@kernel.org
Subject: Re: [PATCH] prctl: fix PR_SET_MM_AUXV kernel stack leak
Message-ID: <YE9ZGl9jlnDz1OBP@grain>
References: <YE53QiJuxsCUeoiu@localhost.localdomain>
 <20210315120803.GA13620@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210315120803.GA13620@redhat.com>
User-Agent: Mutt/2.0.5 (2021-01-21)
Precedence: bulk

On Mon, Mar 15, 2021 at 01:08:03PM +0100, Oleg Nesterov wrote:
> On 03/14, Alexey Dobriyan wrote:
> >
> > 	prctl(PR_SET_MM, PR_SET_MM_AUXV, addr, 1);
> >
> > will copy 1 byte from userspace to (quite big) on-stack array
> > and then stash everything to mm->saved_auxv.
> 
> I too don't understand, memcpy(mm->saved_auxv, user_auxv, len) will
> copy 1 byte...

Indeed. I overlooked that we pass @len when copying. I should
not reply at night :(

> 
> And why task_lock(current) ? What does it try to protect?

As far as I remember this was related to reading from procfs
at time the patch was written for first time. Looks like this
not relevant anymore and could be dropped.