On Tue, Apr 13, 2021 at 12:37:25PM +0000, David Laight wrote: > From: Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx> > > 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@xxxxxxxx/ > > > > 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. > 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. > ISTM that it is very unlikely that the length passed to strnlen_user() > is long enough to take potential buffer beyond the end of user > address space. see above. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
