Wind River Support Network

Description

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