linux-user: Fix broken m68k signal handling on 64 bit hosts

The m68k signal frame setup code which writes the signal return
trampoline code to the stack was assuming that a 'long' was 32 bits;
on 64 bit systems this meant we would end up writing the 32 bit
(2 insn) trampoline sequence to retaddr+4,retaddr+6 instead of
the intended retaddr+0,retaddr+2, resulting in a guest crash when
it tried to execute the invalid zero-bytes at retaddr+0.
Fix by using uint32_t instead; also use uint16_t rather than short
for consistency. This fixes bug LP:1404690.

Reported-by: Michel Boaventura
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 linux-user/signal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

22.12.2014 20:47, Peter Maydell wrote:
> The m68k signal frame setup code which writes the signal return
> trampoline code to the stack was assuming that a 'long' was 32 bits;
> on 64 bit systems this meant we would end up writing the 32 bit
> (2 insn) trampoline sequence to retaddr+4,retaddr+6 instead of
> the intended retaddr+0,retaddr+2, resulting in a guest crash when
> it tried to execute the invalid zero-bytes at retaddr+0.
> Fix by using uint32_t instead; also use uint16_t rather than short
> for consistency. This fixes bug LP:1404690.

Cc: qemu-stable@ ?

Thanks,

/mjt

On 25 December 2014 at 05:10, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 22.12.2014 20:47, Peter Maydell wrote:
>> The m68k signal frame setup code which writes the signal return
>> trampoline code to the stack was assuming that a 'long' was 32 bits;
>> on 64 bit systems this meant we would end up writing the 32 bit
>> (2 insn) trampoline sequence to retaddr+4,retaddr+6 instead of
>> the intended retaddr+0,retaddr+2, resulting in a guest crash when
>> it tried to execute the invalid zero-bytes at retaddr+0.
>> Fix by using uint32_t instead; also use uint16_t rather than short
>> for consistency. This fixes bug LP:1404690.
>
> Cc: qemu-stable@ ?

Yeah, seems reasonable (though this has been busted for five
years, so I deduce that nobody's actually trying to use it...)

-- PMM

Ping?

thanks
-- PMM

On 22 December 2014 at 17:47, Peter Maydell <peter.maydell@linaro.org> wrote:
> The m68k signal frame setup code which writes the signal return
> trampoline code to the stack was assuming that a 'long' was 32 bits;
> on 64 bit systems this meant we would end up writing the 32 bit
> (2 insn) trampoline sequence to retaddr+4,retaddr+6 instead of
> the intended retaddr+0,retaddr+2, resulting in a guest crash when
> it tried to execute the invalid zero-bytes at retaddr+0.
> Fix by using uint32_t instead; also use uint16_t rather than short
> for consistency. This fixes bug LP:1404690.
>
> Reported-by: Michel Boaventura
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  linux-user/signal.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index e11b208..a324fd1 100644
> --- a/linux-user/signal.c
> +++ b/linux-user/signal.c
> @@ -5091,7 +5091,7 @@ static void setup_frame(int sig, struct target_sigaction *ka,
>      /* moveq #,d0; trap #0 */
>
>      __put_user(0x70004e40 + (TARGET_NR_sigreturn << 16),
> -                      (long *)(frame->retcode));
> +                      (uint32_t *)(frame->retcode));
>
>      /* Set up to return from userspace */
>
> @@ -5225,8 +5225,8 @@ static void setup_rt_frame(int sig, struct target_sigaction *ka,
>      /* moveq #,d0; notb d0; trap #0 */
>
>      __put_user(0x70004600 + ((TARGET_NR_rt_sigreturn ^ 0xff) << 16),
> -               (long *)(frame->retcode + 0));
> -    __put_user(0x4e40, (short *)(frame->retcode + 4));
> +               (uint32_t *)(frame->retcode + 0));
> +    __put_user(0x4e40, (uint16_t *)(frame->retcode + 4));
>
>      if (err)
>          goto give_sigsegv;