CVE-2026-64293 in Linux
Summary
by MITRE • 07/25/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability exists within the Linux kernel's iommufd subsystem, specifically in the veventq read functionality where improper size calculation leads to potential buffer overflows. This issue affects the iommufd_veventq_fops_read() function which handles normal vEVENT path operations. The flaw stems from a mismatch in size calculations where sizeof(hdr) is used instead of sizeof(hdr) in a critical bounds check. Here the variable hdr is declared as a pointer to struct iommufd_vevent_header, making sizeof(hdr) evaluate to the size of the pointer rather than the actual structure size. This inconsistency creates a security risk that manifests differently based on architecture, with particularly severe implications on 32-bit systems where the discrepancy results in a 4-byte undercounting error. The surrounding code within the same function consistently uses sizeof(hdr) for proper size calculations, making this deviation a clear coding error that breaks expected behavior.
The operational impact of this vulnerability is significant as it creates a potential buffer overflow condition when processing vEVENT data structures. When the bounds check fails due to incorrect size calculation, the system proceeds to copy more data than the user-supplied buffer can accommodate. Specifically, on 32-bit architectures, the function incorrectly allows copying 8 bytes of header data plus payload when it should only copy 4 bytes less, resulting in memory corruption that could be exploited by malicious actors. The vulnerability is particularly dangerous because it depends on architecture-specific pointer sizes and would remain undetected during normal operation until a specific data pattern triggers the overflow condition. This type of memory corruption can lead to system instability, privilege escalation, or denial of service attacks.
The technical implementation flaw directly violates proper coding practices that should ensure size calculations match actual data being processed. The vulnerability demonstrates poor adherence to defensive programming principles and highlights the importance of consistent type handling throughout code sections. According to CWE guidelines, this represents a buffer overflow vulnerability classified as CWE-121, where insufficient bounds checking allows for memory access beyond allocated boundaries. The issue also aligns with ATT&CK technique T1068 which covers privilege escalation through local exploits. The root cause is fundamentally an incorrect use of sizeof operator on a pointer type rather than the dereferenced structure, creating a mismatch between what is checked and what is actually copied to user space.
Mitigation strategies should focus on immediate code correction by replacing sizeof(hdr) with sizeof(*hdr) throughout the affected function to ensure consistent size calculations. System administrators should prioritize kernel updates that address this specific vulnerability through proper patching procedures. The fix requires careful review of similar patterns within the same codebase to prevent analogous issues from persisting elsewhere. Additionally, implementing stricter static analysis tools and code reviews can help catch such pointer-size mismatches in future development cycles. Regular security audits should examine all functions using sizeof with pointer variables to ensure they properly account for actual data structure sizes rather than pointer widths, particularly important given that modern architectures may vary in their pointer size implementations.
This vulnerability serves as a reminder of how subtle coding errors can create significant security implications, especially in kernel space where memory corruption directly impacts system integrity. The fact that the issue only manifests on certain architectures makes it particularly dangerous as it may go undetected during testing phases, creating a latent security risk that could be exploited in production environments. Proper defensive programming practices and consistent code review processes are essential to prevent such issues from reaching production systems.