In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: harden firmware build-info bounds checks
panthor_fw_read_build_info() checks whether the metadata range fits in the
firmware image with hdr.meta_start + hdr.meta_size. Both fields are u32, so
the addition can wrap and let an out-of-bounds range pass validation.
The function also reads the "git_sha: " prefix without first checking that
the metadata is long enough, and meta_size == 0 can underflow the NULL
terminator index.
Use subtraction-based bounds checking and reject metadata that is too short
to contain the expected prefix and trailing NULL byte.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS Score: 7.1
AV:L - The out-of-bounds reads occur only while panthor_fw_load() parses mali_csffw.bin from the local firmware search path at platform probe (panthor_probe→panthor_fw_init→panthor_fw_load_entry→panthor_fw_read_build_info); no network, DRM ioctl, or /dev/dri/renderD* path supplies attacker-controlled build-info headers.
AC:L - An attacker fully controls the BUILD_INFO_METADATA u32 meta_start and meta_size fields. Setting both to 0, using meta_size shorter than the git_sha prefix, or wrapping meta_start+meta_size deterministically bypasses the old addition check and performs the OOB memcmp, terminator, and %s reads on every load with no race.
PR:L - panthor_fw_read_build_info() performs no capability or authentication checks on firmware content; on Mali CSF Android, Chromebook, and embedded deployments the GPU firmware image commonly lives on vendor/firmware partitions writable by local non-root system or vendor service accounts, sufficient to plant the crafted blob before driver probe.
UI:N - After the malicious mali_csffw.bin is in the firmware search path, panthor_fw_read_build_info() runs automatically during driver probe at boot or bind; no separate victim action such as opening a device node or mounting a filesystem is required.
S:U - The out-of-bounds kernel reads and any resulting oops remain inside the host kernel that loads the Panthor firmware; this is not a VM escape, IOMMU bypass, or other cross-authority breakout.
C:H - A wrapping or zero meta_size lets drm_info("%s") walk from the git_sha prefix through kernel memory adjacent to the firmware vmalloc buffer until a NUL, and meta_start==0 with meta_size==0 indexes fw->data[0xFFFFFFFF]; these are unbounded out-of-bounds reads, not a few-byte leak.
I:N - panthor_fw_read_build_info() only memcmp()s, indexes, and prints firmware bytes; the wrapping metadata range is never used as a write destination, so there is no out-of-bounds write, use-after-free, or control-flow hijack primitive.
A:H - Firmware blobs are vmalloc allocations with guard pages, so the 0xFFFFFFFF terminator index (meta_start=meta_size=0) or an unbounded drm_info %s walk past fw->size readily faults into an unmapped page and oopses or panics the kernel during Mali/Panthor GPU probe.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The out-of-bounds reads occur only while panthor_fw_load() parses mali_csffw.bin from the local firmware search path at platform probe (panthor_probe→panthor_fw_init→panthor_fw_load_entry→panthor_fw_read_build_info); no network, DRM ioctl, or /dev/dri/renderD* path supplies attacker-controlled build-info headers.
AC:L - An attacker fully controls the BUILD_INFO_METADATA u32 meta_start and meta_size fields. Setting both to 0, using meta_size shorter than the git_sha prefix, or wrapping meta_start+meta_size deterministically bypasses the old addition check and performs the OOB memcmp, terminator, and %s reads on every load with no race.
PR:L - panthor_fw_read_build_info() performs no capability or authentication checks on firmware content; on Mali CSF Android, Chromebook, and embedded deployments the GPU firmware image commonly lives on vendor/firmware partitions writable by local non-root system or vendor service accounts, sufficient to plant the crafted blob before driver probe.
UI:N - After the malicious mali_csffw.bin is in the firmware search path, panthor_fw_read_build_info() runs automatically during driver probe at boot or bind; no separate victim action such as opening a device node or mounting a filesystem is required.
S:U - The out-of-bounds kernel reads and any resulting oops remain inside the host kernel that loads the Panthor firmware; this is not a VM escape, IOMMU bypass, or other cross-authority breakout.
C:H - A wrapping or zero meta_size lets drm_info("%s") walk from the git_sha prefix through kernel memory adjacent to the firmware vmalloc buffer until a NUL, and meta_start==0 with meta_size==0 indexes fw->data[0xFFFFFFFF]; these are unbounded out-of-bounds reads, not a few-byte leak.
I:N - panthor_fw_read_build_info() only memcmp()s, indexes, and prints firmware bytes; the wrapping metadata range is never used as a write destination, so there is no out-of-bounds write, use-after-free, or control-flow hijack primitive.
A:H - Firmware blobs are vmalloc allocations with guard pages, so the 0xFFFFFFFF terminator index (meta_start=meta_size=0) or an unbounded drm_info %s walk past fw->size readily faults into an unmapped page and oopses or panics the kernel during Mali/Panthor GPU probe.
CVSS 3.1