linux-kernel - Re: [PATCH v2] x86: Fix x32 System V message queue syscalls

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: <87zg3b5j45.fsf@oldenburg.str.redhat.com>
Date:   Tue, 01 Aug 2023 09:15:06 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Harald van Dijk <harald@...awatt.nl>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Jessica Clarke <jrtc27@...c27.com>,
        Rich Felker <dalias@...c.org>, linux-x86_64@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86: Fix x32 System V message queue syscalls

* Harald van Dijk:

> There is one complication that I think has not been mentioned yet:
> when _GNU_SOURCE is defined, glibc does provide a definition of struct
> msghdr in <sys/msg.h> with a field "__syscall_slong_t mtype;". This
> makes it slightly more likely that there is code out there in the wild
> that works fine with current kernels and would be broken by the
> fix. Given how rare x32 is, and how rare message queues are, this may
> still be acceptable, but I am mentioning it just in case this would
> cause a different approach to be preferred. And whatever is done, a
> fix should also be submitted to glibc.

What should glibc do here?  Just change the definition in the header to
long and ignore the breakage?

Thanks,
Florian