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: <159B3D01-132C-4F56-ABF0-72A8D5958A29@jrtc27.com>
Date:   Fri, 30 Oct 2020 19:21:03 +0000
From:   Jessica Clarke <jrtc27@...c27.com>
To:     linux-x86_64@...r.kernel.org
Cc:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] x86: Fix x32 System V message queue syscalls

> On 12 Oct 2020, at 14:44, Jessica Clarke <jrtc27@...c27.com> wrote:
> 
> POSIX specifies that the first field of the supplied msgp, namely mtype,
> is a long, not a __kernel_long_t, and it's a user-defined struct due to
> the variable-length mtext field so we can't even bend the spec and make
> it a __kernel_long_t even if we wanted to. Thus we must use the compat
> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
> msgrcv respectively.
> 
> Due to erroneously including the first 4 bytes of mtext in the mtype
> this would previously also cause non-zero msgtyp arguments for msgrcv to
> search for the wrong messages, and if sharing message queues between x32
> and non-x32 (i386 or x86_64) processes this would previously cause mtext
> to "move" and, depending on the direction and ABI combination, lose the
> first 4 bytes.
> 
> Signed-off-by: Jessica Clarke <jrtc27@...c27.com>
> ---

Ping?

Jess

> 
> I have verified that the test at the end of [1] now gives the correct
> result on x32 ("PAYL" not "PAY" as I erroneously claimed it should be in
> the above email) and that both i386 and amd64 give the same output with
> that test as before.
> 
> [1] <1156938F-A9A3-4EE9-B059-2294A0B9FBFE@...c27.com>
> 
> Changes since v1:
> * Uses the same syscall numbers for x32 as amd64 and the current x32
>   rather than (further) breaking ABI by allocating new ones from the
>   legacy x32 range
> 
> arch/x86/entry/syscalls/syscall_64.tbl | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
> index f30d6ae9a..f462123f3 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -77,8 +77,10 @@
> 66	common	semctl			sys_semctl
> 67	common	shmdt			sys_shmdt
> 68	common	msgget			sys_msgget
> -69	common	msgsnd			sys_msgsnd
> -70	common	msgrcv			sys_msgrcv
> +69	64	msgsnd			sys_msgsnd
> +69	x32	msgsnd			compat_sys_msgsnd
> +70	64	msgrcv			sys_msgrcv
> +70	x32	msgrcv			compat_sys_msgrcv
> 71	common	msgctl			sys_msgctl
> 72	common	fcntl			sys_fcntl
> 73	common	flock			sys_flock
> -- 
> 2.28.0
>