[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2d2980ede424038ac0e1e5184857407@AcuMS.aculab.com>
Date: Tue, 13 Apr 2021 16:01:13 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Thomas Bogendoerfer' <tsbogend@...ha.franken.de>
CC: Jinyang He <hejinyang@...ngson.cn>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] MIPS: Fix strnlen_user access check
From: Thomas Bogendoerfer
> Sent: 13 April 2021 16:19
>
> On Tue, Apr 13, 2021 at 12:37:25PM +0000, David Laight wrote:
> > From: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
> > > Sent: 13 April 2021 12:15
> > ...
> > > > The __access_ok() is noted with `Ensure that the range [addr, addr+size)
> > > > is within the process's address space`. Does the range checked by
> > > > __access_ok() on MIPS is [addr, addr+size]. So if we want to use
> > > > access_ok(s, 1), should we modify __access_ok()? Or my misunderstanding?
> > >
> > > you are right, I'm going to apply
> > >
> > > https://patchwork.kernel.org/project/linux-mips/patch/20190209194718.1294-1-paul.burton@mips.com/
> > >
> > > to fix that.
> >
> > Isn't that still wrong?
> > If an application does:
> > write(fd, (void *)0xffff0000, 0);
> > it should return 0, not -1 and EFAULT/SIGSEGV.
>
> WRITE(2) Linux Programmer's Manual WRITE(2)
> [...]
> If count is zero and fd refers to a regular file, then write() may
> return a failure status if one of the errors below is detected. If no
> errors are detected, or error detection is not performed, 0 will be
> returned without causing any other effect. If count is zero and fd
> refers to a file other than a regular file, the results are not speci-
> fied.
> [...]
> EFAULT buf is outside your accessible address space.
>
> at least it's covered by the man page on my Linux system.
Something related definitely caused grief in the setsockopt() changes.
> > There is also the question about why this makes any difference
> > to the original problem of logging in via the graphical interface.
>
> kernel/module.c: mod->args = strndup_user(uargs, ~0UL >> 1);
>
> and strndup_user does a strnlen_user.
That call is just gross.
Why did it work before the removal of set_fs() etc.
Or was there another change that affected strndup_user() ?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists