linux-kernel - Re: strange behavior with sigreturn() to 32bit

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

Date:   Tue, 13 Dec 2022 00:38:04 +0000
From:   Andrew Cooper <Andrew.Cooper3@...rix.com>
To:     Thomas Gleixner <tglx@...utronix.de>, stsp <stsp2@...dex.ru>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "x86@...nel.org" <x86@...nel.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Andrew Cooper <Andrew.Cooper3@...rix.com>
Subject: Re: strange behavior with sigreturn() to 32bit

On 13/12/2022 00:24, Thomas Gleixner wrote:
> On Sat, Dec 10 2022 at 14:08, stsp wrote:
>
> Can you please Cc LKML on such mails? x86_64@...r.kernel.org is not used
> by any x86 maintainer as you can figure out from looking at the
> MAINTAINERS file in the kernel.
>
>> I am playing with 32bit compatibility segments, and I am observing
>> something very strange.  To demonstrate the problem, I did the change
>> to the kernel sigreturn test-case, and it is attached.  The change
>> just moves the magic value to EAX and calls an interrupt that produces
>> a SIGSEGV.  The SIGSEGV handler prints the needed regs.  This patch
>> intentionally adds 0x100000000 to the RIP register, because AFAIK the
>> high part or 64bit regs are irrelevant in compatibility mode.
>>
>> Now with high part of RIP non-zero, we see this:
>> $ ./sigreturn_64
>> err=0 trapno=d ax=0 ip=100000003
> I just applied the patch and on a 6.1 kernel I get:
>
> # ./sigreturn_64 
> [OK]	set_thread_area refused 16-bit data
> [OK]	set_thread_area refused 16-bit data
> [RUN]	Valid sigreturn: 64-bit CS (33), 32-bit SS (2b, GDT)
> [OK]	all registers okay
> [RUN]	Valid sigreturn: 32-bit CS (23), 32-bit SS (2b, GDT)
> [NOTE]	SP: 8badf00d5aadc0de -> 5aadc0de
> [OK]	all registers okay
> [RUN]	Valid sigreturn: 16-bit CS (37), 32-bit SS (2b, GDT)
>
>   err=0 trapno=d ax=a5f3 ip=6
>
> Let's look at the disassmbly:
>
> 0000000000403000 <int3>:
>   403000:       8c d1                   mov    %ss,%ecx
>   403002:       cc                      int3
>
> 0000000000403003 <int31>:
>   403003:       b8 f3 a5 00 00          mov    $0xa5f3,%eax
>   403008:       cd 31                   int    $0x31
>
> which is expected and correct:
>
> trapno = 0xd = 13 = #GP
> ax     = the magic value
> ip     = 6 (Offset to the 'int3:' label in the 16bit CS)
> err    = 0
>
> Both 'ip' and 'err' are completely correct here. Why?
>
> The #GP's on 403006. Because in 16bit mode the CPU the disassmbly looks
> like this:
>
>   403003:       b8 f3 a5	        mov    $0xa5f3,%eax
>   403006:	00 00                   add    %al, (%bx, %si)

That's `mov $0xa5f3,%ax` rather than %eax, but otherwise yes.

~Andrew

>
> so 403006 which is offset 6 into the 16bit CS translates to:
>
>       bx[si] += al;
>
> so in my case:
>
>       bx=0x0 si=0x2903e6d0
>
> which is clearly outside of the DS segment limit resulting in a #GP with
> error code == 0.
>
> Your observation that running this under GDB changes the behaviour of
> the error is completely correct because BX/SI are subject to context. So
> depending where the combo points to it results in random behaviour.
>
> So nothing strange to see here, really. You got what you asked for:
>
>> I am playing with ....
> Thanks,
>
>         tglx