Re: [PATCH v9 07/39] dyndbg: factor ddebug_match_desc out from ddebug_change
flat view
From: sashiko-bot@kernel.org
Date: 2026-09-09 01:03:39
Also in:
dri-devel
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Incomplete check for NULL `dp->format` bypasses the intended protection when `query->format` is NULL. -- commit 6e852d37b2302458d6d8e267b4a7058839bebf01 Author: Jim Cromie [off-list ref] dyndbg: factor ddebug_match_desc out from ddebug_change This commit factors out the descriptor matching logic from ddebug_change() into a new ddebug_match_desc() boolean function. It replaces inner loop continue statements with return false to simplify the logic, and elevates a check for a NULL format string to report an error and skip the descriptor.
quoted hunk ↗ jump to hunk
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 49334d1aa4b3a..46ef31328194e 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -172,6 +172,59 @@ static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table cons
[ ... ]
quoted hunk ↗ jump to hunk
+ /* match against the format */ + if (query->format) { + if (!dp->format) { + pr_err_ratelimited("ddebug: NULL format string at %s:%s:%u\n", + dp->filename ? dp->filename : "?", + dp->function ? dp->function : "?", + dp->lineno); + return false; + }
[Severity: Medium] Does nesting the !dp->format check inside if (query->format) bypass the intended protection when a query does not filter by format? If a user issues a query without a format filter (for example, echo 'module * +p' > control), query->format is NULL. This skips the evaluation of the inner check entirely. Can this allow a malformed descriptor to be enabled, leading to the kernel crashing later in __dynamic_pr_debug() when the missing format is executed? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260908-dd-cmap-part2-clean-v9-0-3a3f621f4a10@gmail.com?part=7