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 F177CC433FE for ; Tue, 18 Oct 2022 10:15:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229651AbiJRKPx (ORCPT ); Tue, 18 Oct 2022 06:15:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229456AbiJRKPv (ORCPT ); Tue, 18 Oct 2022 06:15:51 -0400 Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90B35B1BA1 for ; Tue, 18 Oct 2022 03:15:49 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id z18so8974445qvn.6 for ; Tue, 18 Oct 2022 03:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; 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=gYbltMZ64D7hKvFQTXjLIPARfSfHVemLqW1KHFhpOJw=; b=a2JbG4PXkuao8NgxshI79Akk5safpmTtaDgWz7dDb/xODD7hfdgWQbTWR/hVtPJf/8 Ed0McMKCrk31A3JODbEIJjTs62iyrEL8sS2w5F0ftSrBprIi8s4hjDFMUy3g2gDSs2JQ LFxciMt200wcopnUAqYZII+yKIgHL2K34H4AI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=gYbltMZ64D7hKvFQTXjLIPARfSfHVemLqW1KHFhpOJw=; b=ZVDCuKgMDSYJti96MSBsbwAASJmYB8GJdJoMrsnneDppVR9yvUiKCiysecewyXhe5L iGe3LpCTXA3/bvX9FICAdAg/mvjatrR9DHkwwU4iMtiqP+dW1+js6v8zBWyvAnKVJVjX jX18Ewtz7HP/jufDr5B6HzsvRRIbpOROyis5BdbXS2+KXzVkZ/oYEGly8kCClcx6qbD9 0TMRwc5SErVpM7FBmhKQIb3S8I7LNuQHd6TVVwzPrlZ9xbjdhY8DM9JRaIqQQBYCXKgk XrVamlshWg/ytYO+3dLxdMvqQXByvw+uqMXTdLes3qo5sErFk+ko8dLze04TT8N/ioCe Yvfg== X-Gm-Message-State: ACrzQf18awLbW7TdRMWkBDnyQ1XzzbAY9J4ryXDkbGEltIV0toN6z6b+ 21UY3m5Jr/7lK4qb9TciOTxHrsUuBjP7Kg== X-Google-Smtp-Source: AMsMyM45fpCWMbhUwSQa4qqlAC/5HONfOVazlMSqRilbb2GgOwvHEIL5Wxs4HvOt0+aeEnPhJsXwGQ== X-Received: by 2002:a17:902:ef96:b0:17e:e7f3:31db with SMTP id iz22-20020a170902ef9600b0017ee7f331dbmr2355819plb.127.1666088138449; Tue, 18 Oct 2022 03:15:38 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id v8-20020a654608000000b0044046aec036sm7638023pgq.81.2022.10.18.03.15.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 03:15:37 -0700 (PDT) Date: Tue, 18 Oct 2022 03:15:36 -0700 From: Kees Cook To: Rasmus Villemoes Cc: Greg Kroah-Hartman , Thomas Gleixner , Jason Gunthorpe , Nishanth Menon , Michael Kelley , Dan Williams , Won Chung , Andy Shevchenko , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] driver core: Add __alloc_size hint to devm allocators Message-ID: <202210180310.A13EAA7@keescook> References: <20221018073430.never.551-kees@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 18, 2022 at 12:09:30PM +0200, Rasmus Villemoes wrote: > On 18/10/2022 09.34, Kees Cook wrote: > > Mark the devm_*alloc()-family of allocations with appropriate > > __alloc_size() hints so the compiler can attempt to reason about buffer > > lengths from allocations. > > > > > @@ -226,7 +226,8 @@ static inline void *devm_kcalloc(struct device *dev, > > void devm_kfree(struct device *dev, const void *p); > > char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp) __malloc; > > const char *devm_kstrdup_const(struct device *dev, const char *s, gfp_t gfp); > > -void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp); > > +void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp) > > + __alloc_size(3); > > I think it's wrong to apply the __malloc attribute to kmemdup() and > variants. > > 'malloc' > This tells the compiler that a function is 'malloc'-like, i.e., > that the pointer P returned by the function cannot alias any other > pointer valid when the function returns, and moreover no pointers > to valid objects occur in any storage addressed by P. Oh, ew, it defines rules about _contents_ as well. Thank you for pointing that out! I suppose we can use __realloc_size for these cases then? -- Kees Cook