Re: WARNING in ex_handler_uaccess
From: Al Viro
Date: Fri Sep 18 2020 - 20:17:26 EST
On Fri, Sep 18, 2020 at 05:07:43PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 18, 2020 at 4:55 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, Sep 18, 2020 at 04:31:33PM -0700, Andy Lutomirski wrote:
> > > check_zeroed_user() looks buggy. It does:
> > >
> > > if (!user_access_begin(from, size))
> > > return -EFAULT;
> > >
> > > unsafe_get_user(val, (unsigned long __user *) from, err_fault);
> > >
> > > This is wrong if size < sizeof(unsigned long) -- you read outside the
> > > area you verified using user_access_begin().
> > Read the code immediately prior to that. from will be word-aligned,
> > and size will be extended accordingly. If the area acceptable for
> > user_access_begin() ends *NOT* on a word boundary, you have a problem
> > and I would strongly recommend to seek professional help.
> > All reads in that thing are word-aligned and word-sized. So I very
> > much doubt that your analysis is correct.
> Maybe -ETOOTIRED, but I seriously question the math in here. Suppose
> from == (unsigned long *)1 and size == 1. Then align is 1, and we do:
> from -= align;
> size += align;
> So now from = 0 and size = 2. Now we do user_access_begin(0, 2) and
> then immediately read 4 or 8 bytes. No good.
Could you explain what kind of insane hardware manages to do #PF-related
checks (including SMAP, whatever) with *sub*WORD* granularity?
If it's OK with 16bit read from word-aligned address, but barfs on 64bit
one... I want to know what the hell had its authors been smoking.