A recent bug report [1] highlighted a NULL pointer dereference when
reading a debugfs string file created with a NULL pointer. The community
discussed the issue and agreed that creating string nodes with NULL is
invalid and should be forbidden at creation time [2]. Since no fix was
submitted following the discussion, I have implemented the agreed
solution.
Patch 1 modifies debugfs_create_str() to reject NULL pointers, returning
early and triggering a WARN_ON to expose offending callers.
Patch 2 is a code hygiene fix. While modifying the file, I noticed the
EXPORT_SYMBOL_GPL for debugfs_create_str() was misplaced far away from
the function body. This patch moves it to the correct location.
I carefully audited existing callers across the kernel tree. Some
drivers passing NULL have already been independently identified and
fixed [3]. The remaining two subsystems (soundwire and drm/i915) are
addressed in patches 3 and 4 by initializing their respective string
parameters to empty strings (""). The existing logic in both subsystems
correctly and safely handles empty strings.
[1]
https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/2025122221-gag-malt-75ba@gregkh/
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8cc27f5c6dd1
Gui-Dong Han (4):
debugfs: check for NULL pointer in debugfs_create_str()
debugfs: fix placement of EXPORT_SYMBOL_GPL for debugfs_create_str()
soundwire: debugfs: initialize firmware_file to empty string
drm/i915/display: initialize string params to empty strings
drivers/gpu/drm/i915/display/intel_display_params.h | 4 ++--
drivers/soundwire/debugfs.c | 5 +++--
fs/debugfs/file.c | 7 +++++--
3 files changed, 10 insertions(+), 6 deletions(-)
--
2.43.0
