U-Boot EUVD-2026-89430

Exploitation requires that U-Boot process an attacker-supplied RLE8-compressed BMP image through its BMP display path (e.g. the boot splash-screen feature or a 'bmp display' invocation) - the crafted image is the exact prerequisite. The vulnerable code lacks framebuffer bounds checking on RLE run counts, so the attacker must control the content of the displayed BMP, which in most deployments means write access to the boot media, splash partition, or the environment-configured image source, or the ability to feed the image over whatever boot-time channel a given board uses. Limiting factors: the BMP-display/RLE8 path and a splash/logo configuration must be in use; primary impact is a crash/DoS with only limited integrity corruption and no confidentiality loss; and the vendor's AT:P plus adjacent vector indicate this is not remote-unauthenticated against arbitrary default configurations.

This is a moderate-severity memory-corruption flaw whose real-world risk is materially lower than its 6.0 CVSS4 score might suggest at a glance. The vendor vector (CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H) is availability-dominant: the confirmed impact is memory corruption adjacent to the framebuffer and a bootloader crash (VA:H), with only limited integrity impact (VI:L) and no confidentiality impact (VC:N). No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so exploitation status is 'no public exploit identified at time of analysis' - this is not confirmed active exploitation and should not be treated as a zero-day. The AT:P (attack requirements: present) and AV:A choices signal that exploitation is not turnkey: the attacker must get a crafted RLE8-compressed BMP into the exact code path that renders it. The vendor's PR:N (unauthenticated) is defensible only if the BMP is delivered via an unauthenticated channel (e.g. a network/splash source); in the more common case where the attacker must first plant the image on boot media or in an env-configured splash location, effective privileges are higher - this is a genuine ambiguity to verify. The patch is confirmed available (commit 5201e83342d6). Net: a real, patch-worthy defensive-hardening bug in an extremely widely deployed component, but the narrow trigger (must control the displayed BMP), crash-only primary impact, and absence of exploitation signals keep it a medium, not urgent, priority.

An attacker who can influence the BMP image the bootloader renders - for example by writing a malicious boot logo to a splash-screen partition/storage location or supplying it over a boot-time image channel - crafts an RLE8-compressed BMP whose run-length counts drive writes past the end of the framebuffer. When U-Boot decodes and displays the image, video_display_rle8_bitmap writes out-of-bounds, corrupting memory adjacent to the framebuffer and crashing the bootloader (denial of service), with potential for limited memory corruption. No public exploit code is currently identified, and the attack requires control over the displayed image rather than a simple remote request.