CVE-2026-64293iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read
Updated under an hour ago ()
Does this affect you?
It affects Linux and 1 other product. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- 7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Analyzed
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from e36ba5ab808ef6237c3148d469c8238674230e2b before 04a177f91160ee18da98f5689482cf0f589ec869; from e36ba5ab808ef6237c3148d469c8238674230e2b before 0cdbb97a4dbd69abdd2ab998b4fbc7803d4b0b72; from e36ba5ab808ef6237c3148d469c8238674230e2b before be93d186ae88a92e7aa77e122d4e661fa57b1e39 | CNA record |
linux linux_kernel linux:linux_kernel | from 6.15 before 6.18.39; from 6.19 before 7.1.4 | NVD |
References
- https://git.kernel.org/stable/c/04a177f91160ee18da98f5689482cf0f589ec869patch
- https://git.kernel.org/stable/c/0cdbb97a4dbd69abdd2ab998b4fbc7803d4b0b72patch
- https://git.kernel.org/stable/c/be93d186ae88a92e7aa77e122d4e661fa57b1e39patch
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.