From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-119847-1516383041-2-10663322173096375193 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.25, ME_NOAUTH 0.01, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='gov', MailFrom='org' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516383040; b=cAl9rdWNvMlbcb/0KiWeHP81Z0hj6cY5WzQEVzpfZDooDdY jLLaD2EZ6VmyMdmfl6KvpRfDBEJexTL29nAf+Jiwy6J1SNMTnBhLtPsVOvr1z4Je hn0WS/SlYx9K/3dthChW4uAZ7Ztp8fig1y/9+vqYb6xDzpjv97jTJF2KFLo9oG2e 23wGdqjRflt6JZFQQCdFKuTRPNyuEp9j/SXmSVedViCRD47xTTtwI5uW54cVywfy Bfu77CVBJB+JUBHjUIicQiCwZYNUp3mPsCBSUPCqgMVWvNf18YmmYNRJ99/1iLX2 KMs4SUbi+of82z/c2EMzfKQJH1/S3UNy2LLkfNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=message-id:subject:from:to:cc:date :in-reply-to:references:content-type:mime-version :content-transfer-encoding:sender:list-id; s=arctest; t= 1516383040; bh=dM6I2GThap66vBHbNXE9mClzF+czUixmghGaKYR0UEM=; b=j E/sXDMpWc4lCBgoFQVtdnIIwcAGGYLnax9FfZ2tMvgYl2qZS4CAgYCbQwDffMtIG ORnD8zy1ISfM13LrMSHgISgCYhePSAACjD/qski57uMAHwEZkEnbzCOMheXNPbfE 5J2la8HaW0IUBFtjOfUkY3g133+DfdE2Uzf2ivYwNPQP83B0wjEUFtwJ1cObW+OX 6jHjqgRTSA3S/3IVmMOg/X8J+SGR0jVYG5X/0bwVtsI3vHlGP8LWtxPDqzFnrj8j XwrVgrtiBIAzk+9hyUrPIppffgpOZTqYtT8MJnW237aBCvsR9OmjKtV7fRXk3NY5 0I6ZbkTAPSsMHXPeW963A== ARC-Authentication-Results: i=1; mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=tycho.nsa.gov; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=tycho.nsa.gov header.result=pass header_org.domain=nsa.gov header_org.result=pass header_is_org_domain=no Authentication-Results: mx5.messagingengine.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none (p=none,has-list-id=yes,d=none) header.from=tycho.nsa.gov; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=tycho.nsa.gov header.result=pass header_org.domain=nsa.gov header_org.result=pass header_is_org_domain=no Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932266AbeASRai (ORCPT ); Fri, 19 Jan 2018 12:30:38 -0500 Received: from uhil19pa09.eemsg.mail.mil ([214.24.21.82]:32626 "EHLO uhil19pa09.eemsg.mail.mil" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932231AbeASRah (ORCPT ); Fri, 19 Jan 2018 12:30:37 -0500 X-IronPort-AV: E=Sophos;i="5.46,382,1511827200"; d="scan'208";a="7804215" IronPort-PHdr: =?us-ascii?q?9a23=3AG4VYlRdsVhJPWKLGo364MJNZlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxc24Yx2N2/xhgRfzUJnB7Loc0qyK6/qmATJLuM7Z+Fk5M7V0Hycfjs?= =?us-ascii?q?sXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFRrwLxd6?= =?us-ascii?q?KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAmooQnLqsUbgIRuJrstxhfVv3BFZ/?= =?us-ascii?q?lYyWR0KFyJgh3y/N2w/Jlt8yRRv/Iu6ctNWrjkcqo7ULJVEi0oP3g668P3uxbD?= =?us-ascii?q?SxCP5mYHXWUNjhVIGQnF4wrkUZr3ryD3q/By2CiePc3xULA0RTGv5LplRRP0lC?= =?us-ascii?q?sKMSMy/XrJgcJskq1UvBOhpwR+w4HKZoGVKOF+db7Zcd8DWGZNQtpdWylHD4yy?= =?us-ascii?q?dYsPC/cKM/heoYfzulACqQKyCRewCO/qzDJDm3340rAg0+k5Eg/IwQwuEcwAvn?= =?us-ascii?q?vWotX1M7sdX+e6w6fH1jjDc/Fb1C3h5IXSbhwso/eBVq9wf8rLzkkvEhvIgEiM?= =?us-ascii?q?qYP7JzOV1voCs26G5OR9UOKgkWonqwVvrTmv28whjZLJiZ8Oyl3f6SV4wJo6Jd?= =?us-ascii?q?2/SEJhZ96kC4FfuzuVN4txXMMvWmdlszs5xL0eoZO3YScHxZs9yxPfdvCLaZaE?= =?us-ascii?q?7x39WOqLPDt1gm9udqiliBao60egz/XxVsyz0FlXsCVIisLMtnUR1xzL7ciHV+?= =?us-ascii?q?d98l+h2TmR0wDT7flJIVwumqrBKp4h36UwmoAPsUXDAiD2mEL2gLWQdko44ein?= =?us-ascii?q?9/7rYrDnpp+YL4N0iwf+PboymsGnHOg1PQcDU3Kb9OihzrHv40L0TKtQgvEriq?= =?us-ascii?q?XZtYrVJcUfpq63GQ9V1YMj5g6kDzi7y9QVhmUHLVJZdxKHiIjlIVfOIOviAvul?= =?us-ascii?q?jFSslylry+jcPrL9GpXNMmTDkLD5cLZm905T0hE8zdRB6J9PFLEBL+z8WlXruN?= =?us-ascii?q?zbEBA5KQq0zPjjCNln0YMeQ22PCLeDMKzOqV+I+v4vI+6UaY8RuTb9LeUl5vH3?= =?us-ascii?q?gX8ih1ASYbSp3YEWaHCkHvVqOkCZYX3xjdccFWcFoBEzTPLliFKcSz5ffXWyUL?= =?us-ascii?q?wm5jE9Fo2mCZ3PRoe3gLyOxC27BIFZZnhaClCQFnflb56EVOkWaCKdPMBsiTwE?= =?us-ascii?q?WqKlS48l1RCushX2xKZgLurR4icYr47s1MBp5+3PkhE/7T50AN6Y026TVGF4hG?= =?us-ascii?q?cISyUz3KB4u0x90FaD0bNjjvxfD9xc/e9GUgMkOpLG0+N6DNXyUBrbftiVUFam?= =?us-ascii?q?XsmmATYpQ90v298BeVx9G9S5jh3YxyqlGaUVl72QBJws9qLTxWT+KNhnx3bBzq?= =?us-ascii?q?khgEEsQtFTOm2+mq5/6w/TCpbRk0qDiqaqcb8R3DbX+2eeyWqCpURYUAl3UaXf?= =?us-ascii?q?Q38TfFfZrdP85knaVb+hFawnMhddyc6FMqZKbtzpjVNbRPbsIdjeYHy+m322BR?= =?us-ascii?q?mWwrOBd5Tqe2oD0yXHEkQEkB4c/WyANQcgAietuWXeDCZhFVj3eUPj7fF+qG+n?= =?us-ascii?q?Tk8z1wyKdFdu1761+x8Uhf2cTege0agCuCg8sTV0G1e90M/MB9WcoAphefYUXd?= =?us-ascii?q?RoxV5d1irivghsLI2mZ/R5j1oPYRVxl0ro2w9wC4kGms8v+jdiyAt0NLLd015b?= =?us-ascii?q?cT6c9Y7/N6eRKWTo+h2rLanM1QLwytGTr5wT5ew4plOrhwSgEk4v4j0zyNVO+2?= =?us-ascii?q?eN7ZXNSgwJWNT+VVhhpEsynK3TfiRov9Cc7nZrK6Th92aYg98=3D?= X-IPAS-Result: =?us-ascii?q?A2CXAQDJJ2Ja/wHyM5BeGQEBAQEBAQEBAQEBAQcBAQEBAYM?= =?us-ascii?q?VLYFaJ4NdmQRCAQEBAQEBBoE0mUmFRQKEYkMUAQEBAQEBAQEBAWoogjgkAYJGA?= =?us-ascii?q?QEBAQIBIwRSEAsYAgImAgJXBgESiAuCGwUIrzqBbTqKMwEBAQEBAQEDAQEBAQE?= =?us-ascii?q?BASGBD4M5ghWBD4Vegy8EgTiDToJlBYpNiHhfj1GVWIYNjgtImDI2IoFPKggCG?= =?us-ascii?q?AghD4JnYIF0HIIFIzcBihSCSwEBAQ?= Message-ID: <1516382386.2560.11.camel@tycho.nsa.gov> Subject: Re: [PATCH] general protection fault in sock_has_perm From: Stephen Smalley To: Mark Salyzyn , linux-kernel@vger.kernel.org Cc: Paul Moore , Eric Paris , James Morris , "Serge E. Hallyn" , selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org, stable@vger.kernel.org Date: Fri, 19 Jan 2018 12:19:46 -0500 In-Reply-To: <20180118215853.228182-1-salyzyn@android.com> References: <20180118215853.228182-1-salyzyn@android.com> Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.4 (3.26.4-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, 2018-01-18 at 13:58 -0800, Mark Salyzyn wrote: > general protection fault: 0000 [#1] PREEMPT SMP KASAN > CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b > #28 > task: ffff8801d1095f00 task.stack: ffff8800b5950000 > RIP: 0010:[] [] > sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069 > RSP: 0018:ffff8800b5957ce0 EFLAGS: 00010202 > RAX: dffffc0000000000 RBX: 1ffff10016b2af9f RCX: ffffffff81b69b51 > RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000010 > RBP: ffff8800b5957de0 R08: 0000000000000001 R09: 0000000000000001 > R10: 0000000000000000 R11: 1ffff10016b2af68 R12: ffff8800b5957db8 > R13: 0000000000000000 R14: ffff8800b7259f40 R15: 00000000000000d7 > FS: 00007f72f5ae2700(0000) GS:ffff8801db300000(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000a2fa38 CR3: 00000001d7980000 CR4: 0000000000160670 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Stack: > ffffffff81b69a1f ffff8800b5957d58 00008000b5957d30 0000000041b58ab3 > ffffffff83fc82f2 ffffffff81b69980 0000000000000246 ffff8801d1096770 > ffff8801d3165668 ffffffff8157844b ffff8801d1095f00 > ffff880000000001 > Call Trace: > [] selinux_socket_setsockopt+0x4d/0x80 > security/selinux/hooks.c:4338 > [] security_socket_setsockopt+0x7d/0xb0 > security/security.c:1257 > [] SYSC_setsockopt net/socket.c:1757 [inline] > [] SyS_setsockopt+0xe8/0x250 net/socket.c:1746 > [] entry_SYSCALL_64_fastpath+0x16/0x92 > Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8 > f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89 > fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00 > 00 41 8b 75 10 31 > RIP [] sock_has_perm+0x1fe/0x3e0 > security/selinux/hooks.c:4069 > RSP > ---[ end trace 7b5aaf788fef6174 ]--- > > In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket > flag") and all the associated infrastructure changes to take > advantage > of a RCU grace period before freeing, there is a heightened > possibility that a security check is performed while an ill-timed > setsockopt call races in from user space. It then is prudent to null > check sk_security, and if the case, reject the permissions. > > This adjustment is orthogonal to infrastructure improvements that may > nullify the needed check, but should be added as good code hygiene. > > Signed-off-by: Mark Salyzyn > Cc: Paul Moore > Cc: Stephen Smalley > Cc: Eric Paris > Cc: James Morris > Cc: "Serge E. Hallyn" > Cc: selinux@tycho.nsa.gov > Cc: linux-security-module@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: stable@vger.kernel.org > --- > This patch should be applied to all stable trees (author wants > minimum of 3.18, 4.4, 4.9 and 4.14) > > security/selinux/hooks.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 8644d864e3c1..95d7c8143373 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -4342,7 +4342,7 @@ static int sock_has_perm(struct sock *sk, u32 > perms) > struct common_audit_data ad; > struct lsm_network_audit net = {0,}; > > - if (sksec->sid == SECINITSID_KERNEL) > + if (!sksec || sksec->sid == SECINITSID_KERNEL) > return 0; The patch description says "null check the sk_security, and if the case, reject the permissions." The patch code instead has it return 0/success, i.e. permission granted. Which one is correct? If we return -EACCES, then we might break userspace; if we return 0, we might be allowing an operation that should have been denied. Both seem like losing propositions. Could we instead have selinux_sk_free_security() defer freeing of the sock security blob to a call_rcu(), like we did for inode_free_security, or change the caller of it to not free it until the sock is truly freed? > > ad.type = LSM_AUDIT_DATA_NET;