mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Kees Cook <keescook@chromium.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	"Tobin C . Harding" <me@tobin.cc>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] vsprintf: don't obfuscate NULL and error pointers
Date: Tue, 19 May 2020 15:26:21 +0300	[thread overview]
Message-ID: <20200519122621.GD1634618@smile.fi.intel.com> (raw)
In-Reply-To: <20200519112657.17098-1-idryomov@gmail.com>

On Tue, May 19, 2020 at 01:26:57PM +0200, Ilya Dryomov wrote:
> I don't see what security concern is addressed by obfuscating NULL
> and IS_ERR() error pointers, printed with %p/%pK.  Given the number
> of sites where %p is used (over 10000) and the fact that NULL pointers
> aren't uncommon, it probably wouldn't take long for an attacker to
> find the hash that corresponds to 0.  Although harder, the same goes
> for most common error values, such as -1, -2, -11, -14, etc.
> 
> The NULL part actually fixes a regression: NULL pointers weren't
> obfuscated until commit 3e5903eb9cff ("vsprintf: Prevent crash when
> dereferencing invalid pointers") which went into 5.2.  I'm tacking
> the IS_ERR() part on here because error pointers won't leak kernel
> addresses and printing them as pointers shouldn't be any different
> from e.g. %d with PTR_ERR_OR_ZERO().  Obfuscating them just makes
> debugging based on existing pr_debug and friends excruciating.
> 
> Note that the "always print 0's for %pK when kptr_restrict == 2"
> behaviour which goes way back is left as is.
> 
> Example output with the patch applied:
> 
>                             ptr         error-ptr              NULL
> %p:            0000000001f8cc5b  fffffffffffffff2  0000000000000000
> %pK, kptr = 0: 0000000001f8cc5b  fffffffffffffff2  0000000000000000
> %px:           ffff888048c04020  fffffffffffffff2  0000000000000000
> %pK, kptr = 1: ffff888048c04020  fffffffffffffff2  0000000000000000
> %pK, kptr = 2: 0000000000000000  0000000000000000  0000000000000000
> 
> Fixes: 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>  lib/test_printf.c | 19 ++++++++++++++++++-
>  lib/vsprintf.c    |  7 +++++++
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> Hi Petr,
> 
> This just came up again, please consider sending this to Linus
> for 5.7.
> 
> Prior discussion was split in three threads and revolved around the
> vision for how lib/test_printf.c should be structured between Rasmus
> and yourself.  The fix itself wasn't disputed and has several acks.
> 
> If you want to restructure the test suite before adding any new
> test cases, v1 doesn't have them, but I'm reposting with test cases
> because I think it's best to add them right away to prevent further
> regressions.
> 
> v3:
> - don't use EAGAIN macro in error_pointer() test case as the
>   actual error code varies between architectures
> 
> v2:
> - fix null_pointer() test case (it didn't catch the original
>   regression because test_hashed() doesn't really test much)
>   and add error_pointer() test case
> 
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 2d9f520d2f27..6b1622f4d7c2 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -214,6 +214,7 @@ test_string(void)
>  #define PTR_STR "ffff0123456789ab"
>  #define PTR_VAL_NO_CRNG "(____ptrval____)"
>  #define ZEROS "00000000"	/* hex 32 zero bits */
> +#define ONES "ffffffff"		/* hex 32 one bits */
>  
>  static int __init
>  plain_format(void)
> @@ -245,6 +246,7 @@ plain_format(void)
>  #define PTR_STR "456789ab"
>  #define PTR_VAL_NO_CRNG "(ptrval)"
>  #define ZEROS ""
> +#define ONES ""
>  
>  static int __init
>  plain_format(void)
> @@ -330,14 +332,28 @@ test_hashed(const char *fmt, const void *p)
>  	test(buf, fmt, p);
>  }
>  
> +/*
> + * NULL pointers aren't hashed.
> + */
>  static void __init
>  null_pointer(void)
>  {
> -	test_hashed("%p", NULL);
> +	test(ZEROS "00000000", "%p", NULL);
>  	test(ZEROS "00000000", "%px", NULL);
>  	test("(null)", "%pE", NULL);
>  }
>  
> +/*
> + * Error pointers aren't hashed.
> + */
> +static void __init
> +error_pointer(void)
> +{
> +	test(ONES "fffffff5", "%p", ERR_PTR(-11));
> +	test(ONES "fffffff5", "%px", ERR_PTR(-11));
> +	test("(efault)", "%pE", ERR_PTR(-11));
> +}
> +
>  #define PTR_INVALID ((void *)0x000000ab)
>  
>  static void __init
> @@ -649,6 +665,7 @@ test_pointer(void)
>  {
>  	plain();
>  	null_pointer();
> +	error_pointer();
>  	invalid_pointer();
>  	symbol_ptr();
>  	kernel_ptr();
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7c488a1ce318..f0f0522cd5a7 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -794,6 +794,13 @@ static char *ptr_to_id(char *buf, char *end, const void *ptr,
>  	unsigned long hashval;
>  	int ret;
>  
> +	/*
> +	 * Print the real pointer value for NULL and error pointers,
> +	 * as they are not actual addresses.
> +	 */
> +	if (IS_ERR_OR_NULL(ptr))
> +		return pointer_string(buf, end, ptr, spec);
> +
>  	/* When debugging early boot use non-cryptographically secure hash. */
>  	if (unlikely(debug_boot_weak_hash)) {
>  		hashval = hash_long((unsigned long)ptr, 32);
> -- 
> 2.19.2
> 

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-05-19 12:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 11:26 Ilya Dryomov
2020-05-19 12:26 ` Andy Shevchenko [this message]
2020-05-19 18:36 ` Linus Torvalds
2020-05-20 10:53   ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200519122621.GD1634618@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=idryomov@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=me@tobin.cc \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome