PT-2026-64514 · Linux · Linux

CVE-2026-64293

·

Published

2026-07-25

·

Updated

2026-07-25

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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 iommufd veventq fops read() for the normal vEVENT path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr):
if (!vevent for lost events header(cur) &&
  sizeof(hdr) + cur->data len > count - done) {
hdr is declared as struct iommufd vevent header *, so sizeof(hdr) evaluates to the size of the pointer. Surrounding code uses sizeof(*hdr) consistently:
if (done >= count || sizeof(*hdr) > count - done) {
...
if (copy to user(buf + done, hdr, sizeof(*hdr))) {
...
done += sizeof(*hdr);
struct iommufd vevent header 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 data len causes 8 + cur->data len to exceed count - done while 4 + cur->data len does not will pass the check, then the loop will copy to user 8 bytes of header followed by data len bytes of payload, writing past the user-supplied buffer.
It is also a latent bug for any future expansion of struct iommufd vevent header 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.
Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

CVE-2026-64293

Affected Products

Linux