linux-kernel - Re: [PATCH] Wrong symbol resolved for RIP on OOPS/BUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Nov 2013 08:54:48 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Marek Majkowski <marek@...udflare.com>, Jiri Slaby <jslaby@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Wrong symbol resolved for RIP on OOPS/BUG


* Marek Majkowski <marek@...udflare.com> wrote:

> "%pB" is intended for return addresses, and actually resolves the
> address - 1.  So it should only be used for backtraces.  Plain
> instruction addresses should use "%pS", which resolves the given
> address.
> 
> show_regs was using "%pB" to resolve the RIP symbol. This resolved the
> wrong symbol if the first instruction after a symbol created the
> OOPS/BUG. For example:
> 
> 0000000000000049 <before>:
>   49:   90                      nop
>   4a:   90                      nop
>   4b:   90                      nop
>   4c:   90                      nop
> 000000000000004d <suicide>:
>   4d:   ff 14 25 00 00 00 00    callq  *0x0
>   54:   c3                      retq
> 
> Will produce a message saying it's "before" that crashed, not "suicide".
> 
> This problem only happens when the crash occurs in the first instruction
> after a symbol. Therefore it's unlikely to occur on kernels with frame
> pointers (CONFIG_FRAME_POINTER=y).
> 
> Signed-off-by: Marek Majkowski <marek@...udflare.com>
> 
> diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
> index deb6421..4c90013 100644
> --- a/arch/x86/kernel/dumpstack.c
> +++ b/arch/x86/kernel/dumpstack.c
> @@ -27,6 +27,12 @@ static int die_counter;
>  
>  void printk_address(unsigned long address, int reliable)
>  {
> +	pr_cont(" [<%p>] %s%pS\n",
> +		(void *)address, reliable ? "" : "? ", (void *)address);
> +}
> +
> +static void printk_trace_address(unsigned long address, int reliable)
> +{
>  	pr_cont(" [<%p>] %s%pB\n",
>  		(void *)address, reliable ? "" : "? ", (void *)address);
>  }
> @@ -151,7 +157,7 @@ static void print_trace_address(void *data, unsigned long addr, int reliable)
>  {
>  	touch_nmi_watchdog();
>  	printk(data);
> -	printk_address(addr, reliable);
> +	printk_trace_address(addr, reliable);
>  }
>  
>  static const struct stacktrace_ops print_trace_ops = {

There's a recent commit from Jiri Slaby that I think tries to address the 
same problem:

  8d4c812a3e5f x86/dumpstack: Fix printk_address for direct addresses

You can find it in the -tip tree:

  git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/