On 16 April 2018 at 20:42, Richard Henderson <richard.hender...@linaro.org> 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 <peter.mayd...@linaro.org> >> --- >> 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 <richard.hender...@linaro.org>
Applied, thanks. -- PMM
