From nobody Sun Jun 29 18:40:02 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bVdPy5yBWz60XHC for ; Sun, 29 Jun 2025 18:40:06 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from smtp-42aa.mail.infomaniak.ch (smtp-42aa.mail.infomaniak.ch [84.16.66.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "relay.mail.infomaniak.ch", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4bVdPy03g4z43r1 for ; Sun, 29 Jun 2025 18:40:06 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 84.16.66.170 is neither permitted nor denied by domain of dumbbell@FreeBSD.org) smtp.mailfrom=dumbbell@FreeBSD.org; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none) Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4bVdPw0hZBz4D1; Sun, 29 Jun 2025 20:40:04 +0200 (CEST) Received: from unknown by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4bVdPv44SzzTfC; Sun, 29 Jun 2025 20:40:03 +0200 (CEST) Message-ID: Date: Sun, 29 Jun 2025 20:40:02 +0200 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 81e6c0168d46 - main - lindebugfs.c: Fix possible NULL dereference To: Mark Millard , dev-commits-src-main@freebsd.org References: <98C6A324-35AD-471D-9A95-ABD34657BD98.ref@yahoo.com> <98C6A324-35AD-471D-9A95-ABD34657BD98@yahoo.com> Content-Language: en-US, fr From: =?UTF-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= Organization: The FreeBSD Project In-Reply-To: <98C6A324-35AD-471D-9A95-ABD34657BD98@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Infomaniak-Routing: alpha X-Spamd-Result: default: False [1.22 / 15.00]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_MIXED_CHARSET(0.71)[subject]; RWL_MAILSPIKE_EXCELLENT(-0.40)[84.16.66.170:from]; RCVD_IN_DNSWL_LOW(-0.10)[84.16.66.170:from]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[dumbbell]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:29222, ipnet:84.16.64.0/19, country:CH] X-Rspamd-Queue-Id: 4bVdPy03g4z43r1 X-Spamd-Bar: + On 24/06/2025 04:38, Mark Millard wrote: > Jean-Sébastien Pédron 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