Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 28 Apr 2023 18:04:34 -0700 | Subject | Re: [GIT PULL] x86/mm for 6.4 |
| |
On Fri, Apr 28, 2023 at 5:38 PM Kirill A. Shutemov <kirill@shutemov.name> wrote: > > BTW, I think the static check can be relaxed. Checking size against > PAGE_SIZE is rather conservative: there's 8 TB (or 4 PB for 5-level > paging) guard hole at the begging of kernel address space.
So I don't worry about the size per se - we just don't have any constant sized accesses that are bigger than a page.
The constant-sized case is for things like structures being copied to user space.
And having a bug gap is nice for the suzkaller case, although I don't think that GP fault has triggered lately (or ever, I don't remember). Having random system call arguments that trigger "oh, this is in the non-canonical region" is a good thing.
> > So being careful about the range is kind of annoying, when we don't > > really need it. > > Hm. Is there anybody who access high to low after the check (glibc > memcpy() bug flashbacks)? Or not in any particular order?
Yeah, I can't think of a single case, which is why it seems so silly to even bother.
Almost all real life cases end up being limited by things like the page/folio size.
We do have exceptions, like module loading etc that might copy a bigger area from user space, but no, we don't have any backwards copies.
So you'd almost have to have some "access_ok()" followed by random access with a user-controlled offset, and that seems nonsensical and fundamentally impossible anyway.
But just because I can't think of it, and go "that would be insane" doesn't mean that some driver ioctl interface might not try it.
Which is why I think having others look at it would be a good idea.
Linus
| |