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]

Message-ID: <87zgbsno9y.ffs@tglx>
Date:   Tue, 13 Dec 2022 01:24:57 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     stsp <stsp2@...dex.ru>, linux-kernel@...r.kernel.org
Cc:     x86@...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 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)

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