Received: by 10.192.165.148 with SMTP id m20csp4181516imm; Mon, 30 Apr 2018 13:20:34 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpnPu/ylkMnnKiMnppGQ4gx1U27nXiQ2QAOq8FKpSGTJRfJycYjP698j+esHzDVpLZpGXzE X-Received: by 2002:a17:902:5402:: with SMTP id d2-v6mr13764097pli.386.1525119634742; Mon, 30 Apr 2018 13:20:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525119634; cv=none; d=google.com; s=arc-20160816; b=Q9gkMPYLJ/KzvDPC+VYSxGiuojp6q3KzaIhJZEv9jsTKBXX1Y0pTsdyPeP5FVg4YTy OG3j1FLhd4eODTIZowsAnA3QOCOamDtYypTvEUfeZogDkaS/7EanSkfjXh8HKr3LvCNW pX9JDGjwIPem5QifgsmZeHxPKEwwl3LNckrupQNgbo7Vx+Ua/rDQSn9EJxITBAgQq7G+ rtR6uNv/odelqGykoeBhyiZMuiRzzf0CFXj/HUm2LMpjNfTKQ89TQbRn+LPizzEjuE74 orflaOdk6yCbc2yuSVSZ4xg2u2MeZZJ+ec1/9/J47PnJ7vTriBk9vFF0w20s5j13HdR8 WHtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dmarc-filter :arc-authentication-results; bh=kOIdh2eCzQq5jn7nxWyjzsiADp36PFFMXEfRhqM4aWY=; b=PX9MN/RNAtoS1b/7Qe80SKDwAF6ba5r5FiKP2SQYkrq7ONpy07I22ZMGqe2teMh8Yy gqVd/gE/Rucj9V5sM6JB7tBUqwBMMzlfv75m1fvav17+NrLLs/0s31/B+QRIRrHD9GN9 fBGwlLXb7t7t+N2n1CQk4s+ERCfVaQD8yVx4hMYH73QC3PwoiuX1g0yEqkf/f84HnoXG uEgare179Aig4P1OEPkmk64E7I4WpdGgLQlQCnoNpvaksJISyJg7DI/ZO7m+YTNrKtfH xCF93Khm3KE3qW8mh/uDZ+xS5lOHFONDbvjbUf8ss/YiZ5kEOBDNXRMhKSXmyQKB5sc3 8Qlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p13-v6si8099473pll.416.2018.04.30.13.20.20; Mon, 30 Apr 2018 13:20:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756130AbeD3UUJ (ORCPT + 99 others); Mon, 30 Apr 2018 16:20:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:60634 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755772AbeD3T0q (ORCPT ); Mon, 30 Apr 2018 15:26:46 -0400 Received: from localhost (unknown [104.132.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0B8C622DC0; Mon, 30 Apr 2018 19:26:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B8C622DC0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Thomas Gleixner , "H . J . Lu" , Jeffrey Walton , "H. Peter Anvin" Subject: [PATCH 4.9 58/61] x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds Date: Mon, 30 Apr 2018 12:25:01 -0700 Message-Id: <20180430183956.206685084@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430183951.312721450@linuxfoundation.org> References: <20180430183951.312721450@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Arnd Bergmann commit 1a512c0882bd311c5b5561840fcfbe4c25b8f319 upstream. A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout (as seen from user space) a few years ago: Originally, __BITS_PER_LONG was defined as 64 on x32, so we did not have padding after the 64-bit __kernel_time_t fields, After __BITS_PER_LONG got changed to 32, applications would observe extra padding. In other parts of the uapi headers we seem to have a mix of those expecting either 32 or 64 on x32 applications, so we can't easily revert the path that broke these two structures. Instead, this patch decouples x32 from the other architectures and moves it back into arch specific headers, partially reverting the even older commit 73a2d096fdf2 ("x86: remove all now-duplicate header files"). It's not clear whether this ever made any difference, since at least glibc carries its own (correct) copy of both of these header files, so possibly no application has ever observed the definitions here. Based on a suggestion from H.J. Lu, I tried out the tool from https://github.com/hjl-tools/linux-header to find other such bugs, which pointed out the same bug in statfs(), which also has a separate (correct) copy in glibc. Fixes: f4b4aae18288 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Cc: "H . J . Lu" Cc: Jeffrey Walton Cc: stable@vger.kernel.org Cc: "H. Peter Anvin" Link: https://lkml.kernel.org/r/20180424212013.3967461-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/uapi/asm/msgbuf.h | 31 +++++++++++++++++++++++++++ arch/x86/include/uapi/asm/shmbuf.h | 42 +++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) --- a/arch/x86/include/uapi/asm/msgbuf.h +++ b/arch/x86/include/uapi/asm/msgbuf.h @@ -1 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef __ASM_X64_MSGBUF_H +#define __ASM_X64_MSGBUF_H + +#if !defined(__x86_64__) || !defined(__ILP32__) #include +#else +/* + * The msqid64_ds structure for x86 architecture with x32 ABI. + * + * On x86-32 and x86-64 we can just use the generic definition, but + * x32 uses the same binary layout as x86_64, which is differnet + * from other 32-bit architectures. + */ + +struct msqid64_ds { + struct ipc64_perm msg_perm; + __kernel_time_t msg_stime; /* last msgsnd time */ + __kernel_time_t msg_rtime; /* last msgrcv time */ + __kernel_time_t msg_ctime; /* last change time */ + __kernel_ulong_t msg_cbytes; /* current number of bytes on queue */ + __kernel_ulong_t msg_qnum; /* number of messages in queue */ + __kernel_ulong_t msg_qbytes; /* max number of bytes on queue */ + __kernel_pid_t msg_lspid; /* pid of last msgsnd */ + __kernel_pid_t msg_lrpid; /* last receive pid */ + __kernel_ulong_t __unused4; + __kernel_ulong_t __unused5; +}; + +#endif + +#endif /* __ASM_GENERIC_MSGBUF_H */ --- a/arch/x86/include/uapi/asm/shmbuf.h +++ b/arch/x86/include/uapi/asm/shmbuf.h @@ -1 +1,43 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef __ASM_X86_SHMBUF_H +#define __ASM_X86_SHMBUF_H + +#if !defined(__x86_64__) || !defined(__ILP32__) #include +#else +/* + * The shmid64_ds structure for x86 architecture with x32 ABI. + * + * On x86-32 and x86-64 we can just use the generic definition, but + * x32 uses the same binary layout as x86_64, which is differnet + * from other 32-bit architectures. + */ + +struct shmid64_ds { + struct ipc64_perm shm_perm; /* operation perms */ + size_t shm_segsz; /* size of segment (bytes) */ + __kernel_time_t shm_atime; /* last attach time */ + __kernel_time_t shm_dtime; /* last detach time */ + __kernel_time_t shm_ctime; /* last change time */ + __kernel_pid_t shm_cpid; /* pid of creator */ + __kernel_pid_t shm_lpid; /* pid of last operator */ + __kernel_ulong_t shm_nattch; /* no. of current attaches */ + __kernel_ulong_t __unused4; + __kernel_ulong_t __unused5; +}; + +struct shminfo64 { + __kernel_ulong_t shmmax; + __kernel_ulong_t shmmin; + __kernel_ulong_t shmmni; + __kernel_ulong_t shmseg; + __kernel_ulong_t shmall; + __kernel_ulong_t __unused1; + __kernel_ulong_t __unused2; + __kernel_ulong_t __unused3; + __kernel_ulong_t __unused4; +}; + +#endif + +#endif /* __ASM_X86_SHMBUF_H */