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

Message-ID: <6ecb3a57-f552-500f-c853-023f95304bc2@yandex.ru>
Date:   Tue, 13 Dec 2022 09:18:25 +0500
From:   stsp <stsp2@...dex.ru>
To:     Thomas Gleixner <tglx@...utronix.de>, 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

Hi,

13.12.2022 05:24, Thomas Gleixner пишет:
> 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:
Thanks for checking, so some problems
were not valid ones, but lets remove the
mov to eax from the test.

Without gdb:
err=0 trapno=d ax=0 ip=100000003

With gdb:
err=18a trapno=d ax=0 ip=403003

Without high RIP poison:
err=18a trapno=d ax=0 ip=3
This case is perfectly valid now, thanks.

Without high RIP poison and with gdb:
err=18a trapno=d ax=0 ip=403003

So under gdb we still see the wrong RIP
value and high RIP part breaks things
only without gdb (gdb "fixes" it).

Attaching the new diff that doesn't do
the mov to eax, so should be correct now.
View attachment "a.diff" of type "text/x-patch" (2432 bytes)