dc29ae7...
by
=?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= <email address hidden>
KVM: x86: drop error recovery in em_jmp_far and em_ret_far
em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
bit mode, but syzkaller proved otherwise (and SDM agrees).
Code segment was restored upon failure, but it was left uninitialized
outside of long mode, which could lead to a leak of host kernel stack.
We could have fixed that by always saving and restoring the CS, but we
take a simpler approach and just break any guest that manages to fail
as the error recovery is error-prone and modern CPUs don't need emulator
for this.
Found by syzkaller:
WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
Kernel panic - not syncing: panic_on_warn set ...
When packet_set_ring creates a ring buffer it will initialize a
struct timer_list if the packet version is TPACKET_V3. This value
can then be raced by a different thread calling setsockopt to
set the version to TPACKET_V1 before packet_set_ring has finished.
This leads to a use-after-free on a function pointer in the
struct timer_list when the socket is closed as the previously
initialized timer will not be deleted.
The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
changing the packet version while also taking the lock at the start
of packet_set_ring.
Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Signed-off-by: Philip Pettersson <email address hidden>
Signed-off-by: Eric Dumazet <email address hidden>
Signed-off-by: Brad Figg <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Ben Romer <email address hidden>
Commit 3dcf63677d4e ("xen/balloon: cancel ballooning if adding new
memory failed") makes reserve_additional_memory() return BP_ECANCELED
when an error is encountered. This error, however, is ignored by the
caller (balloon_process()) since it is overwritten by subsequent call
to update_schedule(). This results in continuous attempts to add more
memory, all of which are likely to fail again.
We should stop trying to schedule next iteration of ballooning when
the current one has failed.
Signed-off-by: Boris Ostrovsky <email address hidden>
Reviewed-by: Daniel Kiper <email address hidden>
Signed-off-by: David Vrabel <email address hidden>
(cherry picked from commit fd8b79511349efd1f0decea920f61b93acb34a75)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Brad Figg <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
If the balloon driver is adding additional memory regions to the
balloon and add_memory() fails it will likely continuously fail so
cancel the balloon operation.
Signed-off-by: David Vrabel <email address hidden>
Reviewed-by: Daniel Kiper <email address hidden>
(back ported from commit 3dcf63677d4eb7fdfc13290c8558c301d2588fe8)
Signed-off-by: Tim Gardner <email address hidden>
