linux-kernel - Re: [PATCH] [Backport to stable 4.9.y] arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault

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] [day] [month] [year] [list]

Message-ID: <20191122095805.GA1882462@kroah.com>
Date:   Fri, 22 Nov 2019 10:58:05 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Will Deacon <will@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        catalin.marinas@....com, mark.rutland@....com,
        pasha.tatashin@...een.com
Subject: Re: [PATCH] [Backport to stable 4.9.y] arm64: uaccess: Ensure PAN is
 re-enabled after unhandled uaccess fault

On Fri, Nov 22, 2019 at 09:51:16AM +0000, Will Deacon wrote:
> From: Pavel Tatashin <pasha.tatashin@...een.com>
> 
> commit 94bb804e1e6f0a9a77acf20d7c70ea141c6c821e upstream.
> 
> A number of our uaccess routines ('__arch_clear_user()' and
> '__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they
> encounter an unhandled fault whilst accessing userspace.
> 
> For CPUs implementing both hardware PAN and UAO, this bug has no effect
> when both extensions are in use by the kernel.
> 
> For CPUs implementing hardware PAN but not UAO, this means that a kernel
> using hardware PAN may execute portions of code with PAN inadvertently
> disabled, opening us up to potential security vulnerabilities that rely
> on userspace access from within the kernel which would usually be
> prevented by this mechanism. In other words, parts of the kernel run the
> same way as they would on a CPU without PAN implemented/emulated at all.
> 
> For CPUs not implementing hardware PAN and instead relying on software
> emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately
> much worse. Calling 'schedule()' with software PAN disabled means that
> the next task will execute in the kernel using the page-table and ASID
> of the previous process even after 'switch_mm()', since the actual
> hardware switch is deferred until return to userspace. At this point, or
> if there is a intermediate call to 'uaccess_enable()', the page-table
> and ASID of the new process are installed. Sadly, due to the changes
> introduced by KPTI, this is not an atomic operation and there is a very
> small window (two instructions) where the CPU is configured with the
> page-table of the old task and the ASID of the new task; a speculative
> access in this state is disastrous because it would corrupt the TLB
> entries for the new task with mappings from the previous address space.
> 
> As Pavel explains:
> 
>   | I was able to reproduce memory corruption problem on Broadcom's SoC
>   | ARMv8-A like this:
>   |
>   | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's
>   | stack is accessed and copied.
>   |
>   | The test program performed the following on every CPU and forking
>   | many processes:
>   |
>   |	unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE,
>   |				  MAP_SHARED | MAP_ANONYMOUS, -1, 0);
>   |	map[0] = getpid();
>   |	sched_yield();
>   |	if (map[0] != getpid()) {
>   |		fprintf(stderr, "Corruption detected!");
>   |	}
>   |	munmap(map, PAGE_SIZE);
>   |
>   | From time to time I was getting map[0] to contain pid for a
>   | different process.
> 
> Ensure that PAN is re-enabled when returning after an unhandled user
> fault from our uaccess routines.
> 
> Cc: Catalin Marinas <catalin.marinas@....com>
> Reviewed-by: Mark Rutland <mark.rutland@....com>
> Tested-by: Mark Rutland <mark.rutland@....com>
> Cc: <stable@...r.kernel.org>
> Fixes: 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access Never")
> Signed-off-by: Pavel Tatashin <pasha.tatashin@...een.com>
> [will: rewrote commit message]
> [will: backport for 4.9.y stable kernels]

Thanks for this and the 4.4.y backport, both now queued up.

greg k-h