iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read
Summary
| CVE | CVE-2026-64293 |
|---|---|
| State | PUBLISHED |
| Assigner | Linux |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-07-25 10:17:10 UTC |
| Updated | 2026-07-30 15:00:27 UTC |
| Description | 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. |
Risk And Classification
Primary CVSS: v3.1 7.8 HIGH from 416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS: 0.001620000 probability, percentile 0.058270000 (date 2026-08-03)
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | Secondary | 7.8 | HIGH | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | CNA | DECLARED | 7.8 | HIGH | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
CVSS v3.1 Breakdown
Attack Vector
LocalAttack Complexity
LowPrivileges Required
LowUser Interaction
NoneScope
UnchangedConfidentiality
HighIntegrity
HighAvailability
HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Linux | Linux | affected e36ba5ab808ef6237c3148d469c8238674230e2b 04a177f91160ee18da98f5689482cf0f589ec869 git | Not specified |
| CNA | Linux | Linux | affected e36ba5ab808ef6237c3148d469c8238674230e2b 0cdbb97a4dbd69abdd2ab998b4fbc7803d4b0b72 git | Not specified |
| CNA | Linux | Linux | affected e36ba5ab808ef6237c3148d469c8238674230e2b be93d186ae88a92e7aa77e122d4e661fa57b1e39 git | Not specified |
| CNA | Linux | Linux | affected 6.15 | Not specified |
| CNA | Linux | Linux | unaffected 6.15 semver | Not specified |
| CNA | Linux | Linux | unaffected 6.18.39 6.18.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.1.4 7.1.* semver | Not specified |
| CNA | Linux | Linux | unaffected 7.2-rc1 * original_commit_for_fix | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| git.kernel.org/stable/c/0cdbb97a4dbd69abdd2ab998b4fbc7803d4b0b72 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/04a177f91160ee18da98f5689482cf0f589ec869 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| git.kernel.org/stable/c/be93d186ae88a92e7aa77e122d4e661fa57b1e39 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | git.kernel.org | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.