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 <[email protected]> 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/[email protected]?part=1
