linux-kernel - Re: Another gcc corruption bug (was Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings)

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, 13 Oct 2016 15:15:46 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Denys Vlasenko <dvlasenk@...hat.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Emese Revfy <re.emese@...il.com>
Subject: Re: Another gcc corruption bug (was Re: [PATCH] [RFC] x86: avoid
 -mtune=atom for objtool warnings)

On Thu, Oct 13, 2016 at 07:57:41PM +0200, Denys Vlasenko wrote:
> On 10/13/2016 02:46 PM, Josh Poimboeuf wrote:
> > On Tue, Oct 11, 2016 at 10:38:42PM +0200, Arnd Bergmann wrote:
> > > 0000000000000000 <snic_log_q_error>:
> > >    0:	55                   	push   %rbp
> > >    1:	48 89 e5             	mov    %rsp,%rbp
> > >    4:	53                   	push   %rbx
> > >    5:	48 89 fb             	mov    %rdi,%rbx
> > >    8:	48 83 ec 08          	sub    $0x8,%rsp
> > >    c:	e8 00 00 00 00       	callq  11 <snic_log_q_error+0x11>
> > > 			d: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
> > >   11:	8b 03                	mov    (%rbx),%eax
> > >   13:	85 c0                	test   %eax,%eax
> > >   15:	75 11                	jne    28 <snic_log_q_error+0x28>
> > >   17:	48 83 c4 08          	add    $0x8,%rsp
> > >   1b:	5b                   	pop    %rbx
> > >   1c:	5d                   	pop    %rbp
> > >   1d:	e9 00 00 00 00       	jmpq   22 <snic_log_q_error+0x22>
> > > 			1e: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
> > >   22:	66 0f 1f 44 00 00    	nopw   0x0(%rax,%rax,1)
> > >   28:	e8 00 00 00 00       	callq  2d <snic_log_q_error+0x2d>
> > > 			29: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
> > >   2d:	48 8b 7b 10          	mov    0x10(%rbx),%rdi
> > >   31:	e8 00 00 00 00       	callq  36 <snic_log_q_error+0x36>
> > > 			32: R_X86_64_PC32	ioread32-0x4
> > >   36:	89 05 00 00 00 00    	mov    %eax,0x0(%rip)        # 3c <snic_log_q_error+0x3c>
> > > 			38: R_X86_64_PC32	snic_log_q_error_err_status-0x4
> > >   3c:	83 3b 01             	cmpl   $0x1,(%rbx)
> > >   3f:	76 d6                	jbe    17 <snic_log_q_error+0x17>
> > >   41:	e8 00 00 00 00       	callq  46 <snic_log_q_error+0x46>
> > > 			42: R_X86_64_PC32	__sanitizer_cov_trace_pc-0x4
> > 
> > I opened a bug:
> > 
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77966
> > 
> 
> Surprisingly, it's really "not a bug". The only way you can end up in this branch
> is if you have a bug and run off the end of wq[1] array member: i.e.
> if snic->wq_count >= 2. (See gcc BZ for smaller example)
> 
> It's debatable whether it's okay for gcc to just let buggy code to run off
> and execute something random. It is surely surprising, and not debug-friendly.
> 
> An option to emit a crashing instruction (HLT, INT3, that sort of thing)
> instead of just stopping code generation might be useful.

Ah, you're right.

IMO it's still a gcc bug though.  Instead of following a bad pointer, it
would instead start executing some random function.  That takes
"undefined behavior" to a new level.

-- 
Josh