linux-kernel - Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user

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-next>] [day] [month] [year] [list]

Date:   Fri, 28 Oct 2016 11:21:24 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Joe Korty <joe.korty@...r.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sasha Levin <alexander.levin@...izon.com>,
        stable <stable@...r.kernel.org>
Subject: Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

 rea

On Fri, Oct 28, 2016 at 9:40 AM, Joe Korty <joe.korty@...current.com> wrote:
>
> Backporting 548acf19234d to 4.1.35 does indeed fix the
> issue.  However, it is not clear to my _why_ it works,
> so it might be better that someone else push the backport
> to stable.

The problem is that the old _ASM_EXTABLE_EXT hackery ends up being
this code in fixup_exception() back in 4.1 (and later).

                if (fixup->fixup - fixup->insn >= 0x7ffffff0 - 4) {
                        /* Special hack for uaccess_err */
                        current_thread_info()->uaccess_err = 1;
                        new_ip -= 0x7ffffff0;
                }

and it really does depend very intimately on the relationship with the
"fixup" address (fixup->fixup) with the instruction that took the
fault (fixup->insn).

Now, back in the original 4.1 days, that fixup-vs-insn relationship
was trivially always the case, since __get_user_asm_ex() always just
made the fixup be to fall through to the next instruction.

However, when commit 1c109fabbd51 ("fix minor infoleak in
get_user_ex()") was backported, now the fixup for __get_user_asm_ex()
ends up being in a different section entirely (".section .fixup"), and
the close relationship between the faulting instruction and the fixup
instruction went away.

End result: commit 1c109fabbd51lly effectively and very subtly depends
on commit 548acf19234d (introduced in v4.6) that gets rid of the
special hack.

Adding "stable" to the cc, because this might well affect other stable
backports than 4.1.

End result: either commit 1c109fabbd51 shouldn't be backported (it's
really not that important - if people properly check the exception
error results it shouldn't matter), or you need to also backport
548acf19234d as Al suggested.

I'd be inclined to say "don't backport 1c109fabbd51", but it's really
a judgment call.

           Linus