Re: [PATCH v9 07/39] dyndbg: factor ddebug_match_desc out from ddebug_change

[sashiko-bot@kernel.org]

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 <jim.cromie@gmail.com>

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/20260908-dd-cmap-part2-clean-v9-0-3a3f621f4a10@gmail.com?part=7