Michael Neuling <mi...@neuling.org> writes: > __get_user_atomic_128_aligned() stores to kaddr using stvx which is a > VMX store instruction, hence kaddr must be 16 byte aligned otherwise > the store won't occur as expected. > > Unfortunately when we call __get_user_atomic_128_aligned() in > p9_hmi_special_emu(), the buffer we pass as kaddr (ie. vbuf) isn't > guaranteed to be 16B aligned. This means that the write to vbuf in > __get_user_atomic_128_aligned() has the bottom bits of the address > truncated. This results in other local variables being > overwritten. Also vbuf will not contain the correct data which results > in the userspace emulation being wrong and hence user data corruption. > > In the past we've been mostly lucky as vbuf has ended up aligned but > this is fragile and isn't always true. CONFIG_STACKPROTECTOR in > particular can change the stack arrangement enough that our luck runs > out.
Actually I'm yet to find a kernel with CONFIG_STACKPROTECTOR=n that is vulnerable to the bug. Turning on STACKPROTECTOR changes the order GCC allocates locals on the stack, from bottom-up to top-down. That in conjunction with the 8 byte stack canary means we end up with 8 bytes of space below the locals, which misaligns vbuf. But obviously other things can change the stack layout too, so no guarantees that CONFIG_STACKPROTECTOR=n makes it safe. cheers
