Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3287168pxm; Mon, 28 Feb 2022 16:32:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJwf/hny210FIaU9W5xDAoxoV9pG8y6b8ZfmZnd8PC/miFodk3nwcMRPkhKrsST1bpbXVsI5 X-Received: by 2002:a17:90a:c24d:b0:1be:d206:5d7a with SMTP id d13-20020a17090ac24d00b001bed2065d7amr2037223pjx.234.1646094722308; Mon, 28 Feb 2022 16:32:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646094722; cv=none; d=google.com; s=arc-20160816; b=FK6Gkp9L2c4TKc7+Y5qD5rQZ8dadHv8o7Y8dByO7nSHJg+397ZUtYN2Sl3MFsV3Ovc zv5SZCjlhfIDT/Cg7VLmBdUIV9ATzBFNSTAGn1tzJwKTzcjPkGcv94g2qbvhfXek37AL LFisnwB94BSecPVqbNSVCzH2ql53RxEJtdh6K50/0FHarZ2xgdX1ZnvmR3qYABum+Xqp bltFQ8vM6U86OQwN4oH3elzy4vfJpJ9YZyJw1Jsx80AMMflzVJ+evaBTklkgmNgoqI+N 4ybm503ae6CobJaHvsB/4rekpG4x+qeR1SZ4P9W+b/YG2LoE+3Bjl1rzGBqZlPu7B3CY Rf6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=qcyuF/rJ3v9adXS1wD5x79Nrhi3MVFgnMBiDVeVK628=; b=nY9R5cS5o8OtbB2KqCfOiVhz1Vz97prgFNEsK8LbTTYa6msU5OgtF92wKBwheEUAci /XVD4MZwriXknY7U5j+Rlj50MKBWEHGY5kt/U3DiETx7zTUoITN5n/uRFiP+OROpnOhT 8TGguUdT0bqpGQWJa8iCh4If3kvVwWnJmomHHNY91stEsVmGXeNjUGohLzPaS+F7Zvtc QmcQ0QGZ6czRutpYDwkn6P5/7QTfeM2IfAkoQ5W47eN3rI7MM/W3eWPgfw3LiltidX1f nyZ1YgWnGqO3ls8AVOqIEzfFCtdl8snj0vRlONDCs9i6fER6lCPpF/KvKi+W71x2W04q dRuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=H84ukViL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u12-20020a170902e5cc00b0014aa3968690si11651186plf.238.2022.02.28.16.31.45; Mon, 28 Feb 2022 16:32:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=H84ukViL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229662AbiB1XR2 (ORCPT + 99 others); Mon, 28 Feb 2022 18:17:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229654AbiB1XR0 (ORCPT ); Mon, 28 Feb 2022 18:17:26 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C680253B6C for ; Mon, 28 Feb 2022 15:16:46 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id d15so9167954pjg.1 for ; Mon, 28 Feb 2022 15:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qcyuF/rJ3v9adXS1wD5x79Nrhi3MVFgnMBiDVeVK628=; b=H84ukViLP1I1WQwJ555fTIX5iY07fF8mJhYhLLqFrxRU/v/5c13BT2oHieKtQ28QtB vTu/WJ1QzVGt7t0JrWP9EZxzFSuISG7rgQ18dkd1w1PdOvc/6kHgHln31L/hqrFgSqbN iT+TUK5ORx7x3+XzVmrBCQtrgm3FCzB0zo30Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qcyuF/rJ3v9adXS1wD5x79Nrhi3MVFgnMBiDVeVK628=; b=S4m7ElfRZRgsNLDw7OMlhVTWX9s/SNNFr0FmRupDU0QPEUdtxPfP91wlKDFFV8U4J2 YibNTbRgfPgsZELvFmyskyuO6VjYhdvAN6n5d52iHdmkmXJNW769sUZpoEnUT9MwkkLs oJjn8N/Qo8hVZilMMu3L1G9BIuYSlJ+dKYCHEGKfYS2PG9DUVOyzIsNX3MwhOyQzeCs8 wN99ckTYgMz5hI3czDbkeJSajdwRii3aM90hZM9suZf7SiAP2vUFDunjXByXTHaUOmbe WMZl4oeo5+I0ENFPnG9/Yl4Mfa8g1iHFV7Ln9CA4v8jjiodCQI+6zORlLN2trCTbtGtI jJEQ== X-Gm-Message-State: AOAM532vd7S8aGJS2K3Id32OPE2CCd/N0jEmLWixSUO6SBvaLX2lMNn7 Nxam1uflZ1K+zkWTBcRMSUevTQ== X-Received: by 2002:a17:90a:6542:b0:1bd:149f:1c29 with SMTP id f2-20020a17090a654200b001bd149f1c29mr13946279pjs.240.1646090206307; Mon, 28 Feb 2022 15:16:46 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id np11-20020a17090b4c4b00b001bd4aa67bafsm774491pjb.3.2022.02.28.15.16.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 15:16:45 -0800 (PST) Date: Mon, 28 Feb 2022 15:16:45 -0800 From: Kees Cook To: Andrew Morton Cc: llvm@lists.linux.dev, Marco Elver , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , linux-mm@kvack.org, stable@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Christoph Lameter , Nathan Chancellor , Nick Desaulniers , Daniel Micay , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] mm: Handle ksize() vs __alloc_size by forgetting size Message-ID: <202202251823.45E09CF@keescook> References: <20220225221625.3531852-1-keescook@chromium.org> <20220225154518.0d1159fdc6f37ee38e39e90c@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220225154518.0d1159fdc6f37ee38e39e90c@linux-foundation.org> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 25, 2022 at 03:45:18PM -0800, Andrew Morton wrote: > On Fri, 25 Feb 2022 14:16:25 -0800 Kees Cook wrote: > > > If ksize() is used on an allocation, the compiler cannot make any > > assumptions about its size any more (as hinted by __alloc_size). Force > > it to forget. > > > > One caller was using a container_of() construction that needed to be > > worked around. > > Please, when fixing something do fully explain what that thing is. I, > for one, simply cannot understand why this change is being proposed. > > Especially when proposing a -stable backport! Tell readers what was > the end-user impact of the bug. > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1599 > > Even that didn't tell me. Is it just a clang warning? Does the kernel > post your private keys on reddit then scribble all over your disk > drive? I dunno. Yup, sorry. I tend to get so deep changes like this that I forget to give an appropriately detailed summary. As others have mentioned, this is trying to fix a miscompilation issue, triggered by what can be considered either a mis-application of __alloc_size, or a failure to correctly disable compiler optimizations in the face of ksize(). -- Kees Cook