Re: [PATCH 1/2] drm/panic: Fix kmsg screen hang on a long log line

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/panic: pointer underflow and off-by-one line skipping
--

commit 0e87da3652905d3ac59b3e4a4293f550785dff6f
Author: Devin Wittmayer <lucid_duck@justthetip.ca>

drm/panic: Fix kmsg screen hang on a long log line

This commit increases the size of kmsg_buf and makes it static to avoid 
stack issues. It also adds a check to stop reading if kmsg_len is 0,
preventing an infinite loop when a log record doesn't fit in the buffer.

> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
> index e576c4791861d..29b1487de7ae0 100644
> --- a/drivers/gpu/drm/drm_panic.c
> +++ b/drivers/gpu/drm/drm_panic.c
[ ... ]
> @@ -574,6 +575,10 @@ static void draw_panic_screen_kmsg(struct drm_scanout_buffer *sb)
>  		char *start;
>  		char *end;
>  
> +		/* a record that does not fit comes back empty, every time */
> +		if (!kmsg_len)
> +			break;
> +
>  		/* ignore terminating NUL and newline */
>  		start = kmsg_buf + kmsg_len - 2;
>  		end = kmsg_buf + kmsg_len - 1;

[Severity: High]
Does this code underflow the pointer arithmetic if kmsg_len is 1? For
example, an empty printk that just outputs a newline would have a length
of 1, resulting in start pointing to kmsg_buf - 1, which causes undefined
behavior.

Also, looking at the code immediately following this in
draw_panic_screen_kmsg():

    while (start > kmsg_buf && yoffset >= 0) {
        ...

Does the strict inequality prematurely terminate parsing? It appears it
would silently drop 1-char lines. It also seems to skip the first log line of
every kmsg dump chunk, because the loop stops before processing when start
reaches kmsg_buf.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016052722.60051-1-lucid_duck@justthetip.ca?part=1