[PATCH] ERR_PTR: if errno value is known at compile time, make sure it's valid

[PATCH] ERR_PTR: if errno value is known at compile time, make sure it's valid

[Marcin Slusarz]

ERR_PTR is easy to call with wrong argument (positive errno),
and this error lead to catastrophic event - oops or kernel panic
(dereference of invalid pointer).

As most of error handling code paths are rarely tested, this kind of
bug can be hidden for years. Currently there are > 1400 calls of ERR_PTR
with constant argument.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Johannes Weiner <hannes@saeurebad.de>
---
 include/linux/err.h |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/include/linux/err.h b/include/linux/err.h
index ec87f31..4773ed3 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -18,12 +18,21 @@
 #ifndef __ASSEMBLY__
 
 #define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+#define VALID_ERR_PTR_ARG(error) (error == 0 || IS_ERR_VALUE(error))
 
-static inline void *ERR_PTR(long error)
+static inline void *__ERR_PTR(long error)
 {
 	return (void *) error;
 }
 
+/*
+ * implementation note: we have to make it a macro, otherwise
+ * gcc won't break the build on wrong argument
+ */
+#define ERR_PTR(error) (BUILD_BUG_ON(__builtin_constant_p(error) && \
+					!VALID_ERR_PTR_ARG(error)), \
+			__ERR_PTR(error))
+
 static inline long PTR_ERR(const void *ptr)
 {
 	return (long) ptr;
-- 
1.5.4.5

[PATCH] ERR_PTR: warn when ERR_PTR parameter is valid argument

[Marcin Slusarz]

Check at runtime whether error argument of ERR_PTR is valid.
It can catch bugs which possibly lead to oops or panic earlier.

Currently there are > 600 calls of ERR_PTR with non-constant argument.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Johannes Weiner <hannes@saeurebad.de>
---
 include/linux/err.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/linux/err.h b/include/linux/err.h
index 4773ed3..f7e098e 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -3,6 +3,7 @@
 
 #include <linux/compiler.h>
 
+#include <asm/bug.h>
 #include <asm/errno.h>
 
 /*
@@ -22,6 +23,7 @@
 
 static inline void *__ERR_PTR(long error)
 {
+	WARN_ON(!VALID_ERR_PTR_ARG(error));
 	return (void *) error;
 }
 
-- 
1.5.4.5

Re: [PATCH] ERR_PTR: warn when ERR_PTR parameter is invalid

[Marcin Slusarz]

Sorry, wrong patch title. Should be:
"ERR_PTR: warn when ERR_PTR parameter is invalid"

I forgot to add that this patch sould be applied after:
"vfs: fix ERR_PTR abuse in generic_readlink"
http://lkml.org/lkml/2008/5/18/316
which is alredy in -mm

Cheers,
Marcin

Re: [PATCH] ERR_PTR: warn when ERR_PTR parameter is valid argument

[Andrew Morton]

On Thu, 22 May 2008 18:50:19 +0200
Marcin Slusarz <marcin.slusarz@gmail.com> wrote:

> Check at runtime whether error argument of ERR_PTR is valid.
> It can catch bugs which possibly lead to oops or panic earlier.
> 
> Currently there are > 600 calls of ERR_PTR with non-constant argument.
> 
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Al Viro <viro@ZenIV.linux.org.uk>
> Cc: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: Johannes Weiner <hannes@saeurebad.de>
> ---
>  include/linux/err.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/err.h b/include/linux/err.h
> index 4773ed3..f7e098e 100644
> --- a/include/linux/err.h
> +++ b/include/linux/err.h
> @@ -3,6 +3,7 @@
>  
>  #include <linux/compiler.h>
>  
> +#include <asm/bug.h>
>  #include <asm/errno.h>
>  
>  /*
> @@ -22,6 +23,7 @@
>  
>  static inline void *__ERR_PTR(long error)
>  {
> +	WARN_ON(!VALID_ERR_PTR_ARG(error));
>  	return (void *) error;
>  }

It would be regrettable to add source-level complexity and runtime cost
to detect this particular bug.  I think it would be better to do this
via static source-code checking if at all possible.

Is there _any_ legitimate use of non-negative EFOO?  There might be
some baroque bits of code which are using non-negative constants in a
non-buggy fashion, but I bet they could be reworked to use negative
constants.

In which case I'd have thought that a script which

a) extracts all the EFOO identifiers from include/*/errno.h and

b) greps the tree for non-negative uses of those

would have 100% coverage?

We might need to touch up some code sites to avoid triggering false
positives and make that script's life a bit easier, but that's fine.