[PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Kees Cook]

The sysfs interface to seq_file continues to be rather fragile
(seq_get_buf() should not be used outside of seq_file), as seen with
some recent exploits[1]. Move the seq_file buffer to the vmap area
(while retaining the accounting flag), since it has guard pages that
will catch and stop linear overflows. This seems justified given that
sysfs's use of seq_file already uses kvmalloc(), is almost always using
a PAGE_SIZE or larger allocation, has normally short-lived allocations,
and is not normally on a performance critical path.

Once seq_get_buf() has been removed (and all sysfs callbacks using
seq_file directly), this change can also be removed.

[1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html

Signed-off-by: Kees Cook <keescook@chromium.org>
---
v3:
- Limit to only sysfs (instead of all of seq_file).
v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
---
 fs/sysfs/file.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 9aefa7779b29..70e7a450e5d1 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -16,6 +16,7 @@
 #include <linux/mutex.h>
 #include <linux/seq_file.h>
 #include <linux/mm.h>
+#include <linux/vmalloc.h>
 
 #include "sysfs.h"
 
@@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
 	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
 }
 
+/*
+ * To be proactively defensive against sysfs show() handlers that do not
+ * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
+ * the trailing guard page which will stop linear buffer overflows.
+ */
+static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
+{
+	struct kernfs_open_file *of = sf->private;
+	struct kernfs_node *kn = of->kn;
+
+	WARN_ON_ONCE(sf->buf);
+	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
+	if (!sf->buf)
+		return ERR_PTR(-ENOMEM);
+	sf->size = kn->attr.size;
+
+	return NULL + !*ppos;
+}
+
 /*
  * Reads on sysfs are handled through seq_file, which takes care of hairy
  * details like buffering and seeking.  The following function pipes
@@ -206,14 +226,17 @@ static const struct kernfs_ops sysfs_file_kfops_empty = {
 };
 
 static const struct kernfs_ops sysfs_file_kfops_ro = {
+	.seq_start	= sysfs_kf_seq_start,
 	.seq_show	= sysfs_kf_seq_show,
 };
 
 static const struct kernfs_ops sysfs_file_kfops_wo = {
+	.seq_start	= sysfs_kf_seq_start,
 	.write		= sysfs_kf_write,
 };
 
 static const struct kernfs_ops sysfs_file_kfops_rw = {
+	.seq_start	= sysfs_kf_seq_start,
 	.seq_show	= sysfs_kf_seq_show,
 	.write		= sysfs_kf_write,
 };
-- 
2.25.1

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Greg Kroah-Hartman]

On Wed, Mar 31, 2021 at 07:21:45PM -0700, Kees Cook wrote:
> The sysfs interface to seq_file continues to be rather fragile
> (seq_get_buf() should not be used outside of seq_file), as seen with
> some recent exploits[1]. Move the seq_file buffer to the vmap area
> (while retaining the accounting flag), since it has guard pages that
> will catch and stop linear overflows. This seems justified given that
> sysfs's use of seq_file already uses kvmalloc(), is almost always using
> a PAGE_SIZE or larger allocation, has normally short-lived allocations,
> and is not normally on a performance critical path.
> 
> Once seq_get_buf() has been removed (and all sysfs callbacks using
> seq_file directly), this change can also be removed.
> 
> [1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> v3:
> - Limit to only sysfs (instead of all of seq_file).
> v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
> v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
> ---
>  fs/sysfs/file.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 9aefa7779b29..70e7a450e5d1 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -16,6 +16,7 @@
>  #include <linux/mutex.h>
>  #include <linux/seq_file.h>
>  #include <linux/mm.h>
> +#include <linux/vmalloc.h>
>  
>  #include "sysfs.h"
>  
> @@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
>  	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
>  }
>  
> +/*
> + * To be proactively defensive against sysfs show() handlers that do not
> + * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
> + * the trailing guard page which will stop linear buffer overflows.
> + */
> +static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
> +{
> +	struct kernfs_open_file *of = sf->private;
> +	struct kernfs_node *kn = of->kn;
> +
> +	WARN_ON_ONCE(sf->buf);

How can buf ever not be NULL?  And if it is, we will leak memory in the
next line so we shouldn't have _ONCE, we should always know, but not
rebooting the machine would be nice.

> +	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
> +	if (!sf->buf)
> +		return ERR_PTR(-ENOMEM);
> +	sf->size = kn->attr.size;
> +
> +	return NULL + !*ppos;
> +}

Will this also cause the vmalloc fragmentation/abuse that others have
mentioned as userspace can trigger this?

And what code frees it?

thanks,

greg k-h

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Kees Cook]

On Thu, Apr 01, 2021 at 07:16:56AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Mar 31, 2021 at 07:21:45PM -0700, Kees Cook wrote:
> > The sysfs interface to seq_file continues to be rather fragile
> > (seq_get_buf() should not be used outside of seq_file), as seen with
> > some recent exploits[1]. Move the seq_file buffer to the vmap area
> > (while retaining the accounting flag), since it has guard pages that
> > will catch and stop linear overflows. This seems justified given that
> > sysfs's use of seq_file already uses kvmalloc(), is almost always using
> > a PAGE_SIZE or larger allocation, has normally short-lived allocations,
> > and is not normally on a performance critical path.
> > 
> > Once seq_get_buf() has been removed (and all sysfs callbacks using
> > seq_file directly), this change can also be removed.
> > 
> > [1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
> > 
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > v3:
> > - Limit to only sysfs (instead of all of seq_file).
> > v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
> > v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
> > ---
> >  fs/sysfs/file.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> > index 9aefa7779b29..70e7a450e5d1 100644
> > --- a/fs/sysfs/file.c
> > +++ b/fs/sysfs/file.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/mutex.h>
> >  #include <linux/seq_file.h>
> >  #include <linux/mm.h>
> > +#include <linux/vmalloc.h>
> >  
> >  #include "sysfs.h"
> >  
> > @@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
> >  	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
> >  }
> >  
> > +/*
> > + * To be proactively defensive against sysfs show() handlers that do not
> > + * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
> > + * the trailing guard page which will stop linear buffer overflows.
> > + */
> > +static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
> > +{
> > +	struct kernfs_open_file *of = sf->private;
> > +	struct kernfs_node *kn = of->kn;
> > +
> > +	WARN_ON_ONCE(sf->buf);
> 
> How can buf ever not be NULL?  And if it is, we will leak memory in the
> next line so we shouldn't have _ONCE, we should always know, but not
> rebooting the machine would be nice.

It should never be possible. I did this because seq_file has some
unusual buf allocation patterns in the kernel, and I liked the cheap
leak check. I use _ONCE because spewing endlessly doesn't help most
cases. And if you want to trigger it again, you don't have to reboot:
https://www.kernel.org/doc/html/latest/admin-guide/clearing-warn-once.html

> 
> > +	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
> > +	if (!sf->buf)
> > +		return ERR_PTR(-ENOMEM);
> > +	sf->size = kn->attr.size;
> > +
> > +	return NULL + !*ppos;
> > +}
> 
> Will this also cause the vmalloc fragmentation/abuse that others have
> mentioned as userspace can trigger this?

If I understood the concern correctly, it was about it being a risk for
doing it for all seq_file uses. This version confines the changes to only
sysfs seq_file uses.

> And what code frees it?

The existing hooks to seq_release() handle this already. This kind of
"preallocation" of the seq_file buffer is done in a few places already
(hence my desire for the sanity checking WARN lest future seq_file
semantics change).

-- 
Kees Cook

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Greg Kroah-Hartman]

On Wed, Mar 31, 2021 at 11:52:20PM -0700, Kees Cook wrote:
> On Thu, Apr 01, 2021 at 07:16:56AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Mar 31, 2021 at 07:21:45PM -0700, Kees Cook wrote:
> > > The sysfs interface to seq_file continues to be rather fragile
> > > (seq_get_buf() should not be used outside of seq_file), as seen with
> > > some recent exploits[1]. Move the seq_file buffer to the vmap area
> > > (while retaining the accounting flag), since it has guard pages that
> > > will catch and stop linear overflows. This seems justified given that
> > > sysfs's use of seq_file already uses kvmalloc(), is almost always using
> > > a PAGE_SIZE or larger allocation, has normally short-lived allocations,
> > > and is not normally on a performance critical path.
> > > 
> > > Once seq_get_buf() has been removed (and all sysfs callbacks using
> > > seq_file directly), this change can also be removed.
> > > 
> > > [1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
> > > 
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > ---
> > > v3:
> > > - Limit to only sysfs (instead of all of seq_file).
> > > v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
> > > v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
> > > ---
> > >  fs/sysfs/file.c | 23 +++++++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > > 
> > > diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> > > index 9aefa7779b29..70e7a450e5d1 100644
> > > --- a/fs/sysfs/file.c
> > > +++ b/fs/sysfs/file.c
> > > @@ -16,6 +16,7 @@
> > >  #include <linux/mutex.h>
> > >  #include <linux/seq_file.h>
> > >  #include <linux/mm.h>
> > > +#include <linux/vmalloc.h>
> > >  
> > >  #include "sysfs.h"
> > >  
> > > @@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
> > >  	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
> > >  }
> > >  
> > > +/*
> > > + * To be proactively defensive against sysfs show() handlers that do not
> > > + * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
> > > + * the trailing guard page which will stop linear buffer overflows.
> > > + */
> > > +static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
> > > +{
> > > +	struct kernfs_open_file *of = sf->private;
> > > +	struct kernfs_node *kn = of->kn;
> > > +
> > > +	WARN_ON_ONCE(sf->buf);
> > 
> > How can buf ever not be NULL?  And if it is, we will leak memory in the
> > next line so we shouldn't have _ONCE, we should always know, but not
> > rebooting the machine would be nice.
> 
> It should never be possible. I did this because seq_file has some
> unusual buf allocation patterns in the kernel, and I liked the cheap
> leak check. I use _ONCE because spewing endlessly doesn't help most
> cases. And if you want to trigger it again, you don't have to reboot:
> https://www.kernel.org/doc/html/latest/admin-guide/clearing-warn-once.html

True, I was thinking of the panic-on-warn people, and the hesitation of
adding new WARN_ON() to the kernel code.  If this really can happen,
shouldn't we handle it properly?

> > > +	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
> > > +	if (!sf->buf)
> > > +		return ERR_PTR(-ENOMEM);
> > > +	sf->size = kn->attr.size;
> > > +
> > > +	return NULL + !*ppos;
> > > +}
> > 
> > Will this also cause the vmalloc fragmentation/abuse that others have
> > mentioned as userspace can trigger this?
> 
> If I understood the concern correctly, it was about it being a risk for
> doing it for all seq_file uses. This version confines the changes to only
> sysfs seq_file uses.

There are a few sysfs files that userspace can read from out there :)

> > And what code frees it?
> 
> The existing hooks to seq_release() handle this already. This kind of
> "preallocation" of the seq_file buffer is done in a few places already
> (hence my desire for the sanity checking WARN lest future seq_file
> semantics change).

Ah, "magic", gotta love it...

thanks,

greg k-h

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Kees Cook]

On Thu, Apr 01, 2021 at 09:10:05AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Mar 31, 2021 at 11:52:20PM -0700, Kees Cook wrote:
> > On Thu, Apr 01, 2021 at 07:16:56AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Mar 31, 2021 at 07:21:45PM -0700, Kees Cook wrote:
> > > > The sysfs interface to seq_file continues to be rather fragile
> > > > (seq_get_buf() should not be used outside of seq_file), as seen with
> > > > some recent exploits[1]. Move the seq_file buffer to the vmap area
> > > > (while retaining the accounting flag), since it has guard pages that
> > > > will catch and stop linear overflows. This seems justified given that
> > > > sysfs's use of seq_file already uses kvmalloc(), is almost always using
> > > > a PAGE_SIZE or larger allocation, has normally short-lived allocations,
> > > > and is not normally on a performance critical path.
> > > > 
> > > > Once seq_get_buf() has been removed (and all sysfs callbacks using
> > > > seq_file directly), this change can also be removed.
> > > > 
> > > > [1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
> > > > 
> > > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > > ---
> > > > v3:
> > > > - Limit to only sysfs (instead of all of seq_file).
> > > > v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
> > > > v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
> > > > ---
> > > >  fs/sysfs/file.c | 23 +++++++++++++++++++++++
> > > >  1 file changed, 23 insertions(+)
> > > > 
> > > > diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> > > > index 9aefa7779b29..70e7a450e5d1 100644
> > > > --- a/fs/sysfs/file.c
> > > > +++ b/fs/sysfs/file.c
> > > > @@ -16,6 +16,7 @@
> > > >  #include <linux/mutex.h>
> > > >  #include <linux/seq_file.h>
> > > >  #include <linux/mm.h>
> > > > +#include <linux/vmalloc.h>
> > > >  
> > > >  #include "sysfs.h"
> > > >  
> > > > @@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
> > > >  	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
> > > >  }
> > > >  
> > > > +/*
> > > > + * To be proactively defensive against sysfs show() handlers that do not
> > > > + * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
> > > > + * the trailing guard page which will stop linear buffer overflows.
> > > > + */
> > > > +static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
> > > > +{
> > > > +	struct kernfs_open_file *of = sf->private;
> > > > +	struct kernfs_node *kn = of->kn;
> > > > +
> > > > +	WARN_ON_ONCE(sf->buf);
> > > 
> > > How can buf ever not be NULL?  And if it is, we will leak memory in the
> > > next line so we shouldn't have _ONCE, we should always know, but not
> > > rebooting the machine would be nice.
> > 
> > It should never be possible. I did this because seq_file has some
> > unusual buf allocation patterns in the kernel, and I liked the cheap
> > leak check. I use _ONCE because spewing endlessly doesn't help most
> > cases. And if you want to trigger it again, you don't have to reboot:
> > https://www.kernel.org/doc/html/latest/admin-guide/clearing-warn-once.html
> 
> True, I was thinking of the panic-on-warn people, and the hesitation of
> adding new WARN_ON() to the kernel code.  If this really can happen,
> shouldn't we handle it properly?

It should never happen, but I hate silent bugs. Given the existing
pattern of "external preallocation", it seems like a fragile interface
worth asserting our expectations.

The panic_on_warn folks will get exactly what they wanted: immediate
feedback on "expected to be impossible" cases:
https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on

> > > > +	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
> > > > +	if (!sf->buf)
> > > > +		return ERR_PTR(-ENOMEM);
> > > > +	sf->size = kn->attr.size;
> > > > +
> > > > +	return NULL + !*ppos;
> > > > +}
> > > 
> > > Will this also cause the vmalloc fragmentation/abuse that others have
> > > mentioned as userspace can trigger this?
> > 
> > If I understood the concern correctly, it was about it being a risk for
> > doing it for all seq_file uses. This version confines the changes to only
> > sysfs seq_file uses.
> 
> There are a few sysfs files that userspace can read from out there :)

Yes, but the vmap area is also used by default for process stacks, etc.
Malicious fragmentation is already possible. I understood the concern to
be about "regular" use. (And if I'm wrong, we can add a knob maybe?)

> > > And what code frees it?
> > 
> > The existing hooks to seq_release() handle this already. This kind of
> > "preallocation" of the seq_file buffer is done in a few places already
> > (hence my desire for the sanity checking WARN lest future seq_file
> > semantics change).
> 
> Ah, "magic", gotta love it...

Yeeeah. :P

-- 
Kees Cook

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 2859 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
config: powerpc-randconfig-r001-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc cross compiling tool for clang build
        # apt-get install binutils-powerpc-linux-gnu
        # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
        git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           return NULL + !*ppos;
                  ~~~~ ^
   1 warning generated.


vim +52 fs/sysfs/file.c

    35	
    36	/*
    37	 * To be proactively defensive against sysfs show() handlers that do not
    38	 * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
    39	 * the trailing guard page which will stop linear buffer overflows.
    40	 */
    41	static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
    42	{
    43		struct kernfs_open_file *of = sf->private;
    44		struct kernfs_node *kn = of->kn;
    45	
    46		WARN_ON_ONCE(sf->buf);
    47		sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
    48		if (!sf->buf)
    49			return ERR_PTR(-ENOMEM);
    50		sf->size = kn->attr.size;
    51	
  > 52		return NULL + !*ppos;
    53	}
    54	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 35632 bytes --]

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
config: powerpc-randconfig-r001-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc cross compiling tool for clang build
        # apt-get install binutils-powerpc-linux-gnu
        # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
        git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
           return NULL + !*ppos;
                  ~~~~ ^
   1 warning generated.


vim +52 fs/sysfs/file.c

    35	
    36	/*
    37	 * To be proactively defensive against sysfs show() handlers that do not
    38	 * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
    39	 * the trailing guard page which will stop linear buffer overflows.
    40	 */
    41	static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
    42	{
    43		struct kernfs_open_file *of = sf->private;
    44		struct kernfs_node *kn = of->kn;
    45	
    46		WARN_ON_ONCE(sf->buf);
    47		sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
    48		if (!sf->buf)
    49			return ERR_PTR(-ENOMEM);
    50		sf->size = kn->attr.size;
    51	
  > 52		return NULL + !*ppos;
    53	}
    54	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35632 bytes --]

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Nathan Chancellor]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

On Thu, Apr 01, 2021 at 02:41:37PM +0800, kernel test robot wrote:
> Hi Kees,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on driver-core/driver-core-testing]
> [also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
> [cannot apply to hnaz-linux-mm/master]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
> config: powerpc-randconfig-r001-20210401 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # install powerpc cross compiling tool for clang build
>         # apt-get install binutils-powerpc-linux-gnu
>         # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
>         git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
> >> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
>            return NULL + !*ppos;
>                   ~~~~ ^
>    1 warning generated.
> 

Arnd addressed other warnings of this nature in this patch:

https://lore.kernel.org/r/20201028151202.3074398-1-arnd(a)kernel.org/

which it seems never got picked up :(

Cheers,
Nathan

> vim +52 fs/sysfs/file.c
> 
>     35	
>     36	/*
>     37	 * To be proactively defensive against sysfs show() handlers that do not
>     38	 * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
>     39	 * the trailing guard page which will stop linear buffer overflows.
>     40	 */
>     41	static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
>     42	{
>     43		struct kernfs_open_file *of = sf->private;
>     44		struct kernfs_node *kn = of->kn;
>     45	
>     46		WARN_ON_ONCE(sf->buf);
>     47		sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
>     48		if (!sf->buf)
>     49			return ERR_PTR(-ENOMEM);
>     50		sf->size = kn->attr.size;
>     51	
>   > 52		return NULL + !*ppos;
>     53	}
>     54	
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Nathan Chancellor]

On Thu, Apr 01, 2021 at 02:41:37PM +0800, kernel test robot wrote:
> Hi Kees,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on driver-core/driver-core-testing]
> [also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
> [cannot apply to hnaz-linux-mm/master]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
> config: powerpc-randconfig-r001-20210401 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # install powerpc cross compiling tool for clang build
>         # apt-get install binutils-powerpc-linux-gnu
>         # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
>         git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
> >> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
>            return NULL + !*ppos;
>                   ~~~~ ^
>    1 warning generated.
> 

Arnd addressed other warnings of this nature in this patch:

https://lore.kernel.org/r/20201028151202.3074398-1-arnd@kernel.org/

which it seems never got picked up :(

Cheers,
Nathan

> vim +52 fs/sysfs/file.c
> 
>     35	
>     36	/*
>     37	 * To be proactively defensive against sysfs show() handlers that do not
>     38	 * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
>     39	 * the trailing guard page which will stop linear buffer overflows.
>     40	 */
>     41	static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
>     42	{
>     43		struct kernfs_open_file *of = sf->private;
>     44		struct kernfs_node *kn = of->kn;
>     45	
>     46		WARN_ON_ONCE(sf->buf);
>     47		sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
>     48		if (!sf->buf)
>     49			return ERR_PTR(-ENOMEM);
>     50		sf->size = kn->attr.size;
>     51	
>   > 52		return NULL + !*ppos;
>     53	}
>     54	
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Kees Cook]

[-- Attachment #1: Type: text/plain, Size: 2674 bytes --]

On Wed, Mar 31, 2021 at 11:47:53PM -0700, Nathan Chancellor wrote:
> On Thu, Apr 01, 2021 at 02:41:37PM +0800, kernel test robot wrote:
> > Hi Kees,
> > 
> > I love your patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on driver-core/driver-core-testing]
> > [also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
> > [cannot apply to hnaz-linux-mm/master]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch]
> > 
> > url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
> > config: powerpc-randconfig-r001-20210401 (attached as .config)
> > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
> > reproduce (this is a W=1 build):
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # install powerpc cross compiling tool for clang build
> >         # apt-get install binutils-powerpc-linux-gnu
> >         # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
> >         git remote add linux-review https://github.com/0day-ci/linux
> >         git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> >         git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> > 
> > All warnings (new ones prefixed by >>):
> > 
> > >> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> >            return NULL + !*ppos;
> >                   ~~~~ ^
> >    1 warning generated.
> > 
> 
> Arnd addressed other warnings of this nature in this patch:
> 
> https://lore.kernel.org/r/20201028151202.3074398-1-arnd(a)kernel.org/

Ah! Yeah, I copied exactly that clever idiom that Arnd fixed. :)

> which it seems never got picked up :(

Greg, are you able to pick this up too? (Yeow, sent in October!)
(Or I could respin and send them as a series?)

-- 
Kees Cook

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Kees Cook]

On Wed, Mar 31, 2021 at 11:47:53PM -0700, Nathan Chancellor wrote:
> On Thu, Apr 01, 2021 at 02:41:37PM +0800, kernel test robot wrote:
> > Hi Kees,
> > 
> > I love your patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on driver-core/driver-core-testing]
> > [also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
> > [cannot apply to hnaz-linux-mm/master]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch]
> > 
> > url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
> > config: powerpc-randconfig-r001-20210401 (attached as .config)
> > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
> > reproduce (this is a W=1 build):
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # install powerpc cross compiling tool for clang build
> >         # apt-get install binutils-powerpc-linux-gnu
> >         # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
> >         git remote add linux-review https://github.com/0day-ci/linux
> >         git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> >         git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> > 
> > All warnings (new ones prefixed by >>):
> > 
> > >> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> >            return NULL + !*ppos;
> >                   ~~~~ ^
> >    1 warning generated.
> > 
> 
> Arnd addressed other warnings of this nature in this patch:
> 
> https://lore.kernel.org/r/20201028151202.3074398-1-arnd@kernel.org/

Ah! Yeah, I copied exactly that clever idiom that Arnd fixed. :)

> which it seems never got picked up :(

Greg, are you able to pick this up too? (Yeow, sent in October!)
(Or I could respin and send them as a series?)

-- 
Kees Cook

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Greg Kroah-Hartman]

[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]

On Wed, Mar 31, 2021 at 11:59:03PM -0700, Kees Cook wrote:
> On Wed, Mar 31, 2021 at 11:47:53PM -0700, Nathan Chancellor wrote:
> > On Thu, Apr 01, 2021 at 02:41:37PM +0800, kernel test robot wrote:
> > > Hi Kees,
> > > 
> > > I love your patch! Perhaps something to improve:
> > > 
> > > [auto build test WARNING on driver-core/driver-core-testing]
> > > [also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
> > > [cannot apply to hnaz-linux-mm/master]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch]
> > > 
> > > url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
> > > config: powerpc-randconfig-r001-20210401 (attached as .config)
> > > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
> > > reproduce (this is a W=1 build):
> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >         chmod +x ~/bin/make.cross
> > >         # install powerpc cross compiling tool for clang build
> > >         # apt-get install binutils-powerpc-linux-gnu
> > >         # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
> > >         git remote add linux-review https://github.com/0day-ci/linux
> > >         git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> > >         git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
> > >         # save the attached .config to linux build tree
> > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 
> > > 
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > 
> > > All warnings (new ones prefixed by >>):
> > > 
> > > >> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> > >            return NULL + !*ppos;
> > >                   ~~~~ ^
> > >    1 warning generated.
> > > 
> > 
> > Arnd addressed other warnings of this nature in this patch:
> > 
> > https://lore.kernel.org/r/20201028151202.3074398-1-arnd(a)kernel.org/
> 
> Ah! Yeah, I copied exactly that clever idiom that Arnd fixed. :)
> 
> > which it seems never got picked up :(
> 
> Greg, are you able to pick this up too? (Yeow, sent in October!)
> (Or I could respin and send them as a series?)

As a series would be great, thanks.

greg k-h

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Greg Kroah-Hartman]

On Wed, Mar 31, 2021 at 11:59:03PM -0700, Kees Cook wrote:
> On Wed, Mar 31, 2021 at 11:47:53PM -0700, Nathan Chancellor wrote:
> > On Thu, Apr 01, 2021 at 02:41:37PM +0800, kernel test robot wrote:
> > > Hi Kees,
> > > 
> > > I love your patch! Perhaps something to improve:
> > > 
> > > [auto build test WARNING on driver-core/driver-core-testing]
> > > [also build test WARNING on kees/for-next/pstore v5.12-rc5 next-20210331]
> > > [cannot apply to hnaz-linux-mm/master]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch]
> > > 
> > > url:    https://github.com/0day-ci/linux/commits/Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git d225ef6fda7ce9ff7d28764bd1cceea2d0215e8b
> > > config: powerpc-randconfig-r001-20210401 (attached as .config)
> > > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
> > > reproduce (this is a W=1 build):
> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >         chmod +x ~/bin/make.cross
> > >         # install powerpc cross compiling tool for clang build
> > >         # apt-get install binutils-powerpc-linux-gnu
> > >         # https://github.com/0day-ci/linux/commit/c80ca56c15314908ebc1881678da3b36e007a2f4
> > >         git remote add linux-review https://github.com/0day-ci/linux
> > >         git fetch --no-tags linux-review Kees-Cook/sysfs-Unconditionally-use-vmalloc-for-buffer/20210401-102455
> > >         git checkout c80ca56c15314908ebc1881678da3b36e007a2f4
> > >         # save the attached .config to linux build tree
> > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 
> > > 
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > 
> > > All warnings (new ones prefixed by >>):
> > > 
> > > >> fs/sysfs/file.c:52:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> > >            return NULL + !*ppos;
> > >                   ~~~~ ^
> > >    1 warning generated.
> > > 
> > 
> > Arnd addressed other warnings of this nature in this patch:
> > 
> > https://lore.kernel.org/r/20201028151202.3074398-1-arnd@kernel.org/
> 
> Ah! Yeah, I copied exactly that clever idiom that Arnd fixed. :)
> 
> > which it seems never got picked up :(
> 
> Greg, are you able to pick this up too? (Yeow, sent in October!)
> (Or I could respin and send them as a series?)

As a series would be great, thanks.

greg k-h

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Michal Hocko]

On Wed 31-03-21 19:21:45, Kees Cook wrote:
> The sysfs interface to seq_file continues to be rather fragile
> (seq_get_buf() should not be used outside of seq_file), as seen with
> some recent exploits[1]. Move the seq_file buffer to the vmap area
> (while retaining the accounting flag), since it has guard pages that
> will catch and stop linear overflows.

I thought the previous discussion has led to a conclusion that the
preferred way is to disallow direct seq_file buffer usage. But this is
obviously up to sysfs maintainers. I am happy you do not want to spread
this out to all seq_file users anymore.

> This seems justified given that
> sysfs's use of seq_file already uses kvmalloc(), is almost always using
> a PAGE_SIZE or larger allocation, has normally short-lived allocations,
> and is not normally on a performance critical path.

Let me clarify on this, because this is not quite right. kvmalloc vs
vmalloc (both with GFP_KERNEL) on PAGE_SIZE are two different beasts.
The first one is almost always going to use kmalloc because the page
allocator almost never fails those requests.

> Once seq_get_buf() has been removed (and all sysfs callbacks using
> seq_file directly), this change can also be removed.
> 
> [1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> v3:
> - Limit to only sysfs (instead of all of seq_file).
> v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
> v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
> ---
>  fs/sysfs/file.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 9aefa7779b29..70e7a450e5d1 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -16,6 +16,7 @@
>  #include <linux/mutex.h>
>  #include <linux/seq_file.h>
>  #include <linux/mm.h>
> +#include <linux/vmalloc.h>
>  
>  #include "sysfs.h"
>  
> @@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
>  	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
>  }
>  
> +/*
> + * To be proactively defensive against sysfs show() handlers that do not
> + * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
> + * the trailing guard page which will stop linear buffer overflows.
> + */
> +static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
> +{
> +	struct kernfs_open_file *of = sf->private;
> +	struct kernfs_node *kn = of->kn;
> +
> +	WARN_ON_ONCE(sf->buf);
> +	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
> +	if (!sf->buf)
> +		return ERR_PTR(-ENOMEM);
> +	sf->size = kn->attr.size;
> +
> +	return NULL + !*ppos;
> +}
> +
>  /*
>   * Reads on sysfs are handled through seq_file, which takes care of hairy
>   * details like buffering and seeking.  The following function pipes
> @@ -206,14 +226,17 @@ static const struct kernfs_ops sysfs_file_kfops_empty = {
>  };
>  
>  static const struct kernfs_ops sysfs_file_kfops_ro = {
> +	.seq_start	= sysfs_kf_seq_start,
>  	.seq_show	= sysfs_kf_seq_show,
>  };
>  
>  static const struct kernfs_ops sysfs_file_kfops_wo = {
> +	.seq_start	= sysfs_kf_seq_start,
>  	.write		= sysfs_kf_write,
>  };
>  
>  static const struct kernfs_ops sysfs_file_kfops_rw = {
> +	.seq_start	= sysfs_kf_seq_start,
>  	.seq_show	= sysfs_kf_seq_show,
>  	.write		= sysfs_kf_write,
>  };
> -- 
> 2.25.1

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3] sysfs: Unconditionally use vmalloc for buffer

[Kees Cook]

On Thu, Apr 01, 2021 at 09:14:25AM +0200, Michal Hocko wrote:
> On Wed 31-03-21 19:21:45, Kees Cook wrote:
> > The sysfs interface to seq_file continues to be rather fragile
> > (seq_get_buf() should not be used outside of seq_file), as seen with
> > some recent exploits[1]. Move the seq_file buffer to the vmap area
> > (while retaining the accounting flag), since it has guard pages that
> > will catch and stop linear overflows.
> 
> I thought the previous discussion has led to a conclusion that the
> preferred way is to disallow direct seq_file buffer usage. But this is
> obviously up to sysfs maintainers. I am happy you do not want to spread
> this out to all seq_file users anymore.

Yeah; I still want to remove external seq_get_buf(), but that'll take
time. I'll be doing the work, though, since I still need access to
f_cred for show() access control checks.

> > This seems justified given that
> > sysfs's use of seq_file already uses kvmalloc(), is almost always using
> > a PAGE_SIZE or larger allocation, has normally short-lived allocations,
> > and is not normally on a performance critical path.
> 
> Let me clarify on this, because this is not quite right. kvmalloc vs
> vmalloc (both with GFP_KERNEL) on PAGE_SIZE are two different beasts.
> The first one is almost always going to use kmalloc because the page
> allocator almost never fails those requests.

Yes, good point. I will adjust my changelog.

Thanks!

-Kees

> 
> > Once seq_get_buf() has been removed (and all sysfs callbacks using
> > seq_file directly), this change can also be removed.
> > 
> > [1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
> > 
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > v3:
> > - Limit to only sysfs (instead of all of seq_file).
> > v2: https://lore.kernel.org/lkml/20210315174851.622228-1-keescook@chromium.org/
> > v1: https://lore.kernel.org/lkml/20210312205558.2947488-1-keescook@chromium.org/
> > ---
> >  fs/sysfs/file.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> > index 9aefa7779b29..70e7a450e5d1 100644
> > --- a/fs/sysfs/file.c
> > +++ b/fs/sysfs/file.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/mutex.h>
> >  #include <linux/seq_file.h>
> >  #include <linux/mm.h>
> > +#include <linux/vmalloc.h>
> >  
> >  #include "sysfs.h"
> >  
> > @@ -32,6 +33,25 @@ static const struct sysfs_ops *sysfs_file_ops(struct kernfs_node *kn)
> >  	return kobj->ktype ? kobj->ktype->sysfs_ops : NULL;
> >  }
> >  
> > +/*
> > + * To be proactively defensive against sysfs show() handlers that do not
> > + * correctly stay within their PAGE_SIZE buffer, use the vmap area to gain
> > + * the trailing guard page which will stop linear buffer overflows.
> > + */
> > +static void *sysfs_kf_seq_start(struct seq_file *sf, loff_t *ppos)
> > +{
> > +	struct kernfs_open_file *of = sf->private;
> > +	struct kernfs_node *kn = of->kn;
> > +
> > +	WARN_ON_ONCE(sf->buf);
> > +	sf->buf = __vmalloc(kn->attr.size, GFP_KERNEL_ACCOUNT);
> > +	if (!sf->buf)
> > +		return ERR_PTR(-ENOMEM);
> > +	sf->size = kn->attr.size;
> > +
> > +	return NULL + !*ppos;
> > +}
> > +
> >  /*
> >   * Reads on sysfs are handled through seq_file, which takes care of hairy
> >   * details like buffering and seeking.  The following function pipes
> > @@ -206,14 +226,17 @@ static const struct kernfs_ops sysfs_file_kfops_empty = {
> >  };
> >  
> >  static const struct kernfs_ops sysfs_file_kfops_ro = {
> > +	.seq_start	= sysfs_kf_seq_start,
> >  	.seq_show	= sysfs_kf_seq_show,
> >  };
> >  
> >  static const struct kernfs_ops sysfs_file_kfops_wo = {
> > +	.seq_start	= sysfs_kf_seq_start,
> >  	.write		= sysfs_kf_write,
> >  };
> >  
> >  static const struct kernfs_ops sysfs_file_kfops_rw = {
> > +	.seq_start	= sysfs_kf_seq_start,
> >  	.seq_show	= sysfs_kf_seq_show,
> >  	.write		= sysfs_kf_write,
> >  };
> > -- 
> > 2.25.1
> 
> -- 
> Michal Hocko
> SUSE Labs

-- 
Kees Cook