CVE-2026-31588

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Use scratch field in MMIO fragment to hold small write values<br /> <br /> When exiting to userspace to service an emulated MMIO write, copy the<br /> to-be-written value to a scratch field in the MMIO fragment if the size<br /> of the data payload is 8 bytes or less, i.e. can fit in a single chunk,<br /> instead of pointing the fragment directly at the source value.<br /> <br /> This fixes a class of use-after-free bugs that occur when the emulator<br /> initiates a write using an on-stack, local variable as the source, the<br /> write splits a page boundary, *and* both pages are MMIO pages. Because<br /> KVM&amp;#39;s ABI only allows for physically contiguous MMIO requests, accesses<br /> that split MMIO pages are separated into two fragments, and are sent to<br /> userspace one at a time. When KVM attempts to complete userspace MMIO in<br /> response to KVM_RUN after the first fragment, KVM will detect the second<br /> fragment and generate a second userspace exit, and reference the on-stack<br /> variable.<br /> <br /> The issue is most visible if the second KVM_RUN is performed by a separate<br /> task, in which case the stack of the initiating task can show up as truly<br /> freed data.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420<br /> Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984<br /> <br /> CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace:<br /> dump_stack+0xbe/0xfd<br /> print_address_description.constprop.0+0x19/0x170<br /> __kasan_report.cold+0x6c/0x84<br /> kasan_report+0x3a/0x50<br /> check_memory_region+0xfd/0x1f0<br /> memcpy+0x20/0x60<br /> complete_emulated_mmio+0x305/0x420<br /> kvm_arch_vcpu_ioctl_run+0x63f/0x6d0<br /> kvm_vcpu_ioctl+0x413/0xb20<br /> __se_sys_ioctl+0x111/0x160<br /> do_syscall_64+0x30/0x40<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> RIP: 0033:0x42477d<br /> Code: 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d<br /> RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005<br /> RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c<br /> R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720<br /> <br /> The buggy address belongs to the page:<br /> page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37<br /> flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> &gt;ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ^<br /> ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ==================================================================<br /> <br /> The bug can also be reproduced with a targeted KVM-Unit-Test by hacking<br /> KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by<br /> overwrite the data value with garbage.<br /> <br /> Limit the use of the scratch fields to 8-byte or smaller accesses, and to<br /> just writes, as larger accesses and reads are not affected thanks to<br /> implementation details in the emulator, but add a sanity check to ensure<br /> those details don&amp;#39;t change in the future. Specifically, KVM never uses<br /> on-stack variables for accesses larger that 8 bytes, e.g. uses an operand<br /> in the emulator context, and *al<br /> ---truncated---