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 8C844C3DA4A for ; Tue, 20 Aug 2024 06:17:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 009A56B007B; Tue, 20 Aug 2024 02:17:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFC586B0082; Tue, 20 Aug 2024 02:17:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC4246B0083; Tue, 20 Aug 2024 02:17:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BE3C46B007B for ; Tue, 20 Aug 2024 02:17:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9E448A1828 for ; Tue, 20 Aug 2024 06:17:35 +0000 (UTC) X-FDA: 82471617270.28.0D91808 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf07.hostedemail.com (Postfix) with ESMTP id A97EF4000D for ; Tue, 20 Aug 2024 06:17:33 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=STfuhBIt; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724134638; 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=56N+3ZnhzW8ZfoNYTDxVJgLpZofU9AGU8Qdg270Now0=; b=an9tm+8dQ2g+OwZU+1MhwNJ8JB5fWXKsQxV4zWFk55oXlXJe6g0i6j6TyhR3RA3/Uvbnhk x28d6xhYz41p5BjZ+X1pJ8IdXBzu0Xj05u+1D3G4+M2nhD+UXQc95FIjhrP6X7k5JuXsai WVtCA0uenATgDkPsRsk4t1ToAU7q7Jo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=STfuhBIt; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724134638; a=rsa-sha256; cv=none; b=OvxlAPEKUkwiwQhH2Bk61I1efvycxn+vg39zBQ1c5CA23RlEgmVHxK8HYNb+zcZGR6ZC3W WSWzPBsY/kQoITMvt2IFkjZY++KmSOMeFU7SAiWPiI9uo+K3nMR2IGZPKXgr2EFiDBpIPh f6lOXgqp+WOVBVJu/WywZcyWlrbh7wY= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5bed68129a7so4190052a12.2 for ; Mon, 19 Aug 2024 23:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724134652; x=1724739452; 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=56N+3ZnhzW8ZfoNYTDxVJgLpZofU9AGU8Qdg270Now0=; b=STfuhBItbb97wRcQE0nt1PpWTfdlPAZISP/1T8ewjoO+9VRlpIVK/XaOSgj3+kNYEI DIxyE1DW3P2HFWbXXtx0Q5wz+QTf/V9qs9RssQDMCIP2mGtGEANKBltAu5XrcS4bdcam EweabDkAYpsi7blxesMte8jpfXdD0iKC1v4MFqIxh9xvMimEMd9xMg7MDevjerriYPDX PZi0/hIIMC3p2bjHCIFWp5Ku+48JsGh33vlMy6UOGLCTxG5otUvMyUr7EALoVToMFkEc Yup+N0Ufv8ZWvD/8Ig9eGVgYXKbpQlyVgSQ5zIP7Oo4Y3uoZr41NOaACQ//HWaGn3D4P bh/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724134652; x=1724739452; 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=56N+3ZnhzW8ZfoNYTDxVJgLpZofU9AGU8Qdg270Now0=; b=lRDaYJvNB8PnRGkdJeiyQbm1FTvfdN1lqdqxI1Tj3ptnOq/FfGw2aggzt0HTqoQun2 T2mWPhadbrbVbhPs1eJHR1cZTWzdEBudtA8XMMFhv/xXcQHafGc0lsDrW+rdVWtCZWYy EiueyjUYcj0cCrMHnf7ZdAsFFfJCHzMkrIGBM/og0wKGzQ1RMdIPjGxrqgDJd3FS62jo 3RG9z0pp13wDLIKPAbAdP78ZGosFbhAZI+CDUE22gw1TPeWviPlusoFdQzQFbDHl2cm8 WoBxXoBsnaTdVwEyaSjaoEv2eRPacZ7AVKLtA+V5LFBlAvZcPkjk46oBnFP2jx44AbQY DhGQ== X-Forwarded-Encrypted: i=1; AJvYcCUAyVlBYbGuX7Atc59yfP4VBUmSEtEogK0pXTc+JBfThVeQfJBo02I9kAGUIl6e7f+EKlmJ3Ee1KppQVbRn7G1uDP4= X-Gm-Message-State: AOJu0Yy31J70nkhZz+H8ciS1MKuO0pNoNVp/geEGAY40LNmxFRxqNm9n IYcyDnYT4P+RihvuN/dDFFBOn9YEQkBOmor2ZLFyeA69qWxmFwtjXLd8rb29z1k= X-Google-Smtp-Source: AGHT+IF1fVcmkpkLaENHujEcxVs3gkip9d6D2T9b5YQCS0rC4414pWwXTFChRiYzOZIgvF7utuJdqw== X-Received: by 2002:a05:6402:84b:b0:5be:bcdf:4110 with SMTP id 4fb4d7f45d1cf-5beca263a7cmr9618497a12.0.1724134651917; Mon, 19 Aug 2024 23:17:31 -0700 (PDT) Received: from localhost (109-81-83-72.rct.o2.cz. [109.81.83.72]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5bebbdfa4f1sm6330386a12.43.2024.08.19.23.17.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Aug 2024 23:17:31 -0700 (PDT) Date: Tue, 20 Aug 2024 08:17:30 +0200 From: Michal Hocko To: David Hildenbrand Cc: Linus Torvalds , Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev, Christoph Hellwig , Lorenzo Stoakes , Kees Cook , Eugenio =?iso-8859-1?Q?P=E9rez?= , Jason Wang , Maxime Coquelin , "Michael S. Tsirkin" , Xuan Zhuo Subject: Re: [PATCH v3 3/4] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Message-ID: References: <416ac265-ced2-4f90-a347-0a256edf7fdf@redhat.com> <54a4619d-e826-465e-9a0f-0a8f37798e15@redhat.com> <5424dfa3-03db-4a82-a08e-fb31285774b3@redhat.com> <6814fdf6-cf32-43e9-ba20-705ec5238abe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6814fdf6-cf32-43e9-ba20-705ec5238abe@redhat.com> X-Rspam-User: X-Stat-Signature: yitpzk8u8n65j15nm4escwqcnsykdy81 X-Rspamd-Queue-Id: A97EF4000D X-Rspamd-Server: rspam11 X-HE-Tag: 1724134653-225549 X-HE-Meta: U2FsdGVkX19RayRFwkY2hNfvgDuSG2agFbABzp1X2e/JVynTzJcLZ3gxAVN2CuWZYeRCcp3ggKF0XpmO+3Fi6zicIvWRY7gazqGX9csPKO6+RGvE9/GBHoUpD3hY8+tY71uoLPmATG56MowP6noxR1RIW8fFkd1saX76j529wvWKWlnHsFsOx69LMls2nLdpehPuJoPNNm7wgJTCAcR4exBnVKtKOFI1MuJukNaTP1xa5WpG2gLaFWF2RM81HmHkgiFbO3dUABsV/a0/s+XoV4JvGJlMl1BuwOgEFnyLHLC6nPDyO9RRfiuR2fhBl9un3OCQKjCp/tsi3BxEV9pkPhJLOCffPkqlPa8bUt9djsOOkwe3jbLyFU70wNavYl/ghLLzZf81aZFRV1zrPyVU1ahj86Hexo4UPNn34J5JAKmvxylCT6YUZwhPeVYSJX6tSN6lBrAToMJl0JQa6vx7r+QB8kMKUFXu4WEQqSjhAz4GRnm9pihto2D0b2sSXYp+OPmLzlbbMZK3/EOCJRYsSz8vztlnYunsKyKsvzGXuRZ0vQYLad3Dgd8wKcu5Uu/L6byhyaY40kqCwJRBNrY64F2iVDs0BapaChT0MI/EVgfLGm9/B6pJHdW94UAwQcISnWnkBmIUhyvTaoCdW75f+YJ9Xq8EmBmI7Bg9g0T9D+hZjj716hSikj+9wl1QkKspF6/x4zI5PJXBhbFtyiooeOvRz1k/QsWDAUECXdw/ZhNU3E280I8EsuersqwopnayTJQWYRyQ2t3EEu+q9gdvz46bhVLBIAex0KMBf+7jN74X/BlO3bqHtanlwk6vLa5FK26nIRjz5z6oEzXlgwmzmKCecThkX6LDRbVyJtTmmFOjQ9f2xOpo0Gx4D8u5ph36x85P8VVsqN5H4ktlsrgv1N+esLj7tUDh7bvCeItpmBbby3UJrxCM4iCmwtZdfEu+EQy2MbtvkG7tglC6W4+ aZDxXnGt 7R54WqIox3n4qxsPH3mbnZnuB+xq6VjU27tcMs8Pg0meiMGi9mG82NYyZz8NdbRRTbBQIG+VDlG/7xIIZVuyTqG7ltdJEeHvksakfjGVnmHTUCEMGSTl8UPFQiWJ9Ufi8XV3O0fIn7bXfwzjZIQ+Fg+j6vHXueLihFx83q6gVIOWCc9OU2/kZzV6WdWk0U2Aese2xWOhO46orJ2+JJW084MqvBFi0djv0WUA0Dj5n1vNow/lOyqRbW4AV3BV5PBoqO2mkujXWUBAx0K2cYo+7o1SZHC+qtfMWef19DSu2Sg3Nr3V5QlWR7jPYn21TcEOotvEVr07I4lwX8L9vL7t/FA6+CcVJHSyuPECljc0YNHE3jSBYVk0GWj0h3KWvuVstATPi6FNl2XtA0r2xaa8AkBTse5odNAphgCiP4mvMzAqFcDo= 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 Mon 19-08-24 23:57:29, David Hildenbrand wrote: > On 19.08.24 22:35, Linus Torvalds wrote: > > On Mon, 19 Aug 2024 at 13:24, David Hildenbrand wrote: > > > > > > Right, "warn + loop forever" is one alternative where you could at least > > > keep the system alive to some degree. > > > > Maybe. Or it might just lock up the machine. > > Yes, regarding the security concerns it might be a bit better that way. (no > security expert, so I cannot judge ...) Would it make sense to simply enforce and oops? We do expect that an incorrect usage would trigger one but we have no guarantee because the actual user could be array = kvmalloc(unsupported_size_provided_from_userspace, GFP_NOFAIL) which might be actually a valid usecase because that the normaly requested size is large, yet reasonable. A lack of user input checks is just a sad reality we have to live with. While those bugs absolutely _need_ to be fixed it is better to not just allow them to array[large_index] = payload and make them easier to exploit the kernel. Sure you will get a warning but your machine has been compromised. BUG_ON will shoot the whole machine down which I do understand is just too drastic of a measure. Making the allocation loop for ever with cond_resched() or a short sleep is slightly better because it contains the bad user but the process context is still not killabale that way which is a problem on its own. I am not aware of OOPS_ON that would kill the calling user process. Yes, this could still be leaving locks behind but still better than a compromised system. WDYT? -- Michal Hocko SUSE Labs