Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 4 May 2022 13:09:09 -0500
From:   Rob Herring <robh@kernel.org>
To:     Kees Cook <keescook@chromium.org>
Cc:     "Gustavo A . R . Silva" <gustavoars@kernel.org>,
        Chris Zankel <chris@zankel.net>,
        Max Filippov <jcmvbkbc@gmail.com>,
        Frank Rowand <frowand.list@gmail.com>,
        Guenter Roeck <linux@roeck-us.net>,
        linux-xtensa@linux-xtensa.org, devicetree@vger.kernel.org,
        kunit-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org,
        linux-bluetooth@vger.kernel.org, linux-hardening@vger.kernel.org,
        linux-hyperv@vger.kernel.org, linux-integrity@vger.kernel.org,
        linux-rdma@vger.kernel.org, linux-scsi@vger.kernel.org,
        linux-security-module@vger.kernel.org, linux-usb@vger.kernel.org,
        linux-wireless@vger.kernel.org, llvm@lists.linux.dev,
        netdev@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH 29/32] xtensa: Use mem_to_flex_dup() with struct property
Message-ID: <YnKbaXEUHyu+btOD@robh.at.kernel.org>
References: <20220504014440.3697851-1-keescook@chromium.org>
 <20220504014440.3697851-30-keescook@chromium.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220504014440.3697851-30-keescook@chromium.org>
Precedence: bulk

Gmail won't send this, so I've trimmed the recipients...

On Tue, May 03, 2022 at 06:44:38PM -0700, Kees Cook wrote:
> As part of the work to perform bounds checking on all memcpy() uses,
> replace the open-coded a deserialization of bytes out of memory into a
> trailing flexible array by using a flex_array.h helper to perform the
> allocation, bounds checking, and copying.
> 
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: linux-xtensa@linux-xtensa.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  arch/xtensa/platforms/xtfpga/setup.c | 9 +++------
>  include/linux/of.h                   | 3 ++-
>  2 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/xtensa/platforms/xtfpga/setup.c b/arch/xtensa/platforms/xtfpga/setup.c
> index 538e6748e85a..31c1fa4ba4ec 100644
> --- a/arch/xtensa/platforms/xtfpga/setup.c
> +++ b/arch/xtensa/platforms/xtfpga/setup.c
> @@ -102,7 +102,7 @@ CLK_OF_DECLARE(xtfpga_clk, "cdns,xtfpga-clock", xtfpga_clk_setup);
>  #define MAC_LEN 6
>  static void __init update_local_mac(struct device_node *node)
>  {
> -	struct property *newmac;
> +	struct property *newmac = NULL;
>  	const u8* macaddr;
>  	int prop_len;
>  
> @@ -110,19 +110,16 @@ static void __init update_local_mac(struct device_node *node)
>  	if (macaddr == NULL || prop_len != MAC_LEN)
>  		return;
>  
> -	newmac = kzalloc(sizeof(*newmac) + MAC_LEN, GFP_KERNEL);
> -	if (newmac == NULL)
> +	if (mem_to_flex_dup(&newmac, macaddr, MAC_LEN, GFP_KERNEL))
>  		return;
>  
> -	newmac->value = newmac + 1;
> -	newmac->length = MAC_LEN;
> +	newmac->value = newmac->contents;
>  	newmac->name = kstrdup("local-mac-address", GFP_KERNEL);
>  	if (newmac->name == NULL) {
>  		kfree(newmac);
>  		return;
>  	}
>  
> -	memcpy(newmac->value, macaddr, MAC_LEN);
>  	((u8*)newmac->value)[5] = (*(u32*)DIP_SWITCHES_VADDR) & 0x3f;
>  	of_update_property(node, newmac);
>  }
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 17741eee0ca4..efb0f419fd1f 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -30,7 +30,7 @@ typedef u32 ihandle;
>  
>  struct property {
>  	char	*name;
> -	int	length;
> +	DECLARE_FLEX_ARRAY_ELEMENTS_COUNT(int, length);
>  	void	*value;
>  	struct property *next;
>  #if defined(CONFIG_OF_DYNAMIC) || defined(CONFIG_SPARC)
> @@ -42,6 +42,7 @@ struct property {
>  #if defined(CONFIG_OF_KOBJ)
>  	struct bin_attribute attr;
>  #endif
> +	DECLARE_FLEX_ARRAY_ELEMENTS(u8, contents);

99.9% of the time, this is not where the property value is stored as it 
points into an FDT blob. I suppose that is okay, but just want to make 
sure.

The DT API for creating new nodes and properties is horrible as it is 
multiple allocs and strdups which makes for tricky error paths. A better 
API to centralize it would be welcome, but if this is the only case you 
came across it's certainly not a requirement.

Rob