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 090DDE77179 for ; Fri, 6 Dec 2024 15:40:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BAA16B0294; Fri, 6 Dec 2024 10:40:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 76A206B0295; Fri, 6 Dec 2024 10:40:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 631AB6B0296; Fri, 6 Dec 2024 10:40:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 453C86B0294 for ; Fri, 6 Dec 2024 10:40:07 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0B8651C89A5 for ; Fri, 6 Dec 2024 15:40:07 +0000 (UTC) X-FDA: 82864944456.03.82FED97 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf08.hostedemail.com (Postfix) with ESMTP id D5040160004 for ; Fri, 6 Dec 2024 15:39:53 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CBQpVP7E; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=bgeffon@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733499597; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=naCWMgpan0nrCXMmm7Tdt71tCJVAIhYJMfmvvtiKj/o=; b=20uKb7IRA6YvpqpGLuMbCK/y3pqRFFLjdw/PiBmA/SMM14HTsv4Afnj2CT+O0SQMnRbhSA 0NHTwo+2GoVwXxTbhWWbFVmvC3JXHSsSYzrJr+3ShDCRoUYWlS7i4yA8eiYB01DqqZL8IT i1pLlmBoE+ihhg4fpQrbypGlZij1rj0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733499597; a=rsa-sha256; cv=none; b=wz/0iY4q4If+K8YzCvV4KYJLdNue98k67BKR/SMcIifRp/pl8sq5QS7zCyPlmGzYroM74M UhDbrAx4rvYUueln3zVX1N6Leez64fNQVFHeoFR0diGaCz/y7dAyybgalgBLMgh5/CUFbN 4HQZhKZ41VAPtUcxaSvXBwGDmW00Les= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=CBQpVP7E; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=bgeffon@google.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-21625b4f978so31035ad.0 for ; Fri, 06 Dec 2024 07:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733499604; x=1734104404; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=naCWMgpan0nrCXMmm7Tdt71tCJVAIhYJMfmvvtiKj/o=; b=CBQpVP7Ea3DUPM0YAEyZtxSXRLqQ6zAAjZbxEeqyZRHeLApDWuvI/jL3IWx8RZlTVk qefQmW/kXbA/4Qvf66k5nHWld9y21cYu0PKOPxrGIQJVa2DYPRq3mhw4CZ+FxDKDW00u P7DUZKSHHdTUoDRUxwMI8XvkMVXbwkgG1Hxv58QxIA+zguLrYVk3gCGx5g9CZsg5kb5j Aq/lsg7NUMjj4q/0cPklYAXFVvVxhVPAzqCKN5FQaVTyfBOEPIAEi3qNuB+PS7OGJpYR qzJx7iyzz3oBLCgI4fC7h3LXB/F0jkZ0Vw1OA5W1ezNK/Fjhv2TyX4zca9cjOvZQCR2/ KzwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733499604; x=1734104404; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=naCWMgpan0nrCXMmm7Tdt71tCJVAIhYJMfmvvtiKj/o=; b=HJdu8byqjdY/rPCTwdEtQ+p7QmXYBJMyML9p+SEEc6d0PGOHIYysyCAkqjDyS5mHHZ M4zMNn6s9Q46HctoGAouB+mtWHU0NsP1g1egBCohKO7VvgFxhNefy7EyH071a7VKgF13 6SLFgLI/+FvET0rtAlB2TiKqOiWtJgMhmqHetqu0mLdgot+Q/9OnOVQdo1SpM9ignTcN X4QgEk91eGWy13ikDcPpN+pkcVsrxj+pMW6yDQ75eL0XsSJJ2H2rBe0BSel1Hlg8tRbG 52lbbIXa5EE2U9igclHMlasEPFjyal+sA//58w0SMBdLdGL3K0JqkWAX+cIusS7FZnrx 1qyg== X-Forwarded-Encrypted: i=1; AJvYcCVM2F6T4gTn3CXMbNNhfgRzJn+JT8nuG5Rv0FJ6RvhWo3W6rX9xbs0xVEILUbXk4KjTNbtgY/4laQ==@kvack.org X-Gm-Message-State: AOJu0Yyr1wUS6yj4yYpYk8lOjxUVS9bqJfi7YK6zuI18PuHxj/9uGESQ BJvTIs8NcSZTOXxn9CqfCmBpFdOJzzmUQpt+ThcCezpZkzl1sFdEtjpzmxQ6DfsHK1lSAjTatkF tahL1GCdWhxt431CHr1YlZEnNEbwVeWkncYOh X-Gm-Gg: ASbGnctyZw6VRsTPMPwKrz88L5759WyxvGV/ZfnBSg/IisrVK9gm6q96bbOCDyhO0IB zN+nMy2hiu0tgBB6QMT6pThEF8od4UQ== X-Google-Smtp-Source: AGHT+IE+BD5ikEdOAL7gsqN0QEsob2iPIWBRUza/lTLftU4hGbKoYm0b/3gbBD9v7I4I4FlEWSM0E0u/9tVwq+rVBfs= X-Received: by 2002:a17:903:94b:b0:20c:f87f:b7ef with SMTP id d9443c01a7336-21613785b43mr2705515ad.22.1733499603658; Fri, 06 Dec 2024 07:40:03 -0800 (PST) MIME-Version: 1.0 References: <20241206152032.1222067-1-bgeffon@google.com> <20241206152032.1222067-2-bgeffon@google.com> In-Reply-To: From: Brian Geffon Date: Fri, 6 Dec 2024 10:39:27 -0500 Message-ID: Subject: Re: [PATCH 1/2] mremap: Fix new_addr being used as a hint with MREMAP_DONTUNMAP To: Marco Vanotti Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ccjfkr39xy6yi5kk58qznokrzho6qeb8 X-Rspamd-Queue-Id: D5040160004 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733499593-568977 X-HE-Meta: U2FsdGVkX1+ukRoRn2IWT5viF1X2mGtv2krbwafJJ4w4H5TUJUcJKR7lOPGVf17ZvhgkbgHoBKLI55wqVuFiUximZNMdeULQL0c4JYKnm4uDmYiw1HIhlIVyJ39zYdoa5YN1+Gj6Ig8JzYpT1coN7HoTgmqfT47fJu7LAkxkBWLBX/rob+XHRZjsC2ifjNd9LeQ//x6GnaId0gWlTmRp4ewmq+4+atRrQcNiKaF7VHc9tCl+tbRxmuiRajyxe1vHHgo9KYWUaJ8/TKhis9R5Hz8+kNG93HC+tBqPq9H6S75YUrs/cXPPgbm57GGwrbWPR0ES0honnqwwWPCbRRzBrvzNC+3WRnnm79Bypb81rJpGVZhf0SGSBhnoJOdSmi7UkJnwczkHadUWTtcyn9AMO+BuByCqqdTc3hMlSqy8ba97b7juc/fIAAR5FD4KRAQSJjnlA2s45pbWq2UAPPfzpYj24i/grQ74fBAH5A1zp6EljnWPVxW8t3+uvLCuZT/AUAzlfJ8K20vrC7f3LS09J3gATFk8gnD7WhVA6LxUzhZry3YPxOEaWNf0h2EFC4wpZFLv3cLiY7ShTfyFXKry59zt0D7tEGZoe2sxCzsuNsILx2WZCtV8kI3Kd04PjkRWDxvottXiR5UWc7DjU5crNA7tmQKLbORdx6lFx+CJkVVzGiwJZUHr/jU7pSCS1sdEfcFZPRpHvH1EqNuHOCKtNbl4+GRfOR5KxRt1HN4KYAGe2EURU+EONPvd2x2Shz7WtNr9Y4HdouXkV3BN2ZPuWbC1xWRUL/Z02TBb0IOvEZ9banNqjBLBFu3574evCAOfRSDLeSvwo1wRSGLYKu5K6oF34oYU6Pxki/j1XP1pniyLhTcWEP81+I1qv/P5xFfsuGsWc73zsOPuZ1lw4hrht/sKsXqtMTsiZ2vStERjBNFd7vUunyeXjEdOAoxwJ1toy0xuVzNbxuvIQ3YzmjF ls5GR6Lh I7ATVI2suRhOQf8wnrYvjpT8ISz3HwxAjKhfWb51sX1u3xwoGg33uN5fnMc2HVoNGLEHXT1XkUQygkCEKxrqLhFEzINB/bSpi8/eLx4rgDUTmHx4gdb7JU7f2QLWW0F7X9OMnZlrJvIA+fFDSDSnShXCP1BxWXNHIShOF+f63VxWZXO5Wu+BBsv+ZrEyn+XCZd5kF5VdVj/8XAOxbSWBJNc/ldIOUxpc2lVpZzCfv2e/OxCTIJYXGfsz1f8gy9otleiJVhxMOtvAmmJzZmHyMttc5kFWQDeOHm+FxkCzymP9fcU4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.048178, 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 Fri, Dec 6, 2024 at 10:35=E2=80=AFAM Marco Vanotti = wrote: > > On Fri, Dec 6, 2024 at 12:20=E2=80=AFPM Brian Geffon = wrote: > > > > Two non-mutually exclusive paths can land in mremap_to, MREMAP_FIXED > > and MREMAP_DONTUNMAP which are called from mremap(). In the case of > > MREMAP_FIXED we must validate the new_addr to ensure that the new > > address is valid. In the case of MREMAP_DONTUNMAP without MREMAP_FIXED > > a new address is specified as a hint, just like it would be in the > > case of mmap. In this second case we don't need to perform any checks > > because get_unmapped_area() will align new_addr, just like it would in > > the case of mmap. > > > > Signed-off-by: Brian Geffon > > Reported-by: Marco Vanotti > > --- > > mm/mremap.c | 26 +++++++++++++++++++------- > > 1 file changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/mm/mremap.c b/mm/mremap.c > > index 60473413836b..286ffdb883df 100644 > > --- a/mm/mremap.c > > +++ b/mm/mremap.c > > @@ -912,15 +912,27 @@ static unsigned long mremap_to(unsigned long addr= , unsigned long old_len, > > unsigned long ret; > > unsigned long map_flags =3D 0; > > > > - if (offset_in_page(new_addr)) > > - return -EINVAL; > > + /* > > + * Two non-mutually exclusive paths can land in mremap_to, MREM= AP_FIXED > > + * and MREMAP_DONTUNMAP which are called from mremap(). In the = case of > > + * MREMAP_FIXED we must validate the new_addr to ensure that th= e new > > + * address is valid. In the case of MREMAP_DONTUNMAP without MR= EMAP_FIXED > > + * a new address is specified as a hint, just like it would be = in the > > + * case of mmap. In this second case we don't need to perform a= ny checks > > + * because get_unmapped_area() will align new_addr, just like i= t would in > > + * the case of mmap. > > + */ > A few lines below we also check for MREMAP_FIXED before calling > do_unmap, can't we do the validation there? I don't have a strong preference either way. I can mail a v2 with this suggestion. > > + if (flags & MREMAP_FIXED) { > > + if (offset_in_page(new_addr)) > > + return -EINVAL; > > > > - if (new_len > TASK_SIZE || new_addr > TASK_SIZE - new_len) > > - return -EINVAL; > > + if (new_len > TASK_SIZE || new_addr > TASK_SIZE - new_l= en) > > + return -EINVAL; > > > > - /* Ensure the old/new locations do not overlap */ > > - if (addr + old_len > new_addr && new_addr + new_len > addr) > > - return -EINVAL; > > + /* Ensure the old/new locations do not overlap */ > > + if (addr + old_len > new_addr && new_addr + new_len > a= ddr) > > + return -EINVAL; > > + } > > > > /* > > * move_vma() need us to stay 4 maps below the threshold, other= wise > > -- > > 2.47.0.338.g60cca15819-goog > >