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;
From:   Will Deacon <will@kernel.org>
To:     selinux@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
        Paul Moore <paul@paul-moore.com>,
        Ondrej Mosnacek <omosnace@redhat.com>,
        Stephen Smalley <sds@tycho.nsa.gov>,
        Jeffrey Vander Stoep <jeffv@google.com>
Subject: [RFC PATCH 0/2] Avoid blocking in selinux inode callbacks on RCU walk
Date:   Tue, 19 Nov 2019 18:40:55 +0000
Message-Id: <20191119184057.14961-1-will@kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi all,

While debugging a KASAN report in the selinux access vector cache hash
table, I noticed that it looks like we may block in the inode_follow_link()
and inode_permission() callbacks, even when called from the VFS layer as
part of an RCU-protected path walk.

These two patches attempt to fix that, but since I found this by
inspection and I'm not familiar with this code, I'm sending as an RFC in
case I missed something that means this cannot happen.

Comments very welcome,

Will

Cc: Paul Moore <paul@paul-moore.com>
Cc: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Jeffrey Vander Stoep <jeffv@google.com>

--->8

Will Deacon (2):
  selinux: Don't call avc_compute_av() from RCU path walk
  selinux: Propagate RCU walk status from 'security_inode_follow_link()'

 security/selinux/avc.c         | 21 +++++++++++++--------
 security/selinux/hooks.c       |  5 +++--
 security/selinux/include/avc.h | 12 ++++++++----
 3 files changed, 24 insertions(+), 14 deletions(-)

-- 
2.24.0.432.g9d3f5f5b63-goog