Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5819170ybl; Tue, 14 Jan 2020 15:47:26 -0800 (PST) X-Google-Smtp-Source: APXvYqzXRDgamdM5fvvDtWuI0L7+pi1pFBrdDw1RWthQZ4lloWd38lQnOtPAwPPeo2CLa4u1vU+t X-Received: by 2002:aca:eb83:: with SMTP id j125mr17827673oih.153.1579045646733; Tue, 14 Jan 2020 15:47:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579045646; cv=none; d=google.com; s=arc-20160816; b=awBNgj7AGuT4LlAuh9L1xnlPH6sXHmFTElu3ggJKmVRbErkuyNeTQBjJStB+vUUYai X5d+5gjsf8bInwfeVT1Mz3pnYkNc7X/0E0a8RfVV6WvtGIDAWVeDDrhlNKysYowvQHgN 3yoSG95icvR3Ktt5jB3Ng0FOM8Ti3qNlXiwyepZFQwOfQ0jfNGS1+WcmZOTju52gSNEG HZ1GFl7InBu/eCt2ev7cgMQ1gccY0grYeqmCutDCpAG/5L0NHeQSry1Jzp1tvpeYv2ah YXLGjnHWgRJAf+DRPip5sW6R+NFBOfBoQcbwhuBDM30MsYtXNtNMFxJCIK8o2eTaW2qW QPrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=NveKmC+gkTOx8xFd3aSLMj0CQxFE70uUkyeWevZyU2E=; b=rusCqo+1OEj+ySG+JKSAyxopq3H17n0gOGZkHZ1RdD01h7se1/lk/v4RhHx/wEqbU6 WpEOep25BXSDnHTby/eQpwlYBiiIKNzm+2GE1gwx+fBQUX4LwcJGFdnypv7Bnh0/IFKK dY+4jDwC1WSkOKW9BtEYCQhysp5cCpNwc+7qb9VIgAi3bqFieHsih4/h9QEuUStnbyWz r+LrVHXuSLVSbWfPIBcrXWvWkdHJoFZrJ3MIMM7XKkBGPo4zYzSZTO5T/tuZDM5TT1Jd b1o6wcRPhbv+9ZLqIAb3yiCg+H1c7I2jBo7UmR1Cx+jgfJsI+ANRTYs6iW8HU03IOb21 89tA== ARC-Authentication-Results: i=1; mx.google.com; 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 g22si8015665otp.55.2020.01.14.15.47.14; Tue, 14 Jan 2020 15:47:26 -0800 (PST) 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; 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 S1728827AbgANXqT (ORCPT + 99 others); Tue, 14 Jan 2020 18:46:19 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:47370 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728757AbgANXqT (ORCPT ); Tue, 14 Jan 2020 18:46:19 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1irVsm-008O1i-77; Tue, 14 Jan 2020 23:46:00 +0000 Date: Tue, 14 Jan 2020 23:46:00 +0000 From: Al Viro To: Linus Torvalds Cc: Vineet Gupta , Arnd Bergmann , Khalid Aziz , Andrey Konovalov , Andrew Morton , Peter Zijlstra , Christian Brauner , Kees Cook , Ingo Molnar , Aleksa Sarai , linux-snps-arc@lists.infradead.org, Linux Kernel Mailing List , linux-arch Subject: Re: [RFC 2/4] lib/strncpy_from_user: Remove redundant user space pointer range check Message-ID: <20200114234600.GD8904@ZenIV.linux.org.uk> References: <20200114200846.29434-1-vgupta@synopsys.com> <20200114200846.29434-3-vgupta@synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 14, 2020 at 01:22:07PM -0800, Linus Torvalds wrote: > The fact is, copying a string from user space is *very* different from > copying a fixed number of bytes, and that whole dance with > > max_addr = user_addr_max(); > > is absolutely required and necessary. > > You completely broke string copying. BTW, a quick grep through the callers has found something odd - static ssize_t kmemleak_write(struct file *file, const char __user *user_buf, size_t size, loff_t *ppos) { char buf[64]; int buf_size; int ret; buf_size = min(size, (sizeof(buf) - 1)); if (strncpy_from_user(buf, user_buf, buf_size) < 0) return -EFAULT; buf[buf_size] = 0; What the hell? If somebody is calling write(fd, buf, n) they'd better be ready to see any byte from buf[0] up to buf[n - 1] fetched, and if something is unmapped - deal with -EFAULT. Is something really doing that and if so, why does kmemleak try to accomodate that idiocy? The same goes for several more ->write() instances - mtrr_write(), armada_debugfs_crtc_reg_write() and cio_ignore_write(); IMO that's seriously misguided (and cio one ought use vmemdup_user() instead of what it's doing)...