qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [prefix=PATCH for-2.12?] linux-user: check t


From: Peter Maydell
Subject: Re: [Qemu-arm] [Qemu-devel] [prefix=PATCH for-2.12?] linux-user: check that all of AArch64 SVE extended sigframe is writable
Date: Tue, 17 Apr 2018 12:52:06 +0100

On 16 April 2018 at 20:42, Richard Henderson
<address@hidden> wrote:
> On 04/16/2018 05:19 AM, Peter Maydell wrote:
>> In commit 8c5931de0ac7738809 we added support for SVE extended
>> sigframe records.  These mean that the signal frame might now be
>> larger than the size of the target_rt_sigframe record, so make sure
>> we call lock_user on the entire frame size when we're creating it.
>> (The code for restoring the signal frame already correctly handles
>> the extended records by locking the 'extra' section separately to the
>> main section.)
>>
>> In particular, this fixes a bug even for non-SVE signal frames,
>> because it extends the locked section to cover the
>> target_rt_frame_record. Previously this was part of 'struct
>> target_rt_sigframe', but in commit e1eecd1d9d4c1ade3 we pulled
>> it out into its own struct, and so locking the target_rt_sigframe
>> alone doesn't cover it. This bug would mean that we would fail
>> to correctly handle the case where a signal was taken with
>> SP pointing 16 bytes into an unwritable page, with the page
>> immediately below it in memory being writable.
>>
>> Signed-off-by: Peter Maydell <address@hidden>
>> ---
>> The requirements to trigger the bug sound implausible, except
>> that the stack page might be unwritable because we just
>> executed some trampoline code from it, so perhaps not so
>> unlikely as it first seems? Not sure whether to put into 2.12
>> or not...
>> ---
>>  linux-user/signal.c | 7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> Yes, let's just go ahead and fix this all properly now.
> Reviewed-by: Richard Henderson <address@hidden>

Applied, thanks.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]