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:	Wed, 10 Feb 2016 11:52:31 +0000
From:	James Morse <james.morse@....com>
To:	Will Deacon <will.deacon@....com>, Yang Shi <yang.shi@...aro.org>
CC:	catalin.marinas@....com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org
Subject: Re: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump

On 10/02/16 10:29, Will Deacon wrote:
> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
>> dump_backtrace may be called in kthread context, which is not bound to a single
>> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
>> report:
> 
> If we're preemptible here, it means that our irq_stack_ptr is potentially
> bogus. Whilst this isn't an issue for kthreads, it does feel like we
> could make this slightly more robust in the face of potential frame
> corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
> context?

Switching between stacks is only valid if we are tracing ourselves while on the
irq_stack, we should probably prevent it for other tasks too.

Something like (untested):
---------------------
if (tsk == current && in_atomic())
	irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
else
	irq_stack_ptr = 0;
---------------------

This would work when we trace ourselves while on the irq_stack, but break*
tracing a running task on a remote cpu (khungtaskd doesn't do this).

The same fix would apply to unwind_frame(), we have 'tsk' in both functions.

Thoughts?


James


* If this were to ever happen, we would fail to switch to the original stack if
  tracing a remote irq stack, and print the wrong exception args. I'm not aware
  of any users of this, (panic() sends an IPI).

Powered by blists - more mailing lists