Received: by 10.223.164.202 with SMTP id h10csp288890wrb; Wed, 29 Nov 2017 22:24:13 -0800 (PST) X-Google-Smtp-Source: AGs4zMbL1+aUrOkGlDfU34Wggs1KDzCR8o+4AFp5D9B9qcoBhaK7QeDNSjivWStsMT8SbC3aT+m5 X-Received: by 10.84.241.139 with SMTP id b11mr1527003pll.352.1512023052857; Wed, 29 Nov 2017 22:24:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512023052; cv=none; d=google.com; s=arc-20160816; b=YXv7BLtOjB8/cLus1FW6HPbEHj6mcrAKe7b4pem+78eyXv3xoUsJkkrtg4eT9sLMTF PpqYg3lah2a9hCJLvJ+bTP8tiUd9n4UUelOYsZiSstJrAyUhmcMz26Ok5cs/Ra91GnD6 BXfvOmRYp6VuyuXM6XJSYbL+8/Srt4Y/VtS8yoCYTfCcw1AcOIJySzGnbN23Qg5y057L qjbwPskieGK9Pfl0s5wZPEwfjtAp1VmtLYUysgjCUArbuWjSTG0H9a3C0RJhOR4MVZBw pz2Dbd1BacYeylLyJrcSFsqeD4jvlrID04qKqH4W5qGIUfogr+qF+ji0ehfmC7nGpH1Z /flQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=X9Ygmqbm+M14+yZbYIpa9z2EjFn1oxBKFUoJDQ1rypg=; b=Tv8afqHOy4cU0xYC62ga8+kXqkiVSs2QSgS0MtN+LX0xANlhcn1EjIy48iCHVQtbdH p1PW1ir19qdBTKd/ZcutOebjICrvNjWIh/jRXmRrfHkL242DtZqB0lAyQMwvoStqaTHU nlqgqsr1cAWEog1NTNQcVm3hV96V9DfZA6EkrT5+5xHFST3gLg41fSTqy+XJqhloqxtN LgKYa/25jwWKkN/6IU1JH2Uz1VkBMefb7vbO/YUVExiZSTiuqCw2q1Qg4a9/NA2rS4xd 26JW/AcWH7rAn+KNv5/qJO5bhNcaaiKEsQyRTB7aO8d62wzEy8I2Oeu5HRzF+lFH9WkC LZFQ== 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 j12si2526620pgf.678.2017.11.29.22.24.00; Wed, 29 Nov 2017 22:24:12 -0800 (PST) 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 S1753082AbdK3GXb (ORCPT + 99 others); Thu, 30 Nov 2017 01:23:31 -0500 Received: from relay-out3.mail.masterhost.ru ([83.222.12.13]:10104 "EHLO relay-out3.mail.masterhost.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752121AbdK3GXa (ORCPT ); Thu, 30 Nov 2017 01:23:30 -0500 Received: from [93.175.1.191] (helo=localhost.localdomain) by relay3.mail.masterhost.ru with esmtpa envelope from authenticated with philippe.mikoyan@skat.systems message id 1eKI5E-0001OR-B4; Thu, 30 Nov 2017 09:12:38 +0300 From: Philippe Mikoyan To: akpm@linux-foundation.org Cc: viro@zeniv.linux.org.uk, manfred@colorfullife.com, linux-kernel@vger.kernel.org, edgar.kaziakhmedov@virtuozzo.com, philippe.mikoyan@skat.systems Subject: [PATCH 0/2] ipc: Fix ctl(..IPC_STAT..) bugs Date: Thu, 30 Nov 2017 09:12:22 +0300 Message-Id: <20171130061224.25466-1-philippe.mikoyan@skat.systems> X-Mailer: git-send-email 2.11.0 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 119311 [Nov 30 2017] X-KLMS-AntiSpam-Version: 5.7.67.0 X-KLMS-AntiSpam-Envelope-From: philippe.mikoyan@skat.systems X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Info: LuaCore: 90 90 5dc5ed154507efaef166c077cc2b8afd8a7be26b, Auth:dkim=none, {DNS response errors} X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, not scanned, license restriction Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Some applications that uses System V IPC mechanisms rely on data structures that are returned by ctl(..IPC_STAT..) system calls. However, up to now information in these structures was not reliable, due to following reasons: 1) Non-atomic data structures filling process, which, for obvious reasons of not taking ipc lock, performed better - see: commit ac0ba20ea6f2 ("ipc,msg: make msgctl_nolock lockless") commit 16df3674efe3 ("ipc,sem: do not hold ipc lock more than necessary") commit c97cb9ccab8c ("ipc,shm: make shmctl_nolock lockless") 2) [Refer only to shared memory] Because shm_nattch is used by kernel as a ref_count, as a side effect it has to be increased twice in do_shmat in order not to lose segment before mmap and shm_open. These matters can lead, for example, to following unexpectable ipc data structures values: 1) When there are concurrently running shmat and shmctl(... IPC_STAT ...): {... shm_lpid = 0, shm_nattch = 1, ...} 2) If a shared memory segment was created just now and first process attaches, another process, concurrently checking number of shmat-s via shmctl(... IPC_STAT ...), can, at some point of time, get the following result: {... shm_nattch = 2, ...} Bug reproducing code can be found here: https://github.com/Phikimon/sysipc_break To catch bug you have to execute and kill bug reproducing program several times(one to five times, I guess). In this patchset I make an attempt to fix these bugs: 1) By taking locks before filling data structure fields. Note that lock is taken after permissions and security checks in order to increase performance. 2) By filling certain data structure fields directly in do_shmat in order to fill shm_nattch and other fields atomically. shm_open call is removed from shm_mmap. Philippe Mikoyan (2): ipc/shm: Fix shm_nattch incorrect value ipc: Fix ipc data structures inconsistency ipc/msg.c | 20 +++++++++++----- ipc/sem.c | 10 ++++++++ ipc/shm.c | 77 +++++++++++++++++++++++++++++++++----------------------------- ipc/util.c | 5 +++- 4 files changed, 69 insertions(+), 43 deletions(-) -- 2.11.0 From 1585600382782782577@xxx Fri Dec 01 16:39:21 +0000 2017 X-GM-THRID: 1585600382782782577 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread