From: Jani Nikula <jani.nikula@linux.intel.com>
To: Gui-Dong Han <hanguidong02@gmail.com>
Cc: gregkh@linuxfoundation.org, dakr@kernel.org, rafael@kernel.org,
rodrigo.vivi@intel.com, joonas.lahtinen@linux.intel.com,
tursulin@ursulin.net, airlied@gmail.com, simona@ffwll.ch,
gustavo.sousa@intel.com, demarchi@kernel.org,
jouni.hogander@intel.com, luciano.coelho@intel.com,
linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-sound@vger.kernel.org,
akaieurus@gmail.com, me@ziyao.cc
Subject: Re: [PATCH 4/4] drm/i915/display: initialize string params to empty strings
Date: Wed, 18 Mar 2026 10:32:14 +0200 [thread overview]
Message-ID: <8ac4b6ef2dfbc1dce0047dee55f2df609287a3ec@intel.com> (raw)
In-Reply-To: <CALbr=LadoX8g--rtU==HQfNQ9f1=KP=7AS-PGfooKaSbnYPz+Q@mail.gmail.com>
On Wed, 18 Mar 2026, Gui-Dong Han <hanguidong02@gmail.com> wrote:
> On Wed, Mar 18, 2026 at 4:12 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>
>> On Wed, 18 Mar 2026, Gui-Dong Han <hanguidong02@gmail.com> wrote:
>> > Passing NULL to debugfs_create_str() causes a NULL pointer dereference
>> > upon reading, and is no longer permitted. Change the default values of
>> > dmc_firmware_path and vbt_firmware to empty strings ("").
>> >
>> > Existing code that consumes these parameters already verifies both
>> > pointer validity and string length, so empty strings are handled
>> > correctly. Furthermore, heap allocation is not required here: these
>> > debugfs parameters are created with strictly read-only permissions
>> > (0400). As a result, the debugfs write operation is never invoked,
>> > meaning the static empty string will not be erroneously freed by
>> > kfree().
>> >
>> > Fixes: e9913f0bd2e1 ("drm/i915/display: move dmc_firmware_path to display params")
>> > Fixes: 29292bc6cc37 ("drm/i915/display: Move vbt_firmware module parameter under display")
>> > Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
>> > ---
>> > drivers/gpu/drm/i915/display/intel_display_params.h | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display_params.h b/drivers/gpu/drm/i915/display/intel_display_params.h
>> > index b95ecf728daa..0a8cad98d480 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display_params.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_display_params.h
>> > @@ -23,8 +23,8 @@ struct drm_printer;
>> > * debugfs file
>> > */
>> > #define INTEL_DISPLAY_PARAMS_FOR_EACH(param) \
>> > - param(char *, dmc_firmware_path, NULL, 0400) \
>> > - param(char *, vbt_firmware, NULL, 0400) \
>> > + param(char *, dmc_firmware_path, "", 0400) \
>> > + param(char *, vbt_firmware, "", 0400) \
>>
>> Admittedly this is all very convoluted, but these NULL pointers (or
>> pointers to them) are never passed to debugfs_create_str().
>
> Hi Jani,
>
> Thanks for your review.
>
> Could you elaborate on why they are never passed? Looking at
> intel_display_debugfs_params.c, the intel_display_debugfs_params()
> function iterates over INTEL_DISPLAY_PARAMS_FOR_EACH using the
> REGISTER macro. This eventually calls
> _intel_display_param_create_file(), which uses _Generic to dispatch
> char ** types to debugfs_create_str().
In _intel_display_param_create_file(), valp is &display->params.x, where
x is dmc_firmware_path or vbt_firmware.
display->params gets initialized using intel_display_params_copy() when
struct intel_display is allocated in intel_display_device_probe(). In
intel_display_params_copy(), _param_dup_charp() handles the NULL
initializer.
Granted, if the kstrdup() fails, you could end up having NULL there, but
at that point it's fine if your debugfs_create_str() change barfs and
bails out.
Like I said, it's convoluted. ;)
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-03-18 8:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 18:59 [PATCH 0/4] debugfs: disallow NULL string creation and fix callers Gui-Dong Han
2026-03-17 18:59 ` [PATCH 1/4] debugfs: check for NULL pointer in debugfs_create_str() Gui-Dong Han
2026-03-17 18:59 ` [PATCH 2/4] debugfs: fix placement of EXPORT_SYMBOL_GPL for debugfs_create_str() Gui-Dong Han
2026-03-17 19:10 ` [PATCH 3/4] soundwire: debugfs: initialize firmware_file to empty string Gui-Dong Han
2026-03-18 4:14 ` Gui-Dong Han
2026-03-17 19:15 ` [PATCH 4/4] drm/i915/display: initialize string params to empty strings Gui-Dong Han
2026-03-17 20:12 ` Jani Nikula
2026-03-18 1:53 ` Gui-Dong Han
2026-03-18 8:32 ` Jani Nikula [this message]
2026-03-18 8:47 ` Gui-Dong Han
2026-03-23 18:15 ` ✗ LGCI.VerificationFailed: failure for debugfs: disallow NULL string creation and fix callers Patchwork
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=8ac4b6ef2dfbc1dce0047dee55f2df609287a3ec@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=akaieurus@gmail.com \
--cc=dakr@kernel.org \
--cc=demarchi@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo.sousa@intel.com \
--cc=hanguidong02@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=jouni.hogander@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=luciano.coelho@intel.com \
--cc=me@ziyao.cc \
--cc=rafael@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
/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