From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A345C433DB for ; Thu, 28 Jan 2021 07:42:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A7BBD64DD8 for ; Thu, 28 Jan 2021 07:42:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7BBD64DD8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 041536B0005; Thu, 28 Jan 2021 02:42:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F0CB36B0006; Thu, 28 Jan 2021 02:42:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DACFA6B006C; Thu, 28 Jan 2021 02:42:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id A3C176B0005 for ; Thu, 28 Jan 2021 02:42:10 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4FD01181AEF2A for ; Thu, 28 Jan 2021 07:42:10 +0000 (UTC) X-FDA: 77754390420.14.linen31_27143f72759d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 330F318229818 for ; Thu, 28 Jan 2021 07:42:10 +0000 (UTC) X-HE-Tag: linen31_27143f72759d X-Filterd-Recvd-Size: 3879 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 Jan 2021 07:42:08 +0000 (UTC) Received: from fsav103.sakura.ne.jp (fsav103.sakura.ne.jp [27.133.134.230]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 10S7g3qf004963; Thu, 28 Jan 2021 16:42:03 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav103.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav103.sakura.ne.jp); Thu, 28 Jan 2021 16:42:03 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav103.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 10S7g3Lk004960 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jan 2021 16:42:03 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH v3] mm: memdup_user*() should use same gfp flags To: Casey Schaufler , Andrew Morton Cc: Michal Hocko , linux-mm@kvack.org, Sabyrzhan Tasbolatov References: <20210126111315.858994-1-snovitoll@gmail.com> <20210127105538.4919-1-penguin-kernel@I-love.SAKURA.ne.jp> <3e01b180-0a5b-f2aa-6247-1c3bbcabe1ed@i-love.sakura.ne.jp> <20210127151940.a9fbbafb890fc769da1525ea@linux-foundation.org> <847543f8-491c-f5a5-39b6-561fefbc1219@schaufler-ca.com> From: Tetsuo Handa Message-ID: <3692c9b6-2729-4e27-dd0d-a2db47d1f7ae@i-love.sakura.ne.jp> Date: Thu, 28 Jan 2021 16:42:01 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <847543f8-491c-f5a5-39b6-561fefbc1219@schaufler-ca.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021/01/28 8:27, Casey Schaufler wrote: >>> There is no point with allowing userspace to allocate 2GB of physically non-contiguous >>> memory using kvmalloc(). Size is controlled by userspace, and memdup_user_nul() is used >>> for allocating temporary memory which will be released before returning to userspace. >>> >>> Sane userspace processes should allocate only one or a few pages using memdup_user_nul(). >>> Just making insane user processes (like fuzzer) fail memory allocation requests is a >>> reasonable decision. >> (cc Casey) >> >> I'd say that the immediate problem is in smk_write_syslog(). Obviously >> it was implemented expecting small writes, but the fuzzer is passing it a >> huge write and things fall apart. > > Yes, Smack should be checking that. Patch is in the works. Caller of memdup_user_nul() is responsible for making sure that size != -1 in order to avoid integer overflow overlooked by kmalloc(0) != NULL because memdup_user_nul() allocates size + 1 bytes. And this is automatically made sure for smackfs because vfs_write() makes sure that size <= (INT_MAX & PAGE_MASK) bytes. But some legitimate userspace might be already doing "write(fd, buffer, 20000);" for smk_write_onlycap()/smk_write_relabel_self(). How can you guarantee that introducing upper limit on the caller side does not break existing userspace tools? If some caller wants size > 32767 for memdup_user_nul(), it is just a matter of introducing vmemdup_user_nul(). memdup_user() and memdup_user_nul() had better behave similarly. There is no reason to use different gfp flags between memdup_user() and memdup_user_nul(). > I hates fuzzers. A surprising comment from security person. Smack is free to opt out of syzbot testing. :-)