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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D914FC35250 for ; Fri, 7 Feb 2020 20:38:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7D4220838 for ; Fri, 7 Feb 2020 20:38:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TIVoYpqK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727390AbgBGUiu (ORCPT ); Fri, 7 Feb 2020 15:38:50 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:39505 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727303AbgBGUit (ORCPT ); Fri, 7 Feb 2020 15:38:49 -0500 Received: by mail-wm1-f67.google.com with SMTP id c84so4195482wme.4 for ; Fri, 07 Feb 2020 12:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rSg7JMFRzPtoE945qQnjffCeXnLroF1u5VJV3uyBQCE=; b=TIVoYpqKWPU4FbaHxrhBJ1Bwm+O6hvlv52zIi5d26xjDUTZ4yMC+K1iis5YbHTIZVl 9dHFuS4jNiXqxsq3FgyR0QBYCDDX0K20dUQm3BjtPvApP9txtUUaqU1OO0GhGh3Nep+F BPgz1uHXGrOg8F5sRqAfUFY9p4EvycZiJalM+RzKSVOw2pxxJOS10UZf+ODEOwWn1KTt ZqDzRMDMRWAmKXYblY7qJmxgBJymQDI6UbiK7qjXtkJzZqMTb1XCaabdFiCYMXNc+Ehz aCcOFiv0DV4rUQziYOvUisKifEZCM89iODF4OZ09LVnQd9aS0sQtw75L6vLrgV6rGOTX LtsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rSg7JMFRzPtoE945qQnjffCeXnLroF1u5VJV3uyBQCE=; b=Xkh2GcP2jwDP6XqmUW3a7g73OxXRtzKeOIWyjXi1y0dyPmveBZ+xonemW46fQ3rlES ejVdlTyDrgiJ3hOUHVfW4gSZ4tDfoDPT2GRvoMC9j4hB+HaVeA4yx7a1fyiJm/8ijBXa xZ0aVfGzzjbeymR7J3ahHlMYpB492SgFOItEVst/uVM6pn9rjN+5ZZGRPGSEjgYDI/qi N7ifR3oAv8JP+3YZjl/qJlLBeo/VzXuqEuN+KakxT/QOXeDE14ToO2dxpQ9p8qjgHrRs 1NEbT0TvIhlQ1qiKd2jmBVYr50LnsYb8m+71K95RXHqWEExZkLhiiR8aU+Jf92Of0Wzq wviA== X-Gm-Message-State: APjAAAVg3muRmEzOEFMXQ+CdKu2bCOaonKddW6z5GcfHV7yfBB8asCen u+kBEMSUKD9xGdaGJ+xiI0Uk1LPX5ZIKdXFUoho= X-Google-Smtp-Source: APXvYqydjzIv13caN2xryirukeMzD0uzG2GhLc51HcLRq8k2qIGBrJQP/yUUcBKY5ND3CTEXOXO+aNgXuI7aWIVoDew= X-Received: by 2002:a1c:488a:: with SMTP id v132mr81301wma.153.1581107927512; Fri, 07 Feb 2020 12:38:47 -0800 (PST) MIME-Version: 1.0 References: <20200120074344.504-1-dja@axtens.net> <20200120074344.504-6-dja@axtens.net> In-Reply-To: <20200120074344.504-6-dja@axtens.net> From: Daniel Micay Date: Fri, 7 Feb 2020 15:38:22 -0500 Message-ID: Subject: Re: [PATCH 5/5] [RFC] mm: annotate memory allocation functions with their sizes To: Daniel Axtens Cc: Kernel Hardening , Linux-MM , Kees Cook , kernel list , Andrew Morton Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There are some uses of ksize in the kernel making use of the real usable size of memory allocations rather than only the requested amount. It's incorrect when mixed with alloc_size markers, since if a number like 14 is passed that's used as the upper bound, rather than a rounded size like 16 returned by ksize. It's unlikely to trigger any issues with only CONFIG_FORTIFY_SOURCE, but it becomes more likely with -fsanitize=object-size or other library-based usage of __builtin_object_size. 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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F0A2C2BA83 for ; Fri, 7 Feb 2020 20:38:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3C92420838 for ; Fri, 7 Feb 2020 20:38:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TIVoYpqK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C92420838 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AE7C86B0003; Fri, 7 Feb 2020 15:38:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A976D6B0006; Fri, 7 Feb 2020 15:38:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AD1B6B0007; Fri, 7 Feb 2020 15:38:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 7F5716B0003 for ; Fri, 7 Feb 2020 15:38:49 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1FE1B180AD801 for ; Fri, 7 Feb 2020 20:38:49 +0000 (UTC) X-FDA: 76464494778.07.pan36_8728c407ec73e X-HE-Tag: pan36_8728c407ec73e X-Filterd-Recvd-Size: 3241 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 7 Feb 2020 20:38:48 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id p17so4229649wma.1 for ; Fri, 07 Feb 2020 12:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rSg7JMFRzPtoE945qQnjffCeXnLroF1u5VJV3uyBQCE=; b=TIVoYpqKWPU4FbaHxrhBJ1Bwm+O6hvlv52zIi5d26xjDUTZ4yMC+K1iis5YbHTIZVl 9dHFuS4jNiXqxsq3FgyR0QBYCDDX0K20dUQm3BjtPvApP9txtUUaqU1OO0GhGh3Nep+F BPgz1uHXGrOg8F5sRqAfUFY9p4EvycZiJalM+RzKSVOw2pxxJOS10UZf+ODEOwWn1KTt ZqDzRMDMRWAmKXYblY7qJmxgBJymQDI6UbiK7qjXtkJzZqMTb1XCaabdFiCYMXNc+Ehz aCcOFiv0DV4rUQziYOvUisKifEZCM89iODF4OZ09LVnQd9aS0sQtw75L6vLrgV6rGOTX LtsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rSg7JMFRzPtoE945qQnjffCeXnLroF1u5VJV3uyBQCE=; b=J8e+JHh11ihuJBLlrDZV5HxgPFaHNmnVJH7EWzBByMdgm+itq95OxbKHCRVsXIwC8a Tj7HfW/8oLJ3w2Encc6WLXBHNjm1dO/uKKwyIUoLuA/FbDyYbDQS5iD6HhuvjaLAEGIg rHms6WWm0xGeYMpXZlU7/CiE3Pilnh5SLfXvQNAOdCi+Et4gFnmfoEcaGdogcm/cs1OL QY5OmbHE/90KwwuC68qGml7OxEmeIY5TJKR79wYzbr5BQYjs/WEYuZoqAPKzGtHpxF82 AE2q8o1Y+CQ6GaVNwkrFHlbaFvxEO6Q98hGB/GbrDrHMPmukZtifJNBvs9PByjYGTNpd mAwg== X-Gm-Message-State: APjAAAV5Mze+Uywr2oRn6CKnAVK1zWMK/Tw/xrcmladVXENgLCWp5ie0 HXHw1eo0IKOcthzAxVqWSfofYZDpwdVPRmPP+Po= X-Google-Smtp-Source: APXvYqydjzIv13caN2xryirukeMzD0uzG2GhLc51HcLRq8k2qIGBrJQP/yUUcBKY5ND3CTEXOXO+aNgXuI7aWIVoDew= X-Received: by 2002:a1c:488a:: with SMTP id v132mr81301wma.153.1581107927512; Fri, 07 Feb 2020 12:38:47 -0800 (PST) MIME-Version: 1.0 References: <20200120074344.504-1-dja@axtens.net> <20200120074344.504-6-dja@axtens.net> In-Reply-To: <20200120074344.504-6-dja@axtens.net> From: Daniel Micay Date: Fri, 7 Feb 2020 15:38:22 -0500 Message-ID: Subject: Re: [PATCH 5/5] [RFC] mm: annotate memory allocation functions with their sizes To: Daniel Axtens Cc: Kernel Hardening , Linux-MM , Kees Cook , kernel list , Andrew Morton Content-Type: text/plain; charset="UTF-8" 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: There are some uses of ksize in the kernel making use of the real usable size of memory allocations rather than only the requested amount. It's incorrect when mixed with alloc_size markers, since if a number like 14 is passed that's used as the upper bound, rather than a rounded size like 16 returned by ksize. It's unlikely to trigger any issues with only CONFIG_FORTIFY_SOURCE, but it becomes more likely with -fsanitize=object-size or other library-based usage of __builtin_object_size.