CVE-2026-64293: iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read

In the Linux kernel, the following vulnerability has been resolved:

iommufd: Use sizeof(hdr) instead of sizeof(hdr) in veventq read

The bound-check in iommufdveventqfopsread() for the normal vEVENT path uses sizeof(hdr) where the surrounding code uses sizeof(hdr):

if (!veventforlosteventsheader(cur) && sizeof(hdr) + cur->datalen > count - done) {

hdr is declared as struct iommufdveventheader , so sizeof(hdr) evaluates to the size of the pointer. Surrounding code uses sizeof(hdr) consistently:

if (done >= count || sizeof(hdr) > count - done) { ... if (copytouser(buf + done, hdr, sizeof(hdr))) { ... done += sizeof(hdr);

struct iommufdveventheader is currently 8 bytes (two u32 fields, flags and sequence), so on 64-bit (sizeof(void ) == 8) the two expressions happen to be equal and the check works as intended.

On 32-bit (sizeof(void ) == 4) the check under-counts the header by 4 bytes: a vEVENT whose datalen causes 8 + cur->datalen to exceed count - done while 4 + cur->datalen does not will pass the check, then the loop will copytouser 8 bytes of header followed by datalen bytes of payload, writing past the user-supplied buffer.

It is also a latent bug for any future expansion of struct iommufdveventheader beyond sizeof(void ) on 64-bit; the check should not depend on the type happening to match the host pointer width.

Use sizeof(hdr) to match the rest of the function and the actual amount that will be copied.