From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-4145464-1516377054-2-1126903336115931276 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, 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='com', 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=1516377053; b=VYqZ2JHa0s1ONXKC2836y9RZV3P9fTLU9k/gEOR0sZ8ToWt y1neePh6Ctgg0pR6BeizatkbC+NRp13kakLJcBAb6rwk6lHKS/FZl2aj1v6IbnfO ldETyhL3igER2Fxdj4TEHfx3BKsuw1IpkkLicMPPtBrPlsi5Do1bv+uM55HiH09Y fOfBU4cxPXYkCTaeyiY7Cslc4Kfq65zAJxMpdlpEfZSBgygZteeA54RPUzjeAcqT Ya2ecV3Sh8JIDoEdmGyTispIJTJGg8W/QuXgI8Cqf4kq63dt22CqqEArAJ/YGzL4 U3YENx8gOi3OP/liksjA0mWHazfB/mIGJOMZeUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding:sender:list-id; s=arctest; t= 1516377053; bh=DhC/BQ2Svxg7cie0nISExRx0JImxfR7/QPEBM3xXt5g=; b=m 3CGUcqv7QhToIUjQo9xvpfFlglfozYxh0h/PTamlK4OFNnFghKt9blKweEjGWM/P rw65Kv0LldKxBxadwj79m5y5mO6UPxGOp++loIjhQTKlbP726+OIcnk2SbWYuUmA RXG2hv0LXEJnvjNTbVkdnKXTH8TIzZZHmoyjmpHeSvqc9QM87hQAwMP3Lm9X+Awr +iIiTcyl3zV2PWMgh8DcOQ13/4se5RaIuYCxlxcPcKC2S5gyo2wJI9CgG04EZJST A+qQaoLreOPA3LuZJ2Sp2XRE8R0ABOIR9Md9JpVRyC8t6mbNszSqKuLRe50D7Kw/ b2B4HXTOPPa2IIQUXvxsQ== ARC-Authentication-Results: i=1; mx3.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=android.com header.i=@android.com header.b=rsE1B+SR x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,has-list-id=yes,d=none) header.from=android.com; 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-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=PRVHEY7z; 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=android.com header.result=pass header_is_org_domain=yes Authentication-Results: mx3.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=android.com header.i=@android.com header.b=rsE1B+SR x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,has-list-id=yes,d=none) header.from=android.com; 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-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=PRVHEY7z; 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=android.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755936AbeASPuG (ORCPT ); Fri, 19 Jan 2018 10:50:06 -0500 Received: from mail-pf0-f181.google.com ([209.85.192.181]:41347 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755772AbeASPuC (ORCPT ); Fri, 19 Jan 2018 10:50:02 -0500 X-Google-Smtp-Source: ACJfBou8STdjbhMYkgX3ftLZrPzZCahGI2510aN3w/X2fqjNft9PCF3RVILcxfqm61cZb7YdNcwHDQ== Subject: Re: [PATCH] general protection fault in sock_has_perm To: Paul Moore Cc: linux-kernel@vger.kernel.org, Stephen Smalley , Eric Paris , James Morris , "Serge E. Hallyn" , selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org, stable@vger.kernel.org References: <20180118215853.228182-1-salyzyn@android.com> From: Mark Salyzyn Message-ID: <1f185712-9136-be88-02c0-5613a7683619@android.com> Date: Fri, 19 Jan 2018 07:49:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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 01/18/2018 02:36 PM, Paul Moore wrote: > On Thu, Jan 18, 2018 at 4:58 PM, 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 >> . . . >> [] 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. > I'm skeptical that this is the full solution for systems that lack the > SOCK_RCU_FREE protection. Is this really limited to just > setsockopt()? Maybe overstepped in my analysis and assumptions? This is a result of a fuzzer hitting an android 4.4 KASAN kernel. We (so far) have _not_ seen this with an android 4.9 KASAN kernel (which has the SOCK_RCU_FREE adjustments). There is no standalone duplication or PoC _except_ via the fuzzer. The rest of the statements stands based on this tidbit (statements of general good code hygiene, not 100% sure SOCK_RCU_FREE usage is completely covered, KISS solution etc). To be honest, yes, this may be a layer in the onion (swat this NULL check does not by itself solve the _problem_), I'd prefer kernel continuing on in a rational manner rather than panic ... and I have a gut feeling this could be a gratuitous NULL check if all the bugs in the network layer have been solved . Programming to solve a problem with one's gut is not a good practice, but hygiene is. This is 10 characters, and an estimated 1.2ns of added hygiene. No, I do not think this is limited to setsockopt, but would be willing to believe a multithreaded attack of any socket functions or ioctl would drop down to the check with sock_has_perm at possibly the wrong time in socket teardown. Sincerely -- Mark Salyzyn