linux-kernel - RE: WARNING in ex_handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <40d7cc7127084d96a8654993a91b68f4@AcuMS.aculab.com>
Date:   Sat, 19 Sep 2020 15:37:12 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Al Viro' <viro@...iv.linux.org.uk>,
        Andy Lutomirski <luto@...nel.org>
CC:     syzbot <syzbot+ea3a78a71705faf41d77@...kaller.appspotmail.com>,
        "Aleksa Sarai" <cyphar@...har.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        Thomas Gleixner <tglx@...utronix.de>, "X86 ML" <x86@...nel.org>
Subject: RE: WARNING in ex_handler_uaccess

From: Al Viro
> Sent: 19 September 2020 01:17
> 
> 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@...iv.linux.org.uk> 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.

Not going to happen to anything in the data cache. But...

Byte parity errors on memory locations that have never been written
but power-up initialised to 'bad parity'?

I have seen that - but I've completely forgotten the hardware.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)