public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
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
Date: Sun, 16 Nov 2025 19:08:07 +0100	[thread overview]
Message-ID: <87v7j997g8.ffs@tglx> (raw)
In-Reply-To: <87bjl2anrb.ffs@tglx>

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

      reply	other threads:[~2025-11-16 18:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-10  7:57 [PATCH] debug: Fix a NULL vs IS_ERR() bug in __debug_object_init() Haotian Zhang
2025-11-10 13:39 ` Kuan-Wei Chiu
2025-11-11  2:15 ` [PATCH v2] debug: Fix a mixed use of NULL and error pointers Haotian Zhang
2025-11-13 19:49   ` Kuan-Wei Chiu
2025-11-13 20:03   ` Kuan-Wei Chiu
2025-11-14  1:56 ` [PATCH v3] debugobjects: Fix inconsistent return handling and potential ERR_PTR dereference Haotian Zhang
2025-11-15 23:18   ` Thomas Gleixner
2025-11-16 18:08     ` Thomas Gleixner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v7j997g8.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=visitorckw@gmail.com \
    --cc=vulab@iscas.ac.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox