CVE-2025-68259

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Don&amp;#39;t skip unrelated instruction if INT3/INTO is replaced<br /> <br /> When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn<br /> instruction, discard the exception and retry the instruction if the code<br /> stream is changed (e.g. by a different vCPU) between when the CPU<br /> executes the instruction and when KVM decodes the instruction to get the<br /> next RIP.<br /> <br /> As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject<br /> INT3/INTO instead of retrying the instruction"), failure to verify that<br /> the correct INTn instruction was decoded can effectively clobber guest<br /> state due to decoding the wrong instruction and thus specifying the<br /> wrong next RIP.<br /> <br /> The bug most often manifests as "Oops: int3" panics on static branch<br /> checks in Linux guests. Enabling or disabling a static branch in Linux<br /> uses the kernel&amp;#39;s "text poke" code patching mechanism. To modify code<br /> while other CPUs may be executing that code, Linux (temporarily)<br /> replaces the first byte of the original instruction with an int3 (opcode<br /> 0xcc), then patches in the new code stream except for the first byte,<br /> and finally replaces the int3 with the first byte of the new code<br /> stream. If a CPU hits the int3, i.e. executes the code while it&amp;#39;s being<br /> modified, then the guest kernel must look up the RIP to determine how to<br /> handle the #BP, e.g. by emulating the new instruction. If the RIP is<br /> incorrect, then this lookup fails and the guest kernel panics.<br /> <br /> The bug reproduces almost instantly by hacking the guest kernel to<br /> repeatedly check a static branch[1] while running a drgn script[2] on<br /> the host to constantly swap out the memory containing the guest&amp;#39;s TSS.<br /> <br /> [1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a<br /> [2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b