[PATCH v8 1/6] firmware: meson: sm: video firmware loading via secure monitor

sashiko-bot at kernel.org sashiko-bot at kernel.org
Mon Aug 31 01:43:31 PDT 2026


Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Information leak in `serial_show` due to uninitialized kernel heap memory being exposed on short reads.
--

commit 024494408ffd3466033a6280dd28a958f93f1072
Author: Zhentao Guo <zhentao.guo at amlogic.com>

firmware: meson: sm: video firmware loading via secure monitor

Add SM_LOAD_VIDEO_FW to the secure monitor command enum to allow decoder
drivers to load firmware through the meson_sm interface.

> diff --git a/include/linux/firmware/meson/meson_sm.h b/include/linux/firmware/meson/meson_sm.h
> index 3ebc2bd9a9760..3b90b49d05529 100644
> --- a/include/linux/firmware/meson/meson_sm.h
> +++ b/include/linux/firmware/meson/meson_sm.h
> @@ -15,6 +15,7 @@ enum {
>  	SM_THERMAL_CALIB_READ,
>  	SM_A1_PWRC_SET,
>  	SM_A1_PWRC_GET,
> +	SM_LOAD_VIDEO_FW,
>  };

[Severity: High]
This is a pre-existing issue, but while reviewing this secure monitor
addition I noticed a potential information leak in serial_show() in
drivers/firmware/meson/meson_sm.c.

Could a short read in meson_sm_call_read() leak uninitialized kernel memory
to unprivileged local users reading the sysfs serial attribute?

drivers/firmware/meson/meson_sm.c:serial_show() {
    ...
	id_buf = kmalloc(SM_CHIP_ID_LENGTH, GFP_KERNEL);
	if (!id_buf)
		return -ENOMEM;

	ret = meson_sm_call_read(fw, id_buf, SM_CHIP_ID_LENGTH, SM_GET_CHIP_ID,
				 0, 0, 0, 0, 0);
	if (ret < 0) {
		kfree(id_buf);
		return ret;
	}

	ret = sprintf(buf, "%12phN\n", &id_buf[SM_CHIP_ID_OFFSET]);
    ...
}

If the secure monitor returns a positive size smaller than 16,
meson_sm_call_read() only copies those bytes. The check for ret < 0 will
not catch this short read.

Because id_buf is allocated without zeroing and the sysfs attribute is
world-readable (DEVICE_ATTR_RO), sprintf() will unconditionally format 12
bytes starting at SM_CHIP_ID_OFFSET, which could expose uninitialized
kernel heap memory.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-b4-s4-vdec-upstream-v8-0-830195b9bd91@amlogic.com?part=1



More information about the linux-amlogic mailing list