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 <[email protected]> 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. > 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 [ ... ] > @@ -172,6 +172,59 @@ static struct ddebug_class_map > *ddebug_find_valid_class(struct ddebug_table cons [ ... ] > + /* 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/[email protected]?part=7
