* [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).