Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] NULL pointer dereference in the DRM panic handler via `utsname()` if the system panics during task exit. -- commit 5f4f34c2248e13bf1786a1ff3cbb5f0cbb86fc3d Author: Thomas Zimmermann <[email protected]> drm/panic: Do not use un-escaped URL as format string This commit replaces the direct use of DRM_PANIC_SCREEN_QR_CODE_URL in snprintf() with a %s conversion specifier. This change avoids a potential vulnerability from a crafted URL string. > diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c > index e576c4791861d..ba21df4be3380 100644 > --- a/drivers/gpu/drm/drm_panic.c > +++ b/drivers/gpu/drm/drm_panic.c > @@ -658,7 +658,8 @@ static int drm_panic_get_qr_code_url(u8 **qr_image) > char *kmsg; > int max_qr_data_size, url_len; > > - url_len = snprintf(url, sizeof(url), > CONFIG_DRM_PANIC_SCREEN_QR_CODE_URL "?a=%s&v=%s&z=", > + url_len = snprintf(url, sizeof(url), "%s?a=%s&v=%s&z=", > + CONFIG_DRM_PANIC_SCREEN_QR_CODE_URL, > utsname()->machine, utsname()->release); [Severity: High] This is a pre-existing issue, but can dereferencing utsname() here cause a NULL pointer dereference if the system panics during task exit? The utsname() macro expands to (¤t->nsproxy->uts_ns->name). If a panic occurs while the current task is exiting (for example, after exit_task_namespaces() has set current->nsproxy to NULL), dereferencing current->nsproxy will cause a nested oops. This would abort the panic screen rendering and prevent the QR code or kmsg from being displayed, defeating the purpose of the DRM panic handler. Would it be safer to use init_utsname() instead of utsname() here in drm_panic_get_qr_code_url(), similar to how the standard kernel panic and dump code handles this edge case? > > max_qr_data_size = drm_panic_qr_max_data_size(panic_qr_version, > url_len); -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
