In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/vcn: fix integer overflow in dec_msg buffer count check
If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression
6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting
the parser loop far past the end of the message BO. Triggering it
additionally requires a ~4GiB mapping so that msg[1] survives the
earlier "header does not fit in BO" check.
Rewrite the test in division form, which is overflow-free by
construction. Also update the message to reflect that msg is invalid.
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 bug is reached only via the local DRM_IOCTL_AMDGPU_CS ioctl on /dev/dri/renderD (amdgpu_cs_ioctl → amdgpu_cs_patch_jobs → amdgpu_cs_patch_ibs → vcn_v3/v4_0_ring_patch_cs_in_place → vcn__dec_msg). There is no network or physical path to the VCN decode-message parser.
AC:L - The attacker fully controls the decode-message GEM BO. Setting num_buffers to 0x3FFFFFFF with a ~4GiB mapping makes 6+num_buffers*4 wrap to 2 so the uint32 bounds check passes deterministically; allocating that mapping is attacker-controlled on typical GPU workstations and cloud GPU hosts.
PR:L - AMDGPU_CS is registered with DRM_AUTH|DRM_RENDER_ALLOW, so any unprivileged local user who can open the AMDGPU render node (typical render/video group on desktops, handhelds, Android, and GPU cloud instances) can submit VCN command buffers without root.
UI:N - The attacker submits the crafted VCN command buffer through their own DRM context; no separate victim action such as opening a file or mounting a filesystem is required.
S:U - The out-of-bounds read is performed by the CPU in the kernel kmap of the message BO and stays within the kernel security authority; it is not a VM escape or IOMMU/DMA boundary bypass.
C:H - Bypassing the buffer-count check lets the parser loop about 0x3FFFFFFF times, each step reading 16 bytes past the kmapped BO, an unbounded kernel out-of-bounds read well beyond a few bytes.
I:N - The loop only reads message dwords and, when a CREATE record is seen, still bounds-checks offset/size against the BO before any further access; no out-of-bounds write or control-flow hijack primitive is produced.
A:H - The unbounded walk past the kmapped BO into unmapped kernel or MMIO address space causes a page fault/oops, and the billion-iteration loop can also soft-lock the CS path before faulting.
| 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 bug is reached only via the local DRM_IOCTL_AMDGPU_CS ioctl on /dev/dri/renderD (amdgpu_cs_ioctl → amdgpu_cs_patch_jobs → amdgpu_cs_patch_ibs → vcn_v3/v4_0_ring_patch_cs_in_place → vcn__dec_msg). There is no network or physical path to the VCN decode-message parser.
AC:L - The attacker fully controls the decode-message GEM BO. Setting num_buffers to 0x3FFFFFFF with a ~4GiB mapping makes 6+num_buffers*4 wrap to 2 so the uint32 bounds check passes deterministically; allocating that mapping is attacker-controlled on typical GPU workstations and cloud GPU hosts.
PR:L - AMDGPU_CS is registered with DRM_AUTH|DRM_RENDER_ALLOW, so any unprivileged local user who can open the AMDGPU render node (typical render/video group on desktops, handhelds, Android, and GPU cloud instances) can submit VCN command buffers without root.
UI:N - The attacker submits the crafted VCN command buffer through their own DRM context; no separate victim action such as opening a file or mounting a filesystem is required.
S:U - The out-of-bounds read is performed by the CPU in the kernel kmap of the message BO and stays within the kernel security authority; it is not a VM escape or IOMMU/DMA boundary bypass.
C:H - Bypassing the buffer-count check lets the parser loop about 0x3FFFFFFF times, each step reading 16 bytes past the kmapped BO, an unbounded kernel out-of-bounds read well beyond a few bytes.
I:N - The loop only reads message dwords and, when a CREATE record is seen, still bounds-checks offset/size against the BO before any further access; no out-of-bounds write or control-flow hijack primitive is produced.
A:H - The unbounded walk past the kmapped BO into unmapped kernel or MMIO address space causes a page fault/oops, and the billion-iteration loop can also soft-lock the CS path before faulting.
CVSS 3.1