linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RESEND] get_fs_type: Validate fs type string argument
@ 2018-11-20  5:36 Chandan Rajendra
  2018-11-20  5:44 ` Chandan Rajendra
  2019-01-21 12:20 ` Miklos Szeredi
  0 siblings, 2 replies; 4+ messages in thread
From: Chandan Rajendra @ 2018-11-20  5:36 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: Chandan Rajendra, viro, joe, abdhalee

On ppc64le, When a string with PAGE_SIZE - 1 (i.e. 64k-1) length is
passed as a "filesystem type" argument to the mount(2) syscall,
copy_mount_string() ends up allocating 64k (the PAGE_SIZE on ppc64le)
worth of space for holding the string in kernel's address space.

Later, in set_precision() (invoked by get_fs_type() ->
__request_module() -> vsnprintf()), we end up assigning
strlen(fs-type-string) i.e. 65535 as the
value to 'struct printf_spec'->precision member. This field has a width
of 16 bits and it is a signed data type. Hence an invalid value ends
up getting assigned. This causes the "WARN_ONCE(spec->precision != prec,
"precision %d too large", prec)" statement inside set_precision() to be
executed.

This commit fixes the bug by validating the length of the "filesystem
type" argument passed to get_fs_type() function.

Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Suggested-by: Joe Perches <joe@perches.com>
---
 fs/filesystems.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/filesystems.c b/fs/filesystems.c
index 9135646e41ac..a61caf5b6ad3 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -268,6 +268,9 @@ struct file_system_type *get_fs_type(const char *name)
 	const char *dot = strchr(name, '.');
 	int len = dot ? dot - name : strlen(name);
 
+	if (len >= PATH_MAX)
+		return NULL;
+
 	fs = __get_fs_type(name, len);
 	if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
 		fs = __get_fs_type(name, len);
-- 
2.19.1

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] get_fs_type: Validate fs type string argument
  2018-11-20  5:36 [PATCH RESEND] get_fs_type: Validate fs type string argument Chandan Rajendra
@ 2018-11-20  5:44 ` Chandan Rajendra
  2019-01-21 12:20 ` Miklos Szeredi
  1 sibling, 0 replies; 4+ messages in thread
From: Chandan Rajendra @ 2018-11-20  5:44 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: viro, joe, abdhalee

On Tuesday, November 20, 2018 11:06:42 AM IST Chandan Rajendra wrote:
> On ppc64le, When a string with PAGE_SIZE - 1 (i.e. 64k-1) length is
> passed as a "filesystem type" argument to the mount(2) syscall,
> copy_mount_string() ends up allocating 64k (the PAGE_SIZE on ppc64le)
> worth of space for holding the string in kernel's address space.
> 
> Later, in set_precision() (invoked by get_fs_type() ->
> __request_module() -> vsnprintf()), we end up assigning
> strlen(fs-type-string) i.e. 65535 as the
> value to 'struct printf_spec'->precision member. This field has a width
> of 16 bits and it is a signed data type. Hence an invalid value ends
> up getting assigned. This causes the "WARN_ONCE(spec->precision != prec,
> "precision %d too large", prec)" statement inside set_precision() to be
> executed.
> 
> This commit fixes the bug by validating the length of the "filesystem
> type" argument passed to get_fs_type() function.
>

The following is a trivial userspace program to recreate the issue,

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <sys/mount.h>

#define BUFSIZE 65536

char buf[BUFSIZE];

int main(int argc, char *argv[])
{
        int ret;

        if (argc != 3) {
                fprintf(stderr, "Usage: %s <device> <mount point>.\n", argv[0]);
                exit(1);
        }

        memset(buf, 1, BUFSIZE);

        buf[BUFSIZE-1] = '\0';
        printf("strlen(buf) = %lu.\n", strlen(buf));
        ret = mount(argv[1], argv[2], buf, 0, NULL);
        if (ret) {
                perror("mount");
                exit(0);
        }

        exit(1);
}

-- 
chandan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] get_fs_type: Validate fs type string argument
  2018-11-20  5:36 [PATCH RESEND] get_fs_type: Validate fs type string argument Chandan Rajendra
  2018-11-20  5:44 ` Chandan Rajendra
@ 2019-01-21 12:20 ` Miklos Szeredi
  2019-01-21 21:25   ` Al Viro
  1 sibling, 1 reply; 4+ messages in thread
From: Miklos Szeredi @ 2019-01-21 12:20 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-fsdevel, Chandan Rajendra, joe, abdhalee

On Tue, Nov 20, 2018 at 6:36 AM Chandan Rajendra
<chandan@linux.vnet.ibm.com> wrote:
>
> On ppc64le, When a string with PAGE_SIZE - 1 (i.e. 64k-1) length is
> passed as a "filesystem type" argument to the mount(2) syscall,
> copy_mount_string() ends up allocating 64k (the PAGE_SIZE on ppc64le)
> worth of space for holding the string in kernel's address space.
>
> Later, in set_precision() (invoked by get_fs_type() ->
> __request_module() -> vsnprintf()), we end up assigning
> strlen(fs-type-string) i.e. 65535 as the
> value to 'struct printf_spec'->precision member. This field has a width
> of 16 bits and it is a signed data type. Hence an invalid value ends
> up getting assigned. This causes the "WARN_ONCE(spec->precision != prec,
> "precision %d too large", prec)" statement inside set_precision() to be
> executed.
>
> This commit fixes the bug by validating the length of the "filesystem
> type" argument passed to get_fs_type() function.
>
> Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
> Suggested-by: Joe Perches <joe@perches.com>

Acked-by:  Miklos Szeredi <mszeredi@redhat.com>

Al, please pick this up, it looks like a good sanity check and lack of
it is causing headaches for IBM QA.

Thanks,
Miklos

> ---
>  fs/filesystems.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/fs/filesystems.c b/fs/filesystems.c
> index 9135646e41ac..a61caf5b6ad3 100644
> --- a/fs/filesystems.c
> +++ b/fs/filesystems.c
> @@ -268,6 +268,9 @@ struct file_system_type *get_fs_type(const char *name)
>         const char *dot = strchr(name, '.');
>         int len = dot ? dot - name : strlen(name);
>
> +       if (len >= PATH_MAX)
> +               return NULL;
> +
>         fs = __get_fs_type(name, len);
>         if (!fs && (request_module("fs-%.*s", len, name) == 0)) {
>                 fs = __get_fs_type(name, len);
> --
> 2.19.1
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] get_fs_type: Validate fs type string argument
  2019-01-21 12:20 ` Miklos Szeredi
@ 2019-01-21 21:25   ` Al Viro
  0 siblings, 0 replies; 4+ messages in thread
From: Al Viro @ 2019-01-21 21:25 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: linux-fsdevel, Chandan Rajendra, joe, abdhalee

On Mon, Jan 21, 2019 at 01:20:57PM +0100, Miklos Szeredi wrote:
> On Tue, Nov 20, 2018 at 6:36 AM Chandan Rajendra
> <chandan@linux.vnet.ibm.com> wrote:
> >
> > On ppc64le, When a string with PAGE_SIZE - 1 (i.e. 64k-1) length is
> > passed as a "filesystem type" argument to the mount(2) syscall,
> > copy_mount_string() ends up allocating 64k (the PAGE_SIZE on ppc64le)
> > worth of space for holding the string in kernel's address space.
> >
> > Later, in set_precision() (invoked by get_fs_type() ->
> > __request_module() -> vsnprintf()), we end up assigning
> > strlen(fs-type-string) i.e. 65535 as the
> > value to 'struct printf_spec'->precision member. This field has a width
> > of 16 bits and it is a signed data type. Hence an invalid value ends
> > up getting assigned. This causes the "WARN_ONCE(spec->precision != prec,
> > "precision %d too large", prec)" statement inside set_precision() to be
> > executed.
> >
> > This commit fixes the bug by validating the length of the "filesystem
> > type" argument passed to get_fs_type() function.
> >
> > Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> > Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
> > Suggested-by: Joe Perches <joe@perches.com>
> 
> Acked-by:  Miklos Szeredi <mszeredi@redhat.com>
> 
> Al, please pick this up, it looks like a good sanity check and lack of
> it is causing headaches for IBM QA.

Umm...  I'm not against that patch, but I wonder if that should be caught
earlier...  If nothing else, the same string is seen by LSM shite before
get_fs_type() gets a chance to reject it, and I wouldn't bet a dime on
robustness of that code.  Wouldn't it be saner to have
char *copy_mount_string(const void __user *data)
{
        return data ? strndup_user(data, PAGE_SIZE) : NULL;
}
use a more explicit size limit?  PATH_MAX, for example?

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-01-21 21:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-20  5:36 [PATCH RESEND] get_fs_type: Validate fs type string argument Chandan Rajendra
2018-11-20  5:44 ` Chandan Rajendra
2019-01-21 12:20 ` Miklos Szeredi
2019-01-21 21:25   ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).