On Tue, Mar 16, 2021 at 09:50:35PM +0300, Alexey Dobriyan wrote:
> > >
> > > There is another (non-security) one. Compat 32-bit process will report
> > > 2 longs too many:
> >
> > Good catch! Alexey, should I address it? Or you have fixed it already?
>
> I didn't and I don't know how frankly.
>
On Mon, Mar 15, 2021 at 09:42:47AM +0300, Cyrill Gorcunov wrote:
> On Mon, Mar 15, 2021 at 09:00:00AM +0300, Alexey Dobriyan wrote:
> > On Sun, Mar 14, 2021 at 02:40:05PM -0700, Linus Torvalds wrote:
> > > [mm->saved_auxv]
> > >
> > > That's a separate issue, and I can't find it in myself to care
On Mon, Mar 15, 2021 at 02:19:12PM +0100, Oleg Nesterov wrote:
> > >
> > > 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
On Mon, Mar 15, 2021 at 01:29:02PM +0300, Dan Carpenter wrote:
> On Sun, Mar 14, 2021 at 11:51:14PM +0300, 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
On 03/15, Cyrill Gorcunov wrote:
>
> On Mon, Mar 15, 2021 at 01:08:03PM +0100, Oleg Nesterov wrote:
>
> >
> > 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
>
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
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...
And why
On Sun, Mar 14, 2021 at 11:51:14PM +0300, 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.
What? It won't save everything, only the 1 byte. What am I not
On Mon, Mar 15, 2021 at 09:00:00AM +0300, Alexey Dobriyan wrote:
> On Sun, Mar 14, 2021 at 02:40:05PM -0700, Linus Torvalds wrote:
> > [mm->saved_auxv]
> >
> > That's a separate issue, and I can't find it in myself to care (and
> > nobody has ever complained), but I thought I'd mention it.
>
>
On Sun, Mar 14, 2021 at 02:40:05PM -0700, Linus Torvalds wrote:
> [mm->saved_auxv]
>
> That's a separate issue, and I can't find it in myself to care (and
> nobody has ever complained), but I thought I'd mention it.
There is another (non-security) one. Compat 32-bit process will report
2 longs
On Sun, Mar 14, 2021 at 02:40:05PM -0700, Linus Torvalds wrote:
> Applied directly, since I'm just about to tag rc3 and was just looking
> that there were no last-minute pull requests.
>
> Andrew, no need to pick it up into your queue.
>
> Side note: I think we should return -EINVAL more
On Sun, Mar 14, 2021 at 11:51:14PM +0300, 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.
> AT_NULL terminator will be inserted at the very end.
>
>
Applied directly, since I'm just about to tag rc3 and was just looking
that there were no last-minute pull requests.
Andrew, no need to pick it up into your queue.
Side note: I think we should return -EINVAL more aggressively: right
now we fill up potentially all of user_auxv[] and return
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.
AT_NULL terminator will be inserted at the very end.
/proc/*/auxv handler will find that AT_NULL terminator
and copy original stack
14 matches
Mail list logo
