From: David Laight <David.Laight@ACULAB.COM>
To: 'Thomas Bogendoerfer' <tsbogend@alpha.franken.de>,
Jinyang He <hejinyang@loongson.cn>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] MIPS: Fix strnlen_user access check
Date: Tue, 13 Apr 2021 12:37:25 +0000 [thread overview]
Message-ID: <069e524dbad2412f9e74fd234f40fff5@AcuMS.aculab.com> (raw)
In-Reply-To: <20210413111438.GA9472@alpha.franken.de>
From: Thomas Bogendoerfer <tsbogend@alpha.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.
There is also the question about why this makes any difference
to the original problem of logging in via the graphical interface.
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.
It might be that it is passing 'huge' to do strlen_user().
But since the remove set_fs() changes are reported to have
broken it, was it actually being called for a kernel buffer?
There is more going on here.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-04-13 12:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-11 11:04 Jinyang He
2021-04-12 3:02 ` Tiezhu Yang
2021-04-12 6:06 ` Jinyang He
2021-04-12 7:08 ` Tiezhu Yang
2021-04-12 14:27 ` Thomas Bogendoerfer
2021-04-13 1:15 ` Jinyang He
2021-04-13 8:34 ` David Laight
2021-04-13 11:14 ` Thomas Bogendoerfer
2021-04-13 12:37 ` David Laight [this message]
2021-04-13 15:19 ` Thomas Bogendoerfer
2021-04-13 16:01 ` David Laight
2021-04-14 7:59 ` Thomas Bogendoerfer
2021-04-12 13:47 ` Jinyang He
2021-04-15 21:26 Thomas Bogendoerfer
2021-04-16 7:22 ` Thomas Bogendoerfer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=069e524dbad2412f9e74fd234f40fff5@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=hejinyang@loongson.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=yangtiezhu@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®