This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v5 03/30] arm64: signal: Verify extra data is user-readable in sys_rt_sigreturn
- From: Catalin Marinas <catalin dot marinas at arm dot com>
- To: Dave Martin <Dave dot Martin at arm dot com>
- Cc: linux-arm-kernel at lists dot infradead dot org, linux-arch at vger dot kernel dot org, Okamoto Takayuki <tokamoto at jp dot fujitsu dot com>, libc-alpha at sourceware dot org, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Will Deacon <will dot deacon at arm dot com>, Alex Bennée <alex dot bennee at linaro dot org>, kvmarm at lists dot cs dot columbia dot edu
- Date: Wed, 1 Nov 2017 11:43:29 +0000
- Subject: Re: [PATCH v5 03/30] arm64: signal: Verify extra data is user-readable in sys_rt_sigreturn
- Authentication-results: sourceware.org; auth=none
- References: <1509465082-30427-1-git-send-email-Dave.Martin@arm.com> <1509465082-30427-4-git-send-email-Dave.Martin@arm.com>
On Tue, Oct 31, 2017 at 03:50:55PM +0000, Dave P Martin wrote:
> Currently sys_rt_sigreturn() verifies that the base sigframe is
> readable, but no similar check is performed on the extra data to
> which an extra_context record points.
>
> This matters because the extra data will be read with the
> unprotected user accessors. However, this is not a problem at
> present because the extra data base address is required to be
> exactly at the end of the base sigframe. So, there would need to
> be a non-user-readable kernel address within about 59K
> (SIGFRAME_MAXSZ - sizeof(struct rt_sigframe)) of some address for
> which access_ok(VERIFY_READ) returns true, in order for sigreturn
> to be able to read kernel memory that should be inaccessible to the
> user task. This is currently impossible due to the untranslatable
> address hole between the TTBR0 and TTBR1 address ranges.
>
> Disappearance of the hole between the TTBR0 and TTBR1 mapping
> ranges would require the VA size for TTBR0 and TTBR1 to grow to at
> least 55 bits, and either the disabling of tagged pointers for
> userspace or enabling of tagged pointers for kernel space; none of
> which is currently envisaged.
>
> Even so, it is wrong to use the unprotected user accessors without
> an accompanying access_ok() check.
>
> To avoid the potential for future surprises, this patch does an
> explicit access_ok() check on the extra data space when parsing an
> extra_context record.
>
> Fixes: 33f082614c34 ("arm64: signal: Allow expansion of the signal frame")
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>