linux-kernel - Re: [PATCH] ARM: mvebu: potential dereference of null pointer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y8mFjt/K1VSt5d03@shell.armlinux.org.uk>
Date:   Thu, 19 Jan 2023 18:01:50 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     ye.xingchen@....com.cn
Cc:     andrew@...n.ch, gregory.clement@...tlin.com,
        sebastian.hesselbarth@...il.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: mvebu: potential dereference of null pointer

On Thu, Jan 19, 2023 at 10:51:18AM +0800, ye.xingchen@....com.cn wrote:
> From: Minghao Chi <chi.minghao@....com.cn>
> 
> The return value of kzalloc() needs to be checked.
> To avoid use of null pointer in case of the failure of alloc.
> 
> Reported-by: Zeal Robot <zealci@....com.cn>
> Signed-off-by: Minghao Chi <chi.minghao@....com.cn>
> Signed-off-by: ye xingchen <ye.xingchen@....com.cn>
> ---
>  arch/arm/mach-mvebu/board-v7.c  | 4 ++++
>  arch/arm/mach-mvebu/coherency.c | 4 ++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index fd5d0c8ff695..3c031b2efe16 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -125,11 +125,15 @@ static void __init i2c_quirk(void)
>  		struct property *new_compat;
> 
>  		new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> +		if (!new_compat)
> +			return;
> 
>  		new_compat->name = kstrdup("compatible", GFP_KERNEL);
>  		new_compat->length = sizeof("marvell,mv78230-a0-i2c");
>  		new_compat->value = kstrdup("marvell,mv78230-a0-i2c",
>  						GFP_KERNEL);
> +		if (!new_compat->name || !new_compat->value)
> +			return;

... and then someone else comes along and spots that "new_compat"
gets leaked, so we get another patch to add a kfree() for new_compat.

Why not do the job properly first time around?

>  		of_update_property(np, new_compat);
>  	}
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> index a6b621ff0b87..8291185c52cc 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -191,7 +191,11 @@ static void __init armada_375_380_coherency_init(struct device_node *np)
>  		struct property *p;
> 
>  		p = kzalloc(sizeof(*p), GFP_KERNEL);
> +		if (!p)
> +			return;
>  		p->name = kstrdup("arm,io-coherent", GFP_KERNEL);
> +		if (!p->name)
> +			return;

Same problem here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!