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 62D90C3DA60 for ; Thu, 18 Jul 2024 08:18:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E01E36B0092; Thu, 18 Jul 2024 04:18:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB1A16B0093; Thu, 18 Jul 2024 04:18:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA04D6B0095; Thu, 18 Jul 2024 04:18:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AAB0C6B0092 for ; Thu, 18 Jul 2024 04:18:17 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 237A480DD7 for ; Thu, 18 Jul 2024 08:18:17 +0000 (UTC) X-FDA: 82352171034.15.7952D0A Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by imf16.hostedemail.com (Postfix) with ESMTP id 3D4D3180026 for ; Thu, 18 Jul 2024 08:18:15 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Zosjy83e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721290662; a=rsa-sha256; cv=none; b=NOShKHszQ42GapR9odtFBOk2kJQauHMuFh0ohKNXrt5NKA3rZhaFEWcitDJWa3ZLP1ZXtB uUbWuWs3Hq3lxEo3sfEBAtL69q0quuIb6SiZpzd7nr042ZrZxlmvbdUMXZ9xu2+d9AwNt2 J/zsUnAISRbUM5Y+Bw4PkzXbpO8OKcg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Zosjy83e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721290662; 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=DvOSx4Zfn8IpsHTffF6VAw4rLB7M3YA/nGmuEhSer24=; b=tde2JB3NH4J1lljDmLIoew/KH+VDRnyr3jSpyW0GFkJ00BmjteGzgbbuKqUWkPzQOAJwhs fMoBGIFdywMbu4qMeAoWtMHB6haMHLWY8QpozJ7evXgoiwuyPsQ2toIRc1DFVOTw01zBhb 2jWGf0NGNFdB6/DvS/7M5RCdwpOekc0= Received: by mail-ua1-f46.google.com with SMTP id a1e0cc1a2514c-8218de5e3beso177724241.3 for ; Thu, 18 Jul 2024 01:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721290694; x=1721895494; 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=DvOSx4Zfn8IpsHTffF6VAw4rLB7M3YA/nGmuEhSer24=; b=Zosjy83e9xfelheobkUGdwvwlZH5HLn1lvSR3/dNg0MeVvC3gCYSiRBRP5py4ib7aF hbOPAyN/r7G+gF7UvVE5Fv7kGW0K4vr6Yjde+/jB+b943S/e6JYBUZiS53YFXcmcd2ZX M8zKEzk1VlHFYmPkYI7jPTE+u5In159sYd+gAKDzVXjd9UlZrImpJaJDQ2cf+gDyyc3t npsoNRc1EC0AYJj7tDQnAm1u+etpC6dm8alUsXp2z1IrtO/Fw5435UBuwTEBB7FJo9Lr xy3AeLQv5iySN1mqqVuOLcPXGQ9qC72/3vEmk0ukM/m4ALvvXA/74fyzyGw+2tLfaDO0 Hvgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721290694; x=1721895494; 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=DvOSx4Zfn8IpsHTffF6VAw4rLB7M3YA/nGmuEhSer24=; b=q/hgyX+hBTmR0XLixf9bDWcdd+vIPSOMR9I9ERSOzSL/7Nm4ahaaJ8QDV7kw65ot8/ hfI+eB+jNAm8fEubAFk9pmTtWcWqGNsbacTU81k/XSqaaP4F+5KW+XC1El85g5Pj2dZT zwn9gQhLdqqjdJD+a7I3c8hYXhC4Tor1egUjqM/+7/pd+r1N65/5VfscTVuDI+NZD5Wq t49bNEjiA9gPZPobJ9GmkH4gKiljs0j5Urjy48UqWrFbsffpDZewY8/5PMgac+rc4Gx1 eTmZtWYBQtNGpxjOwDn69NsRm3ipcOHJA0jnvbMnNpNWQE5k0987brgy5qjgCziOqrWJ ZhdA== X-Forwarded-Encrypted: i=1; AJvYcCU0KO11EGigknQn7hY2d0Tq+sioHlbNEDcc6+pJBunRzmivaaQxDqg61xqLMXSsnk59NLIYZQIm4ES/KMndympBXbQ= X-Gm-Message-State: AOJu0Yy+KXxo9Hht2YZ/FHB+hCOPS75ECf1Px4t3wPciBXgk4/tulBlc kjUCGJFksKbcVT9VIr2Ag28zCt2ONFiN7ya/HI9ySCLCI4I9Y2IVUgVVkqaI43W70Rqp0ITl+q/ 07U11ve9oZQ2yffNTwaMLKf72Wxc= X-Google-Smtp-Source: AGHT+IE5RPB88vmHulbcCqj67os1Iw6CIfW1/j43XQOQ3Vx1kao4FOJhsvvx8OFeUSfwAt5KkvY2FuxvwY0IBwP2GkA= X-Received: by 2002:a05:6102:4bc3:b0:48f:42a7:2c5e with SMTP id ada2fe7eead31-49159960ab9mr5844894137.27.1721290694224; Thu, 18 Jul 2024 01:18:14 -0700 (PDT) MIME-Version: 1.0 References: <20240717230025.77361-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 18 Jul 2024 20:18:02 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL To: Michal Hocko Cc: akpm@linux-foundation.org, linux-mm@kvack.org, Barry Song , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3D4D3180026 X-Stat-Signature: ht1hefayx8ttifcm53gtaoj13y4s6kjr X-Rspam-User: X-HE-Tag: 1721290695-288495 X-HE-Meta: U2FsdGVkX19d3d64LpN4llO1eQpMaS5U4A/SGS/SKxVONtnesK+Sjgd4mKMIjSTt4X14Z/K9CxlTOb0oZ0KSqARJnXOZx+u17U8oFBLZgQDAAOQya0bgvNPiM0xHMWwOFc/uMhWAZTEVxSBxWB9JG1Nnl4FWv47c0IFag4jozDK3BKipzXyf078bWIjWVcux6tg9iPF3gTJbT/HlHdwnUza0ZaQzfSUqhgEnJn1wAf1TwtcqfGV9nT8wy2O8W++vshvNcYAnwQN1DZ6d5EOr5YX8RlBQe8oe/mcWhF7kGhGHHFmvm78ijmaxtGtIN62gccE8TnALxdNsJUVJCEhcfv6iz973KQpJJhUuObLjyTDNen6FKCx+/KAgc6Sq14OHGS+zBu7YrmbxIMergcGBsQm0DdnXJ7hx58MeRF40jiPYkiKYi+aGy/ZFk4k/GsHMMgxbyOb5Z7sZPUukNqs6siXun+FjmdQZvUhOvbr6qdS1DV4I3GZXevhhmgUHQ4zqmtiiYoAaKnjLswSWhJrTr8C5UOpij0cDtQQzG7HxVF9Y8/6/EmkP+LkR/EBzxbR+ZowSgMSWGYyqPJWak+pQxn9mKFDO7UYMRSZIObBeqYJKWQ9NtRjQtKrIlNmhgDUnjyuoX1hBtoKMhI6NyZwhmXFbI/re5DN0rre6L59N22DY7BilSgc95LDAeMBYJcbJhKSdjOT2tEFCmbfcRY+LWZ2CyEOYoiKjfgxN0ycDbiJvQIp6PljBncZ23jmwnTD5r+YNINNIt8NB1zjkZShXVXF9988Dw29rTIbFrAhERHfobnj8/BjF5PAfsM3jmGcwTPgx5BmPmhADkgNK4DZqAU6fH1QUFS8R90feKMFZl/hMO1s7G0dbr/NTATpvMme7ZZcAraoyAQBZHOU1WNHSN+2v1X5ynp5x4V0grkR4GH829udhtu4KeC4uMGs/zxzq9Phv2g4gsoh8IXJMDvf HWruxArr b6M37aVBoh/L1P836ZHbE9/V1NeY89DsKhU97HNqP8R5dbCwYSmwOILPXf8wRMZusPuucLEvNdKg1t1SqQvAQUUuVLsr/2ZweyKv6CdkuYIYlCK2oJorQfklPw6VSzU3ZM5PR9PW1Q0xqpimDf0i5xDMqB1x5JMCnXcbImsD9FdwV7/06ffn6PqguOpeRUTOK0hVSpBXR3Wa/btkvOdSnvPOSQE+pKFby2Xk4CbA6Zhr+z7by2qjVTPz++iNQBvPGDxE8EjxrdKLl4EfqW6ZQ6juNQzeFvSyt/uj8p626fX+SvQnY0yAOduJGtnqxQXWjJG0UFnH8A/ApWr6lEXuhHqE60xrapto/3n9LeKaJAXN4YtAXafYxz/OPMitfOf2a7skx3jXKBLpOx2hw5eImfbNXn5CbPzOSiDr1+FlRziJ3JLR94p0DmqX56lZqXc+/41cSaEfudnJADYvqDe0YqTm4wyd7uhUTuehl 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: List-Subscribe: List-Unsubscribe: On Thu, Jul 18, 2024 at 7:55=E2=80=AFPM Michal Hocko wrot= e: > > On Thu 18-07-24 19:41:33, Barry Song wrote: > > On Thu, Jul 18, 2024 at 7:27=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Thu 18-07-24 19:22:37, Barry Song wrote: > > > [...] > > > > For future-proofing and security reasons, returning NULL for NOFAIL > > > > still seems incorrect as the callers won't check the ret. If any fu= ture or > > > > existing in-tree code has a potential bug which might be exploited = by > > > > hackers, for example > > > > > > > > ptr =3D kvmalloc_array(NOFAIL); > > > > ptr->callback(); //ptr=3DNULL; > > > > > > > > callback could be a privilege escalation? > > > > > > Only if you allow to map zero page AFAIK. Nobody reasonable should be > > > doing that. > > > > ptr->callback could be above /proc/sys/vm/mmap_min_addr ? > > Yes, it can of course but this would require quite a stretch to trigger, > no? > > Look at this from a real life code POV. You are allocating an array of > callbacks (or structure of callbacks). In order to have this exploitable > you need to direct the first dereference above mmap_min_addr. > > If you really want to protect from a code like that then WARN_ON doesn't > buy you anything because it will stop the exploit only when > panic_on_warn. You would need BUG_ON as mentioned by Christoph. > I actually also mentioned BUG_ON in the changelog "Likely BUG_ON() seems better as anyway we can't fix it?" though the code is WARN_ON. > So the real question is, do you want to stop exploits or do you want to > debug potentially incorrect but mostly harmless buggy code? I want to ensure that GFP_NOFAIL has consistent semantics=E2=80=94we don't check the return value, and it must succeed, although allocating a large amount of NOFAIL(I mean a number less than overflow) memory might make the system "unusable". While GFP_NOFAIL itself behaves correctly, it's inappropriate for the caller. So the purpose is making sure the semantics - NOFAIL means no failure and we don't need to check ret. If we can't really succeed, it should thro= w a BUG to stop any potential exploits. > -- > Michal Hocko > SUSE Labs Thanks Barry