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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8556EEB57D for ; Thu, 12 Sep 2024 10:06:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 565C26B007B; Thu, 12 Sep 2024 06:06:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 515406B0082; Thu, 12 Sep 2024 06:06:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DD6E6B0083; Thu, 12 Sep 2024 06:06:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 234776B007B for ; Thu, 12 Sep 2024 06:06:17 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D654881DE4 for ; Thu, 12 Sep 2024 10:06:16 +0000 (UTC) X-FDA: 82555655952.21.26CC2C1 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf10.hostedemail.com (Postfix) with ESMTP id E44DEC000D for ; Thu, 12 Sep 2024 10:06:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=x8gN4laf; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf10.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.128.54 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726135546; a=rsa-sha256; cv=none; b=UMSgRFSEowtWC82ijGbI7Hqo4bzUkvCE5HpW5xjc33niz2C4GrKQ/dSqXQ5/vpZbPyFl0+ /wTaJKs5Bv2yiefUej5i7ok0EEDB9QxlCOLITI7zeJOoV/H2AON0u5h6tnLR7ZKC0YUn7q hHaoWJOFv12P2SIOK0fMG4GSBDW1coE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=x8gN4laf; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf10.hostedemail.com: domain of dan.carpenter@linaro.org designates 209.85.128.54 as permitted sender) smtp.mailfrom=dan.carpenter@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726135546; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9f9vw1hY5QrAMqb22ETyD6iQGuby4m6Ga+q6MMaPXKw=; b=PQgLsstrwEF2ScnJDi7Bdqak3fa86PvBwJPNrd8h7bTy2OWVd6+Ua5PYwU0joYOCDtR4a3 JHd4o17vWYVqVSZj1XLOG6OTqLQh1p0ZqXvwVEO2T6J9VOEdNVLJZFUMqHhgxhhXcTSoHg OVrUJNem0dPtjyQYMP2LkTH7ze4uVmI= Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-42cb8dac900so6804535e9.3 for ; Thu, 12 Sep 2024 03:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1726135573; x=1726740373; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=9f9vw1hY5QrAMqb22ETyD6iQGuby4m6Ga+q6MMaPXKw=; b=x8gN4lafxKjyLkQUQ8XWYKMW9vbXpj12zD5PZHiEQRGjhPno1iHIOtxSBmQjHdjUus lAf+FsyKupJoAEDkLkjXhsc58I2SC2QubkxWZhUE1nDA60RJs0zZZMiojWzbk81NyPP2 3OGcScvsYcLy2Y1U8jiJhEh8W/KAL3owMkO7Rcajbgl1bFGa0tTKgfx7cIBt/80F1a/i 6rd4HcSr4s1954eN4CAvb8XCiZ00eqFb2TnJgUkiewq/46UpPI8QDf+uhFtRMTxozX/V wfW3qNU72ruosHTZGoZ3/1jechRwKDhkaYtpraHnl/g160S1W/YdJka8jfPEwNPJnCs2 nF/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726135573; x=1726740373; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9f9vw1hY5QrAMqb22ETyD6iQGuby4m6Ga+q6MMaPXKw=; b=eTsMslWXXE+ZW/wtGneKevkHzAjh9tHj7i26omGWRRhg9Kg/Ho8z1Nn6+oSTL1+5dI 7my0fuWaTQs8IfU4kPxMEYUXek+fmW9F9jcAqA406L0TSyez7Isf8h35sXvcXGxMbD8V GzYEfIcrzDdaQ2r5fNMTr2D7Wh9buvQK8R2tQ1gvlfU1j904wU83heNxRkUxAeFekPED eFmSl9K8KegNTrYc1n3uu4iBj5qhtOND5AdK6WGnp3Mg/36Iv/WidBJNI8Pb55H0+j0k 5vg9R2T+NlPdRkqGymg5qBM4M4kHge7NVaWWtCSikHeDR9bWXgaAflAUiX9LOW3UmP+P BfRA== X-Gm-Message-State: AOJu0YzosdjCERH+qpC3+phLmZlliIDHMDjXZtG3qoCgSWo2JCSLAEe/ i5T2q82dIcLZRp3t7an8k1qvIep7yk2fiCGuuj3vnOfvZSY+g52swFvrp/r5RXPZvybvYik3F2i q X-Google-Smtp-Source: AGHT+IFIVXMSjXI0WItlEkRGBkE4sVo1mzs3x8iYM6cm17R5bnyS11Apu3o6+MP2BwuX9mdLX1bomg== X-Received: by 2002:a05:600c:4d06:b0:42c:acb0:ddb6 with SMTP id 5b1f17b1804b1-42cdb531b66mr19362125e9.9.1726135573210; Thu, 12 Sep 2024 03:06:13 -0700 (PDT) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42caeb8ada3sm165339195e9.43.2024.09.12.03.06.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2024 03:06:12 -0700 (PDT) Date: Thu, 12 Sep 2024 13:06:08 +0300 From: Dan Carpenter To: Muhammad Usama Anjum Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Kees Cook Subject: Re: [bug report] fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs Message-ID: <69e01b95-fcf1-4168-8aa9-708623ec3956@stanley.mountain> References: <3a4e2a3e-b395-41e6-807d-0e6ad8722c7d@stanley.mountain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: E44DEC000D X-Rspamd-Server: rspam01 X-Stat-Signature: bdrir5eeyn7kei69mnxea1hy838hbmtk X-HE-Tag: 1726135574-903098 X-HE-Meta: U2FsdGVkX181RX6CNds43FbdMBBuBgOHBoE87wgfEElPWTCMjYJFNfbr2zbAybNryCG2D9a2SvzAEs2ZVoGFJBFyI2hHUAdqdaH9xOJkSd+0mVRE+rM3H8fPxcZg6+fuHV4JYgXQKMIDUdkrLfuikVksErk79GOK3mYvYRkL398dLyHE5TrFUKStCLoLQFYEKpPeFt/6LxZSfohy95L4jrnVVBvOYVOfC1i7ebXIhb7LZLSLE8h8L3+HT39BHI6rz4lS1or8bKUtSwFHNUZtdXFh18RhvsajoSMdmpWPxIblosfmtxez5csqtKz0wRpN8p5xn2fcACdUukS6ZkETJRRX+0/r80a1dbYA92tzvsFlEh6RWIrtwsC00l71UeKovm4x6HuBgfXXcbndB3i65fm48bnbPjLEoADOmfesJ7Htq+N/CK9mHWcquUM26p/GYIL+RLOIe7UZQ8VVrIBfNV7dHMcBluFYNUXpwj9EK1SAxDvV+xptEbpAjHcVJUp7F+uPszxqh4At9k03/3EhIjm8eKZbbyz18s1Fr4KICfWXxEqfOVa7KO2jT+esS0PAyNzeD5hKwIGp6QhNSEug0A3lAy0+MnrUiw2JQgfukhfRgWMhvjOpOXCq+W16tsXYZgXPooU/5JSwk6K2BkvDCw+KAQTAqhFvpjtEX4Ooi6kZrqhbzRnHeiqrOvAHHbgwQG1al6HewSGzIUb9eWgNzQiAlR+52MfSe7I8xL3Z3lpfeiI1mqZ846fkZOdpqKF90wmC/3imcsmyowxmVrkvS1bELEk2D3dRuNEwbuiolC6EJ2mGr3wu/2pOPi07G2jCDVRPUXgdhJ2hMzOoUiYGSq5Nx1pDcSjJKBOjxFG7v7KhamTrLg5CtFgvVDmpHc6SDYcjTfAMvAQEJh7gNQ9yPzoL+f7kYOnatTTrCAqu3CWRMHgN9I+bci68cLG5I+qYH5GpOqOXwNN7Lac4FB0 IMkb/gAY 8FllVlVJy22AruluZ+SPay8EdEzMXqDwtBDiUTiQWWTmmuk9wkG5N5YNb+2AZxIa/YmUpoK6ZW4g6aOp+1P1G3VkhpN6rX2HmvaZbsfwehvocPEmZjcvLkY19hyDltr0NOt1CrWdNoVsF9sj7MjNrN3PpH159o178UnNjXCkH81RqgVDXvZMrnlomch/D4gDLVa5VppGVNIRlQNG2hkWjESp8URwMunvJL17cwtR84tZge5PIHD+fQw6Kw9KPOBp/W4mf33n7yk61OCpx07y7+6GBQ/Bt1x1S/zaRX0YAuMMDcjl6SB0i91ZRUXhrsbgM9IfO X-Bogosity: Ham, tests=bogofilter, spamicity=0.053093, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Sep 12, 2024 at 02:34:54PM +0500, Muhammad Usama Anjum wrote: > On 9/12/24 11:36 AM, Muhammad Usama Anjum wrote: > > Hi Dan, > > > > Thank you for reporting. > I've debugged more and found out that no changes are required as > access_ok() already deals well with the overflows. I've tested the > corner cases on x86_64 and there are no issue found. > > I'll add more test cases in the selftest for this ioctl. Please share > your thoughts if I may have missed something. > I don't understand what you are saying. We are discussing three issues: 1) We check the size and then make the size larger: check: if (!access_ok((void __user *)(long)arg->start, arg->end - arg->start)) larger: arg->end = ALIGN(arg->end, PAGE_SIZE); The ALIGN() can't make ->end go beyond the end of the page so it's possible that if you have access_ok to the start of the page then you have access to the whole page. It just seems ugly to rely on that. (I don't know mm very well). 2) Passing negative sizes to access_ok(). The access_ok() check will treat negative sizes as very large positive sizes and it will be rejected. So far as I can see this is fine. Plus there is a check at the start of walk_page_range() which says if (start >= end) return -EINVAL; 3) Integer overflow: access_ok((void __user *)(long)arg->vec, arg->vec_len * sizeof(struct page_region)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This multiplication can overflow so access_ok() checks a smaller size than intended. It will absolutely return success when it shouldn't. To determine the impact then we have to look at do_pagemap_scan() but I don't know the code well enough to say if it's harmless or what the impact is. Integer overflows to access_ok() are always treated as a bug though even if it's harmless. regards, dan carpenter