CVE-2026-64293

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Use sizeof(*hdr) instead of sizeof(hdr) in veventq read<br /> <br /> The bound-check in iommufd_veventq_fops_read() for the normal vEVENT<br /> path uses sizeof(hdr) where the surrounding code uses sizeof(*hdr):<br /> <br /> if (!vevent_for_lost_events_header(cur) &amp;&amp;<br /> sizeof(hdr) + cur-&gt;data_len &gt; count - done) {<br /> <br /> hdr is declared as struct iommufd_vevent_header *, so sizeof(hdr)<br /> evaluates to the size of the pointer. Surrounding code uses<br /> sizeof(*hdr) consistently:<br /> <br /> if (done &gt;= count || sizeof(*hdr) &gt; count - done) {<br /> ...<br /> if (copy_to_user(buf + done, hdr, sizeof(*hdr))) {<br /> ...<br /> done += sizeof(*hdr);<br /> <br /> struct iommufd_vevent_header is currently 8 bytes (two __u32 fields,<br /> flags and sequence), so on 64-bit (sizeof(void *) == 8) the two<br /> expressions happen to be equal and the check works as intended.<br /> <br /> On 32-bit (sizeof(void *) == 4) the check under-counts the header by<br /> 4 bytes: a vEVENT whose data_len causes 8 + cur-&gt;data_len to exceed<br /> count - done while 4 + cur-&gt;data_len does not will pass the check,<br /> then the loop will copy_to_user 8 bytes of header followed by data_len<br /> bytes of payload, writing past the user-supplied buffer.<br /> <br /> It is also a latent bug for any future expansion of struct<br /> iommufd_vevent_header beyond sizeof(void *) on 64-bit; the check<br /> should not depend on the type happening to match the host pointer<br /> width.<br /> <br /> Use sizeof(*hdr) to match the rest of the function and the actual<br /> amount that will be copied.