linux-kernel - Re: [PATCH] xen: Fix null pointer dereference in xen_init_lock

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0b55dcb7-dbba-4c90-b0a2-9e158317f88a@suse.com>
Date: Wed, 26 Jun 2024 10:52:06 +0200
From: Jan Beulich <jbeulich@...e.com>
To: Ma Ke <make24@...as.ac.cn>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
 jgross@...e.com, boris.ostrovsky@...cle.com, tglx@...utronix.de,
 mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
 hpa@...or.com
Subject: Re: [PATCH] xen: Fix null pointer dereference in xen_init_lock_cpu()

On 26.06.2024 09:43, Ma Ke wrote:
> kasprintf() is used for formatting strings and dynamically allocating
> memory space. If memory allocation fails, kasprintf() will return NULL.
> We should add a check to ensure that failure does not occur.
> 
> Fixes: d5de8841355a ("x86: split spinlock implementations out into their own files")
> Signed-off-by: Ma Ke <make24@...as.ac.cn>
> ---
> Found this error through static analysis.
> ---
>  arch/x86/xen/spinlock.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 5c6fc16e4b92..fe3cd95c1604 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -75,6 +75,8 @@ void xen_init_lock_cpu(int cpu)
>  	     cpu, per_cpu(lock_kicker_irq, cpu));
>  
>  	name = kasprintf(GFP_KERNEL, "spinlock%d", cpu);
> +	if (!name)
> +		return;
>  	per_cpu(irq_name, cpu) = name;
>  	irq = bind_ipi_to_irqhandler(XEN_SPIN_UNLOCK_VECTOR,
>  				     cpu,

While yes, error checking would better be added here, this isn't enough.
You're treating an easy to diagnose issue (at the point where the NULL
would be attempted to be de-referenced) for a possibly more difficult to
diagnose issue: Any such failure will also need propagating back up the
call stack.

Jan