Some architectures grand full access to userspace regardless of the
address/len passed to user_access_begin(), but other architectures
only grand access to the requested area.
For exemple, on 32 bits powerpc (book3s/32), access is granted by
segments of 256 Mbytes.
Modify filldir() and filldir64() to request the real area they need
to get access to, i.e. the area covering the parent dirent (if any)
and the contiguous current dirent.
Fixes: 9f79b78ef744 ("Convert filldir[64]() from __put_user() to unsafe_put_user()")
Signed-off-by: Christophe Leroy <[email protected]>
---
v2: have user_access_begin() cover both parent dirent (if any) and current dirent
---
fs/readdir.c | 50 ++++++++++++++++++++++++++++----------------------
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/fs/readdir.c b/fs/readdir.c
index d26d5ea4de7b..3f9b4488d9b7 100644
--- a/fs/readdir.c
+++ b/fs/readdir.c
@@ -214,7 +214,7 @@ struct getdents_callback {
static int filldir(struct dir_context *ctx, const char *name, int namlen,
loff_t offset, u64 ino, unsigned int d_type)
{
- struct linux_dirent __user * dirent;
+ struct linux_dirent __user * dirent, *dirent0;
struct getdents_callback *buf =
container_of(ctx, struct getdents_callback, ctx);
unsigned long d_ino;
@@ -232,19 +232,22 @@ static int filldir(struct dir_context *ctx, const char *name, int namlen,
buf->error = -EOVERFLOW;
return -EOVERFLOW;
}
- dirent = buf->previous;
- if (dirent && signal_pending(current))
+ dirent0 = buf->previous;
+ if (dirent0 && signal_pending(current))
return -EINTR;
- /*
- * Note! This range-checks 'previous' (which may be NULL).
- * The real range was checked in getdents
- */
- if (!user_access_begin(dirent, sizeof(*dirent)))
- goto efault;
- if (dirent)
- unsafe_put_user(offset, &dirent->d_off, efault_end);
dirent = buf->current_dir;
+ if (dirent0) {
+ int sz = (void __user *)dirent + reclen -
+ (void __user *)dirent0;
+
+ if (!user_access_begin(dirent0, sz))
+ goto efault;
+ unsafe_put_user(offset, &dirent0->d_off, efault_end);
+ } else {
+ if (!user_access_begin(dirent, reclen))
+ goto efault;
+ }
unsafe_put_user(d_ino, &dirent->d_ino, efault_end);
unsafe_put_user(reclen, &dirent->d_reclen, efault_end);
unsafe_put_user(d_type, (char __user *) dirent + reclen - 1, efault_end);
@@ -307,7 +310,7 @@ struct getdents_callback64 {
static int filldir64(struct dir_context *ctx, const char *name, int namlen,
loff_t offset, u64 ino, unsigned int d_type)
{
- struct linux_dirent64 __user *dirent;
+ struct linux_dirent64 __user *dirent, *dirent0;
struct getdents_callback64 *buf =
container_of(ctx, struct getdents_callback64, ctx);
int reclen = ALIGN(offsetof(struct linux_dirent64, d_name) + namlen + 1,
@@ -319,19 +322,22 @@ static int filldir64(struct dir_context *ctx, const char *name, int namlen,
buf->error = -EINVAL; /* only used if we fail.. */
if (reclen > buf->count)
return -EINVAL;
- dirent = buf->previous;
- if (dirent && signal_pending(current))
+ dirent0 = buf->previous;
+ if (dirent0 && signal_pending(current))
return -EINTR;
- /*
- * Note! This range-checks 'previous' (which may be NULL).
- * The real range was checked in getdents
- */
- if (!user_access_begin(dirent, sizeof(*dirent)))
- goto efault;
- if (dirent)
- unsafe_put_user(offset, &dirent->d_off, efault_end);
dirent = buf->current_dir;
+ if (dirent0) {
+ int sz = (void __user *)dirent + reclen -
+ (void __user *)dirent0;
+
+ if (!user_access_begin(dirent0, sz))
+ goto efault;
+ unsafe_put_user(offset, &dirent0->d_off, efault_end);
+ } else {
+ if (!user_access_begin(dirent, reclen))
+ goto efault;
+ }
unsafe_put_user(ino, &dirent->d_ino, efault_end);
unsafe_put_user(reclen, &dirent->d_reclen, efault_end);
unsafe_put_user(d_type, &dirent->d_type, efault_end);
--
2.25.0
On Wed, Jan 22, 2020 at 10:24 AM Linus Torvalds
<[email protected]> wrote:
>
> Patch looks better, but those names are horrid.
Hmm.
A bit more re-organization also allows us to do the unsafe_put_user()
unconditionally.
In particular, if we remove 'previous' as a pointer from the filldir
data structure, and replace it with 'prev_reclen', then we can do
prev_reclen = buf->prev_reclen;
dirent = buf->current_dir;
prev = (void __user *) dirent - prev_reclen;
if (!user_access_begin(prev, reclen + prev_reclen))
goto efault;
and instead of checking that 'previous' pointer for NULL, we just
check prev_reclen for not being zero.
Yes, it replaces a few other
lastdirent = buf.previous;
with the slightly more complicated
lastdirent = (void __user *)buf.current_dir - buf.prev_reclen;
but on the whole it makes the _important_ code more streamlined, and
avoids having to have those if-else cases.
Something like the attached.
COMPLETELY UNTESTED! It compiles for me. The generated assembly looks
ok from a quick look.
Christophe, does this work for you on your ppc test-case?
Side note: I think verify_dirent_name() should check that 'len' is in
the appropriate range too, because right now a corrupted filesystem is
only noticed for a zero length. But a negative one, or one where the
reclen calculations would overflow, is not noticed.
Most filesystems have the source of 'len' being something like an
'unsigned char' so that it's pretty bounded anyway, which is likely
why nobody cared when we added that check, but..
Linus
On Wed, Jan 22, 2020 at 12:00 PM Linus Torvalds
<[email protected]> wrote:
>
> A bit more re-organization also allows us to do the unsafe_put_user()
> unconditionally.
I meant the "user_access_begin()", of course.
Code was right, explanation was wrong.
That said, with this model, we _could_ make the
unsafe_put_user(offset, &prev->d_off, efault_end);
be unconditional too, since now 'prev' will actually be a valid
pointer - it will match 'dirent' if there was no prev.
But since we want to test whether we had a previous entry anyway (for
the signal handling latency issue), making the write to the previous
d_reclen unconditional (and then overwriting it the next iteration)
doesn't actually buy us anything.
It was the user_access_begin() I'd rather have unconditional, since
otherwise it gets duplicated in two (very slightly) different versions
and we have unnecessary code bloat.
Linus
[ Talking to myself ]
On Wed, Jan 22, 2020 at 12:00 PM Linus Torvalds
<[email protected]> wrote:
>
> COMPLETELY UNTESTED! It compiles for me. The generated assembly looks
> ok from a quick look.
Some more testing shows that objtool is unhappy about how we do that
signal_pending(current) inside the user access region.
I didn't notice because my test builds were with sane kernel
configurations so that I could look at the generated code.
But with KASAN enabled, the signal check causes accesses that KASAN
wants to check, and I get
objtool: filldir()+0x395: call to __kasan_check_read() with UACCESS enabled
warnings.
So that patch of mine isn't acceptable for silly reasons, and the
signal check itself would need to be done outside of the user access
area.
That actually makes the whole "let's do the &prev->d_off setting
unconditionally" much more interesting.
So here's a slightly updated patch that does exactly that, and avoids
the objtool warning.
It actually generates better code than the last one too, because now
we don't duplicate the user_access_end() for the EINTR case.
So test this one instead, please.
Linus
Le 22/01/2020 à 21:37, Linus Torvalds a écrit :
> [ Talking to myself ]
>
> On Wed, Jan 22, 2020 at 12:00 PM Linus Torvalds
> <[email protected]> wrote:
>>
>> COMPLETELY UNTESTED! It compiles for me. The generated assembly looks
>> ok from a quick look.
>
>
> So here's a slightly updated patch that does exactly that, and avoids
> the objtool warning.
>
> It actually generates better code than the last one too, because now
> we don't duplicate the user_access_end() for the EINTR case.
>
> So test this one instead, please.
This patch works on my ppc board, thanks
Christophe
Hi Christophe,
This patch is independent of the rest of the series AFAICS, and it looks
like Linus has modified it quite a bit down thread.
So I'll take patches 2-6 via powerpc and assume this patch will go via
Linus or Al or elsewhere.
Also a couple of minor spelling fixes below.
cheers
Christophe Leroy <[email protected]> writes:
> Some architectures grand full access to userspace regardless of the
^
grant
> address/len passed to user_access_begin(), but other architectures
> only grand access to the requested area.
^
grant
>
> For exemple, on 32 bits powerpc (book3s/32), access is granted by
^
example
> segments of 256 Mbytes.
>
> Modify filldir() and filldir64() to request the real area they need
> to get access to, i.e. the area covering the parent dirent (if any)
> and the contiguous current dirent.
>
> Fixes: 9f79b78ef744 ("Convert filldir[64]() from __put_user() to unsafe_put_user()")
> Signed-off-by: Christophe Leroy <[email protected]>
> ---
> v2: have user_access_begin() cover both parent dirent (if any) and current dirent
> ---
> fs/readdir.c | 50 ++++++++++++++++++++++++++++----------------------
> 1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/fs/readdir.c b/fs/readdir.c
> index d26d5ea4de7b..3f9b4488d9b7 100644
> --- a/fs/readdir.c
> +++ b/fs/readdir.c
> @@ -214,7 +214,7 @@ struct getdents_callback {
> static int filldir(struct dir_context *ctx, const char *name, int namlen,
> loff_t offset, u64 ino, unsigned int d_type)
> {
> - struct linux_dirent __user * dirent;
> + struct linux_dirent __user * dirent, *dirent0;
> struct getdents_callback *buf =
> container_of(ctx, struct getdents_callback, ctx);
> unsigned long d_ino;
> @@ -232,19 +232,22 @@ static int filldir(struct dir_context *ctx, const char *name, int namlen,
> buf->error = -EOVERFLOW;
> return -EOVERFLOW;
> }
> - dirent = buf->previous;
> - if (dirent && signal_pending(current))
> + dirent0 = buf->previous;
> + if (dirent0 && signal_pending(current))
> return -EINTR;
>
> - /*
> - * Note! This range-checks 'previous' (which may be NULL).
> - * The real range was checked in getdents
> - */
> - if (!user_access_begin(dirent, sizeof(*dirent)))
> - goto efault;
> - if (dirent)
> - unsafe_put_user(offset, &dirent->d_off, efault_end);
> dirent = buf->current_dir;
> + if (dirent0) {
> + int sz = (void __user *)dirent + reclen -
> + (void __user *)dirent0;
> +
> + if (!user_access_begin(dirent0, sz))
> + goto efault;
> + unsafe_put_user(offset, &dirent0->d_off, efault_end);
> + } else {
> + if (!user_access_begin(dirent, reclen))
> + goto efault;
> + }
> unsafe_put_user(d_ino, &dirent->d_ino, efault_end);
> unsafe_put_user(reclen, &dirent->d_reclen, efault_end);
> unsafe_put_user(d_type, (char __user *) dirent + reclen - 1, efault_end);
> @@ -307,7 +310,7 @@ struct getdents_callback64 {
> static int filldir64(struct dir_context *ctx, const char *name, int namlen,
> loff_t offset, u64 ino, unsigned int d_type)
> {
> - struct linux_dirent64 __user *dirent;
> + struct linux_dirent64 __user *dirent, *dirent0;
> struct getdents_callback64 *buf =
> container_of(ctx, struct getdents_callback64, ctx);
> int reclen = ALIGN(offsetof(struct linux_dirent64, d_name) + namlen + 1,
> @@ -319,19 +322,22 @@ static int filldir64(struct dir_context *ctx, const char *name, int namlen,
> buf->error = -EINVAL; /* only used if we fail.. */
> if (reclen > buf->count)
> return -EINVAL;
> - dirent = buf->previous;
> - if (dirent && signal_pending(current))
> + dirent0 = buf->previous;
> + if (dirent0 && signal_pending(current))
> return -EINTR;
>
> - /*
> - * Note! This range-checks 'previous' (which may be NULL).
> - * The real range was checked in getdents
> - */
> - if (!user_access_begin(dirent, sizeof(*dirent)))
> - goto efault;
> - if (dirent)
> - unsafe_put_user(offset, &dirent->d_off, efault_end);
> dirent = buf->current_dir;
> + if (dirent0) {
> + int sz = (void __user *)dirent + reclen -
> + (void __user *)dirent0;
> +
> + if (!user_access_begin(dirent0, sz))
> + goto efault;
> + unsafe_put_user(offset, &dirent0->d_off, efault_end);
> + } else {
> + if (!user_access_begin(dirent, reclen))
> + goto efault;
> + }
> unsafe_put_user(ino, &dirent->d_ino, efault_end);
> unsafe_put_user(reclen, &dirent->d_reclen, efault_end);
> unsafe_put_user(d_type, &dirent->d_type, efault_end);
> --
> 2.25.0
Michael Ellerman <[email protected]> writes:
> Hi Christophe,
>
> This patch is independent of the rest of the series AFAICS
And of course having hit send I immediately realise that's not true.
> So I'll take patches 2-6 via powerpc and assume this patch will go via
> Linus or Al or elsewhere.
So I guess I'll wait and see what happens with patch 1.
cheers
Le 23/01/2020 à 13:00, Michael Ellerman a écrit :
> Michael Ellerman <[email protected]> writes:
>> Hi Christophe,
>>
>> This patch is independent of the rest of the series AFAICS
>
> And of course having hit send I immediately realise that's not true.
Without this, book3s/32 fails booting. (And without patch 2, it even
hangs, looping forever in do_page_fault()).
>
>> So I'll take patches 2-6 via powerpc and assume this patch will go via
>> Linus or Al or elsewhere.
>
> So I guess I'll wait and see what happens with patch 1.
We could eventually opt out user_access_begin() for
CONFIG_PPC_BOOK3S_32, then you could take patches 3 and 6. That's enough
to have user_access_begin() and stuff for 8xx and RADIX.
Patch 2 should be taken as well as a fix, and can be kept independant of
the series (once we have patch 1, we normally don't hit the problem
fixed by patch 2).
Won't don't need patch 4 until we want user_access_begin() supported by
book3s/32
However, I'm about to send out a v3 with a different approach. It
modifies the core part where user_access_begin() is returning an opaque
value used by user_access_end(). And it also tells user_access_begin()
whether it's a read or a write, so that we can limit unlocking to write
acccesses on book3s/32, and fine grain rights on book3s/64.
Maybe you would prefer this change on top of first step, in which case
I'll be able to make a v4 rebasing all this on top of patch 3 and 6 of
v3 series. Tell me what you prefer.
Christophe
On Thu, Jan 23, 2020 at 4:00 AM Michael Ellerman <[email protected]> wrote:
>
> So I guess I'll wait and see what happens with patch 1.
I've committed my fixes to filldir[64]() directly - they really were
fixing me being lazy about the range, and the name length checking
really is a theoretical "access wrong user space pointer" issue with
corrupted filesystems regardless (even though I suspect it's entirely
theoretical - even a corrupt filesystem hopefully won't be passing in
negative directory entry lengths or something like that).
The "pass in read/write" part I'm not entirely convinced about.
Honestly, if this is just for ppc32 and nobody else really needs it,
make the ppc32s thing always just enable both user space reads and
writes. That's the semantics for x86 and arm as is, I'm not convinced
that we should complicate this for a legacy platform.
Linus
Linus Torvalds <[email protected]> writes:
> On Thu, Jan 23, 2020 at 4:00 AM Michael Ellerman <[email protected]> wrote:
>>
>> So I guess I'll wait and see what happens with patch 1.
>
> I've committed my fixes to filldir[64]() directly - they really were
> fixing me being lazy about the range, and the name length checking
> really is a theoretical "access wrong user space pointer" issue with
> corrupted filesystems regardless (even though I suspect it's entirely
> theoretical - even a corrupt filesystem hopefully won't be passing in
> negative directory entry lengths or something like that).
Great, thanks.
> The "pass in read/write" part I'm not entirely convinced about.
> Honestly, if this is just for ppc32 and nobody else really needs it,
> make the ppc32s thing always just enable both user space reads and
> writes. That's the semantics for x86 and arm as is, I'm not convinced
> that we should complicate this for a legacy platform.
We can use the read/write info on Power9 too. That's a niche platform
but hopefully not legacy status yet :P
But it's entirely optional, as you say we can just enable read/write if
we aren't passed the read/write info from the upper-level API.
I think our priority should be getting objtool going on powerpc to check
our user access regions are well contained. Once we have that working
maybe then we can look at plumbing the direction through
user_access_begin() etc.
cheers