Received: by 10.213.65.68 with SMTP id h4csp3584635imn; Tue, 10 Apr 2018 01:03:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx49WHZdTaFlWjAYwQ1DaRlpO12buvBiTcCA3UAHqoNJPpz7rX0o+jUodOu8TqAJY65UndRdl X-Received: by 2002:a17:902:579d:: with SMTP id l29-v6mr12611693pli.163.1523347402342; Tue, 10 Apr 2018 01:03:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523347402; cv=none; d=google.com; s=arc-20160816; b=ZROhP6yz0EWEUlwkcofbWKnX9netWj+PlaWantJw9MoY0f5rov9GQuYQiWliNY2nSI nLsCFGfyvNeD9axUyWQcMtVZXdaDpCWxcVrSlb/xXcKWUClU+qIEG+Vjs5xdq3rWhNMV IKZFwwv/LIhHH5AQaoOYH0gep9fxGphZMSSJzufLblnCvur2dxN7SXTIKZgKEZI3hCJm qEJjivYN1R/N1yKFN/wOFk5LYsD09UYX+HvsajAHyCwBPHIuzhKhVgBauHg9P9+EvUGO ejgTKyDgYNa3xwavQYT4qRWnKbhrZtQlfEIwJmWvjUnrJD0/yl/BGtkrGAW4t7Cquis7 CR4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=T9ls1kOcCcrRgAX/qdHSsvHf0WCo+thboIIs5NUjP+s=; b=yK32oA5BVlGOLUVpDXb9/GzXX6wAhnL5O8QtzGFMchqUmXZgtz6MsO6PCLAG1doHke Blaqt2rk8FaV/pRCGMsR2FDWovEM/9eDPAar1IhUceK9BNiksLmDgo4sJj/LEPUFdYNz gR51U8hMm72k0jSEbgDCEN8sA/isqyAaY/UAdCJVi4ApkGyxXVZEGc8X41wx8P6kVC25 TqMkV7eQjMbAty+Kw0vwbM6GqvvXBC/zOWOraRpaCGD7xtmZst6D2q3G+4g+956I/Wra XhjP7bZxZBNufqKu7EFnM0CATL8/u37LcfdgP3nIL/2w+vejE+g7yR46bPltKPe1Gu82 o/cQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Wf521M3C; 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 62si1641823pfw.173.2018.04.10.01.02.45; Tue, 10 Apr 2018 01:03:22 -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; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Wf521M3C; 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 S1752565AbeDJH7M (ORCPT + 99 others); Tue, 10 Apr 2018 03:59:12 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:56049 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752274AbeDJH7K (ORCPT ); Tue, 10 Apr 2018 03:59:10 -0400 Received: by mail-wm0-f46.google.com with SMTP id b127so24192501wmf.5 for ; Tue, 10 Apr 2018 00:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=T9ls1kOcCcrRgAX/qdHSsvHf0WCo+thboIIs5NUjP+s=; b=Wf521M3CRiVssf8c8iLL7Wx+qrD7ugUAybzCTovfXVrfnjf6OOMs7zrfg9iIoDDhL5 e25pUdOCdVUubgNws7429V7RCTK/04Xv+HMj5vznAoZmEZVr98rGwAgUgMUNZUGNwQ+E QLpDYOJ3r3xPJGtEX3gtlk9yLZmAnUKyNc6hUyBDftLrNE5UCmK2EFDIlYxG8FeDxRbp /YVAo1NNGjSAPK/mO6XswT/PUU2VLEsNgigPg+phfJAxQmzAWx1NhMFJ6uKiyxzUwMsn yCjqCQlci+lOWpoZHYzNWhTORa/6gGN1Sv9Mvz1QmtJHFLfiydqbk93ciVgpv8ciBL9K KBzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=T9ls1kOcCcrRgAX/qdHSsvHf0WCo+thboIIs5NUjP+s=; b=Os2ZwoOlpErHVSYOmtgVd0NywNLjjRiub9cpNH6WcHwbzXRtQgViTi548uZbJMSSPe wKt3afdKgQzmDMbtV8hpvyPc6DzzEaC0DdO1d2eQbYAninKcbf59YRmo0Fl+m9lEJPTO J7M2tFFmOM4c4FHKG6o9rLBv3N54apGKlSGaic5dDzVvmYei2ZiMNXPUJpWDK5tHsa/M md+4diPGMk5svNSqGhNzwU0gEp75bul9SqwzFVlTkCquE7FszaJVL7kzNHUNkIs7IG1J BT9nA6+rmZJiBaL9UnOOtBa9MFHGHNpJvWJi2iqeLv50gOezLA+TPeaXw1dWrQvlwm5b zOpQ== X-Gm-Message-State: ALQs6tAQdk8JW7ngQquzYPtUo/mkimBJHCaYsYGBZOzAkettYO0oosbu jqZvJ0sXdcIVpz6M/gxydOlbYg== X-Received: by 10.80.152.55 with SMTP id g52mr1662931edb.31.1523347149688; Tue, 10 Apr 2018 00:59:09 -0700 (PDT) Received: from node.shutemov.name (mm-234-69-122-178.brest.dynamic.pppoe.byfly.by. [178.122.69.234]) by smtp.gmail.com with ESMTPSA id y28sm1536557edc.0.2018.04.10.00.59.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 00:59:08 -0700 (PDT) Received: by node.shutemov.name (Postfix, from userid 1000) id 9305F648D520; Tue, 10 Apr 2018 10:58:22 +0300 (+03) Date: Tue, 10 Apr 2018 10:58:22 +0300 From: "Kirill A. Shutemov" To: Eric Biggers Cc: Davidlohr Bueso , linux-mm@kvack.org, Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, "Kirill A . Shutemov" , Manfred Spraul , "Eric W . Biederman" , syzkaller-bugs@googlegroups.com Subject: Re: [PATCH] ipc/shm: fix use-after-free of shm file via remap_file_pages() Message-ID: <20180410075822.wspmi4imsp3s7m27@node.shutemov.name> References: <94eb2c06f65e5e2467055d036889@google.com> <20180409043039.28915-1-ebiggers3@gmail.com> <20180409094813.bsjc3u2hnsrdyiuk@black.fi.intel.com> <20180409185016.GA203367@gmail.com> <20180409201232.3rweldbjtvxjj5ql@linux-n805> <20180409203635.GD203367@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180409203635.GD203367@gmail.com> User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 09, 2018 at 01:36:35PM -0700, Eric Biggers wrote: > On Mon, Apr 09, 2018 at 01:12:32PM -0700, Davidlohr Bueso wrote: > > On Mon, 09 Apr 2018, Eric Biggers wrote: > > > > > It's necessary because if we don't hold a reference to sfd->file, then it can be > > > a stale pointer when we compare it in __shm_open(). In particular, if the new > > > struct file happened to be allocated at the same address as the old one, then > > > 'sfd->file == shp->shm_file' so the mmap would be allowed. But, it will be a > > > different shm segment than was intended. The caller may not even have > > > permissions to map it normally, yet it would be done anyway. > > > > > > In the end it's just broken to have a pointer to something that can be freed out > > > from under you... > > > > So this is actually handled by shm_nattch, serialized by the ipc perm->lock. > > shm_destroy() is called when 0, which in turn does the fput(shm_file). Note > > that shm_file is given a count of 1 when a new segment is created (deep in > > get_empty_filp()). So I don't think the pointer is going anywhere, or am I missing > > something? > > > > Thanks, > > Davidlohr > > In the remap_file_pages() case, a reference is taken to the ->vm_file, then the > segment is unmapped. If that brings ->shm_nattch to 0, then the underlying shm > segment and ID can be removed, which (currently) causes the real shm file to be > freed. But, the outer file still exists and will have ->mmap() called on it. > That's why the outer file needs to hold a reference to the real shm file. Okay, fair enough. Logic in SysV IPC implementation is often hard to follow. Could you include the description in the commit message? And feel free to use my Acked-by: Kirill A. Shutemov -- Kirill A. Shutemov