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: 12+ 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 16:13 ` ✗ LGCI.VerificationFailed: failure for debugfs: disallow NULL string creation and fix callers Patchwork
2026-03-23 18:15 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.