Linux i915 GPU kernel driver (execbuffer2 ioctl): The execbuffer2 ioctl accepted a userspace-supplied address without

Impact

The execbuffer2 ioctl accepted a userspace-supplied address without an access_ok() check, so a local user submitting GPU work could get the kernel to touch an arbitrary address. Execbuffer is the hot path every GPU workload uses, which makes this trivially reachable from any GPU-enabled container.

Who can reach it

Any local user or container with a DRM render node - i.e. any tenant that was scheduled a GPU. No privileged capability needed.

What to do

Fix ships in the Linux kernel. Update the kernel and reboot the node - in practice this is a drain plus reboot because the accelerator driver cannot be unloaded while jobs hold device file descriptors. No BIOS or firmware update needed.

References

Related entries

• Intel i915 graphics kernel-mode driver for Linux (< 5.0): Insufficient input validation in the i915 kernel-mode driverCVE-2019-11085 · Intel i915 graphics kernel-mode driver for Linux (< 5.0)High
• Linux kernel (ptrace): Broken permission and object lifetime handling for PTRACE_TRACEME, local rootCVE-2019-13272 · Linux kernel (ptrace)High
• AMD Radeon Kernel Mode driver - Escape 0x2000c00 call handler: A low-privileged attacker can drive the RadeonCVE-2020-12964 · AMD Radeon Kernel Mode driver - Escape 0x2000c00 call handlerHigh
• Linux i915 GPU kernel driver: A use-after-free in the i915 GPU kernel driver. The general shape is that a GPU object isCVE-2020-7053 · Linux i915 GPU kernel driverHigh
• Linux kernel (netfilter x_tables): Heap out-of-bounds write in xt_compat_target_from_user()CVE-2021-22555 · Linux kernel (netfilter x_tables)High
• sudo: Baron Samedit: heap overflow in sudo argument parsing, root from any local accountCVE-2021-3156 · sudoHigh