From: Al Viro <viro@zeniv.linux.org.uk>
To: Arthur Gautier <baloo@gandi.net>
Cc: Andy Lutomirski <luto@amacapital.net>,
Thomas Gleixner <tglx@linutronix.de>,
Jann Horn <jannh@google.com>,
the arch/x86 maintainers <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
kernel list <linux-kernel@vger.kernel.org>,
Pascal Bouchareine <pascal@gandi.net>
Subject: Re: [PATCH] x86: uaccess: fix regression in unsafe_get_user
Date: Sun, 17 Feb 2019 04:22:09 +0000 [thread overview]
Message-ID: <20190217042201.GU2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190217034121.bs3q3sgevexmdt3d@khany>
On Sun, Feb 17, 2019 at 03:41:21AM +0000, Arthur Gautier wrote:
> On Sat, Feb 16, 2019 at 11:47:02PM +0000, Al Viro wrote:
> > On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote:
> >
> > > What is the actual problem? We’re not actually demand-faulting this data, are we? Are we just overrunning the buffer because the from_user helpers are too clever? Can we fix it for real by having the fancy helpers do *aligned* loads so that they don’t overrun the buffer? Heck, this might be faster, too.
> >
> > Unaligned _stores_ are not any cheaper, and you'd get one hell of
> > extra arithmetics from trying to avoid both. Check something
> > like e.g. memcpy() on alpha, where you really have to keep all
> > accesses aligned, both on load and on store side.
> >
> > Can't we just pad the buffers a bit? Making sure that name_buf
> > and symlink_buf are _not_ followed by unmapped pages shouldn't
> > be hard. Both are allocated by kmalloc(), so...
>
> We cannot change alignment rules here. The input buffer string we're
> reading is coming from an cpio formated file and the format is
> defined by cpio(5).
> Nothing much we can do there I'm afraid. Input buffer is defined to
> be 4-byte aligned.
Who says anything about changing the format of the file? At least
one trivial way to handle that would be this:
diff --git a/init/initramfs.c b/init/initramfs.c
index 7cea802d00ef..edbddfb73106 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -265,8 +265,12 @@ static int __init do_header(void)
state = Collect;
return 0;
}
- if (S_ISREG(mode) || !body_len)
- read_into(name_buf, N_ALIGN(name_len), GotName);
+ if (S_ISREG(mode) || !body_len) {
+ collect = collected = name_buf;
+ remains = N_ALIGN(name_len);
+ next_state = GotName;
+ state = Collect;
+ }
return 0;
}
Another would be to have the buffer passed to flush_buffer() (i.e.
the callback of decompress_fn) allocated with 4 bytes of padding
past the part where the unpacked piece of data is placed for the
callback to find. As in,
diff --git a/lib/decompress_inflate.c b/lib/decompress_inflate.c
index 63b4b7eee138..ca3f7ecc9b35 100644
--- a/lib/decompress_inflate.c
+++ b/lib/decompress_inflate.c
@@ -48,7 +48,7 @@ STATIC int INIT __gunzip(unsigned char *buf, long len,
rc = -1;
if (flush) {
out_len = 0x8000; /* 32 K */
- out_buf = malloc(out_len);
+ out_buf = malloc(out_len + 4);
} else {
if (!out_len)
out_len = ((size_t)~0) - (size_t)out_buf; /* no limit */
for gunzip/decompress and similar ones for bzip2, etc. The contents
layout doesn't have anything to do with that...
next prev parent reply other threads:[~2019-02-17 4:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 23:59 [PATCH] x86: uaccess: fix regression in unsafe_get_user baloo
2019-02-16 4:20 ` Jann Horn
2019-02-16 20:18 ` Thomas Gleixner
2019-02-16 22:25 ` Thomas Gleixner
2019-02-16 22:50 ` Andy Lutomirski
2019-02-16 22:57 ` Andy Lutomirski
2019-02-16 23:47 ` Al Viro
2019-02-17 0:02 ` Al Viro
2019-02-17 2:36 ` Andy Lutomirski
2019-02-17 3:41 ` Arthur Gautier
2019-02-17 4:22 ` Al Viro [this message]
2019-02-18 13:04 ` Thomas Gleixner
2019-02-18 19:15 ` Andy Lutomirski
2019-02-18 21:13 ` Jann Horn
2019-02-18 21:51 ` Arthur Gautier
2019-09-26 9:58 ` Arthur Gautier
2019-09-26 14:09 ` Borislav Petkov
2019-10-10 16:49 ` Arthur Gautier
2019-11-05 14:11 ` Borislav Petkov
2019-11-05 16:05 ` Arthur Gautier
2019-11-06 0:21 ` Andy Lutomirski
2019-11-06 2:22 ` Arthur Gautier
2019-09-26 14:08 ` Borislav Petkov
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=20190217042201.GU2217@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=baloo@gandi.net \
--cc=bp@alien8.de \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=pascal@gandi.net \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.