Date: Sun, 29 Jun 2025 20:40:02 +0200 From: =?UTF-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= <dumbbell@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com>, dev-commits-src-main@freebsd.org Subject: Re: git: 81e6c0168d46 - main - lindebugfs.c: Fix possible NULL dereference Message-ID: <c33c2726-56ec-4375-bd84-70aefe409d64@FreeBSD.org> In-Reply-To: <98C6A324-35AD-471D-9A95-ABD34657BD98@yahoo.com> References: <98C6A324-35AD-471D-9A95-ABD34657BD98.ref@yahoo.com> <98C6A324-35AD-471D-9A95-ABD34657BD98@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24/06/2025 04:38, Mark Millard wrote:
> Jean-Sébastien Pédron <dumbbell_at_FreeBSD.org> wrote on
>> If `debugfs_destroy()` is called early as part of error handling during
>> initialzation, `pn->pn_data` is unset.
>
> "is unset": Is this wording intended to mean:
>
> A) (...)
>
> vs.
>
> B) guaranteed to have been set to either NULL
> or to a valid non-NULL pointer value?
Yes, it's scenario (B). pfs_create_{file,dir}() allocates the structure
with `M_ZERO`, thus the field is NULL at first.
debugfs_create_{file,dir}() sets `pn_data` after
`pfs_create_{file,dir}() returned successfully.
However, if pfs_create_{file,dir}() fails, it calls the given "destroy"
callback before returning NULL. Therefore, when debugfs_destroy() was
called as part of the aborted creation, it was still assuming `pn_data`
was set to its own private data; this was not the case.
I hope that clears the issue origin.
--
Jean-Sébastien Pédron
The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c33c2726-56ec-4375-bd84-70aefe409d64>