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 5097230C63A for ; Sun, 16 Nov 2025 18:08:10 +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=1763316491; cv=none; b=lCk4uyFHBXgDWzB7IugMsOz9T1TkHuVgZCMwLRBG6iv1ctCpuY15GrhwGIsNlN5u6T/fwOxbBvLYqMC9N1jrE0zmq632dQBx7JjIbxRrPEAHBhzkBSKTMch+2Xl1fpO7U3hprmoKzXGnJH9kJN201yK2qMjhSqT9yS7EftIzbqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763316491; c=relaxed/simple; bh=PkH7n0C0bsh4V0Fam/2SL8NXnIaAdw+WWie4ZjCC8XM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hsSvBuGnrKvbF02LUzeSuvfwKvTQLFfo8iQVZuV1MlTOP0Tj61ijVMf2Bp+HxV8qcQr9E87L/6c2m2C5DzQEUWqiaPqBcor9Dj+Z21ooU35GN8YeepBB0//RUYc7GGtEd9opGItzZtp8NFVaY1v4wt6YTakl3Ea36XuDQRKQIuY= 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=1+aA32LK; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=fNImUR6U; 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="1+aA32LK"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="fNImUR6U" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763316488; 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=XFGOFbjwiH8A0dZX0ca+zCmut5IWghGxzvaS+HTaBPY=; b=1+aA32LKdM5mZB5qgH8ScWtJZmo6OOKAVzf/8OCX8MY4dnMUWk6VGfqLX6yaWRPEejWfRK SkHDqZ5auRA9MBusGu7uoFM07q4IeGH3Tj8BNeD1+1qCSglFpIzlZOU+65nwwm6GCgTzLD M9rACX8BJ9+vmDDauSDygiLiqhruCtYN9FoWCvbJQWQOObg6WuJVA3aieYAm+3piQXP6/V 0XK4XcG8lf0B7dy5GGJkg5O6pW57EBJ5Ft4SjsfraFEHRdh6Tt/OgQ5wsEQArDXP52/w8c GRUpROSWN8I2SUsjQdvDSTkG5rJNBZd2BMGEjO1/51vqZbfNEGI1H7p7dlx37Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763316488; 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=XFGOFbjwiH8A0dZX0ca+zCmut5IWghGxzvaS+HTaBPY=; b=fNImUR6U90kRdz42rmQk1jXTfuA5nIku/sLwdzs8pzCFlbnNJO/VQJNACcmTR4jNy+pCGz QpKNX0XOAp7XGiAQ== To: Haotian Zhang , Andrew Morton , Kuan-Wei Chiu Cc: linux-kernel@vger.kernel.org, Haotian Zhang Subject: Re: [PATCH v3] debugobjects: Fix inconsistent return handling and potential ERR_PTR dereference In-Reply-To: <87bjl2anrb.ffs@tglx> References: <20251110075746.1680-1-vulab@iscas.ac.cn> <20251114015631.1729-1-vulab@iscas.ac.cn> <87bjl2anrb.ffs@tglx> Date: Sun, 16 Nov 2025 19:08:07 +0100 Message-ID: <87v7j997g8.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Sun, Nov 16 2025 at 00:18, Thomas Gleixner wrote: > 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. That said. You clearly failed to explain how you found that. I'm well aware that you are deeply involved in LLM based code analysis, so don't tell me that reviewing random code is your new hobby. Thanks, tglx