From: Al Viro <viro@ZenIV.linux.org.uk>
To: Joe Korty <joe.korty@concurrent.com>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Sasha Levin <alexander.levin@verizon.com>
Subject: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()
Date: Fri, 28 Oct 2016 03:02:10 +0100 [thread overview]
Message-ID: <20161028020210.GL19539@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20161028000355.GK19539@ZenIV.linux.org.uk>
On Fri, Oct 28, 2016 at 01:03:55AM +0100, Al Viro wrote:
> On Thu, Oct 27, 2016 at 03:32:10PM -0400, Joe Korty wrote:
[oops in 4.1.35, bisected to 319fe1151940]
> > The following test program can be used to trigger the problem:
> >
> > /* gcc -m32 c.c -o c */
> > #define _GNU_SOURCE
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <unistd.h>
> > #include <errno.h>
> > #include <sys/syscall.h>
> >
> > #define rt_sigqueueinfo 178
> >
> > int main(int argc, char **argv) {
> > int stat = syscall(rt_sigqueueinfo, 0, 0, 0, 0, 0, 0);
> > printf("syscall(%d): stat: %d, errno: %d\n",
> > rt_sigqueueinfo, stat, errno);
> > return 0;
> > }
> >
> > This is under 4.1.35 on x86_64.
>
> AFAICS, it steps on _ASM_EXTABLE_EX being more brittle in 4.1 - it pretty
> much has to have the handler on the next insn after the faulting one, or
> the resulting extable entry won't be recognized. This
> "x86/mm: Expand the exception table logic to allow new handling options"
> in mainline is where that requirement has disappeared. I think we
> ought to use the plain _ASM_EXTABLE and just call something that would
> set current_thread_info()->uaccess_err directly from the fixup code there.
> That, or backport the commit switching to less brittle extables.
... and frankly, backporting 548acf19234d would be my preference. It's a bit
more intrusive than needed (_ASM_EXTABLE_FAULT is used only in memcpy_mcsafe(),
which is used only by pmem and it's the only reason for passing the trap
number to fixup_exception()), but AFAICS it's fairly safe. Objections?
next prev parent reply other threads:[~2016-10-28 2:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20161027193210.GA23006@zipoli.ccur.com>
2016-10-28 0:03 ` BUGreport: fix minor infoleak in get_user_ex() Al Viro
2016-10-28 2:02 ` Al Viro [this message]
[not found] ` <20161028164033.GA29952@zipoli.ccur.com>
2016-10-28 18:21 ` [4.1 backport trouble] " Linus Torvalds
2016-10-28 19:49 ` Al Viro
2016-10-28 21:29 ` Greg KH
2016-10-28 19:34 ` Al Viro
2016-10-30 18:16 ` Levin, Alexander
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=20161028020210.GL19539@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=alexander.levin@verizon.com \
--cc=joe.korty@concurrent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.