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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50B16C433EF for ; Mon, 28 Feb 2022 23:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229667AbiB1XR3 (ORCPT ); Mon, 28 Feb 2022 18:17:29 -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-Google-Smtp-Source: ABdhPJyUO4WdPD4D+EwN7uSB3399f8EhL9c8HcIjeCpMcQrsQdmLfXFfXqDsDs2KAc/EYgd95j5zzQ== 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> 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