From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BAF422FE11
	for <linux-kernel@vger.kernel.org>; Sat, 15 Nov 2025 23:18:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1763248702; cv=none; b=Ld0Fis6TQBtDrCgPBB7RJkHZ6tr7d2VVMPz1uVr9+mh2pqxUlI+JCOb3rO9zXubaQIidRLs6Xx4ddSXWZLKXuuysKc7qRpDEI8TLTCSuDBO1LtZ7wc4x2f0E7+4IsYzrWJLM85Oh+hYl+HvaXmdhmlBV2DbvHqKmtF2e0ICQTz8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1763248702; c=relaxed/simple;
	bh=lIm2cqHvoeJrkFieWDMeOZ8ROUikIE1P/pJdKNoO2U8=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=VOjRPrUiU/9O7cFdQ4MXR83k0sijNHHGtCRxa6AUNY81bhsOGuZ18CvfBTFVb/2EyREmDzVqfU7Z3dJ3q/CidXJCRPay3rWV/A+Dy9y3RhFpF8Q5BZyF9g6csH7Mti8B/fqCHOrN9ntJ6b5yM5GVu6/R1mWkNqLkBAOtLolQhSA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=L6b58rsI; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=eaKoz8Pu; arc=none smtp.client-ip=193.142.43.55
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="L6b58rsI";
	dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="eaKoz8Pu"
From: Thomas Gleixner <tglx@linutronix.de>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;
	s=2020; t=1763248698;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=/eStzWkwYAfLa/8Yx0qsJi2M10aR9NoWp6DQ4fTbZsU=;
	b=L6b58rsI7b++EzVE2djDtyPAopn00jqh7CsmuUBs2l5Rdr8nBEPN0WBaZJkvJyttRI7QAR
	lRzvsvRbicdt9O5qfWoTzH91TYOid52qqChDFjX8fAemtOKuy8ObgJNTrxL7YiijLpHXGA
	vuAF4G7qSnP3ZmlliGZ8j1EwQfKsnSCNl8ZHkbNS8WieXzPMQ+LswMVVefmnZNiba7Vr4e
	yzeBXEZWCt/ekXJIuTc0LXR4IjjNPGt8qt6VlSvVNtq1yrWrqTZ97bWsLTZf1noCA88f+5
	EP1C6Lo3Ja1Gh/kAUY5uD4W7v/Ft7AN0q6hi2W8lM9eaNiyuzLqu8lR6eEw59A==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;
	s=2020e; t=1763248698;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=/eStzWkwYAfLa/8Yx0qsJi2M10aR9NoWp6DQ4fTbZsU=;
	b=eaKoz8PuTMBG6aK7nLUNoI4JIlvafxu8a8A6vztaNtCEWZhLopv/NMEtFn+u4pfPfnbJxD
	EPftbcFoKnKpt5CA==
To: Haotian Zhang <vulab@iscas.ac.cn>, Andrew Morton
 <akpm@linux-foundation.org>, Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: linux-kernel@vger.kernel.org, Haotian Zhang <vulab@iscas.ac.cn>
Subject: Re: [PATCH v3] debugobjects: Fix inconsistent return handling and
 potential ERR_PTR dereference
In-Reply-To: <20251114015631.1729-1-vulab@iscas.ac.cn>
References: <20251110075746.1680-1-vulab@iscas.ac.cn>
 <20251114015631.1729-1-vulab@iscas.ac.cn>
Date: Sun, 16 Nov 2025 00:18:16 +0100
Message-ID: <87bjl2anrb.ffs@tglx>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Fri, Nov 14 2025 at 09:56, Haotian Zhang wrote:
> The lookup_object_or_alloc() function can return NULL on memory
> allocation failure, while returning an error pointer for other errors.
> Call sites such as __debug_object_init() and debug_object_activate()
> only check for errors using IS_ERR(), which does not evaluate to true
> for a NULL pointer. This can lead to a NULL pointer dereference if
> memory allocation fails.

Nice fairy tale. Let's look at the facts.

__debug_object_init():
	obj = lookup_object_or_alloc(addr, db, descr, onstack, false);
	if (unlikely(!obj)) {
           ....

Does not use IS_ERR() at all and _is_ completely correct because
lookup_object_or_alloc() can only return NULL or a valid object but
never an error pointer because the 'alloc_ifstatic' argument is NULL.

debug_object_activate():
	obj = lookup_object_or_alloc(addr, db, descr, false, true);
	if (unlikely(!obj)) {
           ....
	} else if (likely(!IS_ERR(obj))) {
           ....

handles both the NULL pointer and the error pointer case correctly.

I have no idea which code you were analyzing or which tool halluzinated
about it.

> Fixes: 63a759694eed ("debugobject: Prevent init race with static objects")

There is nothing broken, so this fixes nothing.

Thanks,

        tglx