GRUB2 (grub_malloc allocator): GRUB's allocator never checks the requested size for arithmetic overflow, so a tenant

Impact

GRUB's allocator never checks the requested size for arithmetic overflow, so a tenant who can influence any parsed structure gets a heap that is smaller than GRUB believes it is. The payoff is arbitrary write inside the bootloader, which means loading an unsigned kernel with Secure Boot still reporting green. On a bare-metal GPU node that is the difference between 'the next tenant gets a clean box' and 'the next tenant gets the last tenant's rootkit'.

Who can reach it

A tenant with root on a node they rented, or anyone who can write the EFI System Partition (including via BMC virtual media). Not remote on its own - it is the persistence half of a two-stage attack.

What to do

grub2 package update plus reboot on every node. The package update alone does not close it: the old signed GRUB binary stays trusted until the UEFI revocation list (dbx) is updated, and pushing dbx before every node is on the new shim/GRUB will brick nodes at next boot. Plan it as two passes with a verification gate between them.

References