In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock<\/p>\n
Fix an issue where userspace or the guest can program an Hyper-V
\nsynthetic timer to have a deadline in the past via integer overflow,
\npreventing the CPU from making progress and triggering an RCU stall.<\/p>\n
Hyper-V’s SynIC exposes 4 per-vCPU synthetic timers to the
\nguest, which are emulated by KVM. Each is programmed through the
\nHV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending
\non CONFIG, COUNT represents either the absolute expiration time or the
\nperiod of a periodic timer, both expressed in 100ns ticks. These timers
\nmay be set both by the guest (WRMSR) and the host (KVM_SET_MSRS).<\/p>\n
When the timer is enabled, stimer_start() translates COUNT to an
\nabsolute monotonic deadline and arms an hrtimer. If COUNT is set to a
\nvalue close to U64_MAX, the deadline calculation can overflow.<\/p>\n
ktime_add_ns(ktime_now, 100 * (stimer->exp_time – time_now))<\/p>\n
This can result in a CPU livelock. stimer_start() arms the timer
\nvia hrtimer_start() with a deadline in the past, which causes it to
\nimmediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with
\nthe intention of causing KVM to deliver a synthetic interrupt on the
\nnext vCPU guest enter.<\/p>\n
Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the
\nrequest, calling kvm_hv_process_stimers(). This would normally disable
\nthe timer via stimer_expiration() once the deadline is in the past.
\nHowever, the deadline comparison is done between the KVM reference
\ncounter and stime->exp_time, which is a big value close to U64_MAX, so
\nthis never happens for a few thousand years.<\/p>\n
kvm_hv_process_timers() then re-arms the timer via stimer_start(), since
\nit was not disabled, which again fires immediately. Before entering
\nthe guest, kvm_vcpu_exit_request() checks kvm_request_pending(),
\nwhich returns true due to the newly raised KVM_REQ_HV_STIMER. Then
\nvcpu_enter_guest() aborts the guest entry, returning early into
\nvcpu_run(), which loops back again into vcpu_enter_guest(), restarting
\nthe cycle.<\/p>\n
Since there are no manual yields in this loop, a task with SCHED_FIFO
\nmay starve RCU grace-period kthreads, which exposes the stalls found
\nby syzcaller:<\/p>\n
rcu: INFO: rcu_preempt detected stalls on CPUs\/tasks:
\n rcu: (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2)
\n rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0
\n rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
\n rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
\n ( … )
\n Call Trace:<\/p>\n
__run_hrtimer kernel\/time\/hrtimer.c:1773 [inline]
\n __hrtimer_run_queues+0x408\/0xc30 kernel\/time\/hrtimer.c:1841
\n hrtimer_interrupt+0x45b\/0xaa0 kernel\/time\/hrtimer.c:1903
\n local_apic_timer_interrupt arch\/x86\/kernel\/apic\/apic.c:1045 [inline]
\n __sysvec_apic_timer_interrupt+0x102\/0x3e0 arch\/x86\/kernel\/apic\/apic.c:1062
\n instr_sysvec_apic_timer_interrupt arch\/x86\/kernel\/apic\/apic.c:1056 [inline]
\n sysvec_apic_timer_interrupt+0xa1\/0xc0 arch\/x86\/kernel\/apic\/apic.c:1056<\/p>\n
asm_sysvec_apic_timer_interrupt+0x1a\/0x20 arch\/x86\/include\/asm\/idtentry.h:697
\n RIP: 0010:__raw_spin_unlock_irqrestore include\/linux\/spinlock_api_smp.h:152 [inline]
\n RIP: 0010:_raw_spin_unlock_irqrestore+0xa8\/0x110 kernel\/locking\/spinlock.c:194
\n Code: 74 05 e8 0b f4 5f f6 48 c7 44 24 20 00 00 00 00 9c 8f 44 24 20 f6 44 24 21 02 75 4f f7 c3 00 02 00 00 74 01 fb bf 01 00 00 00 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36
\n RSP: 0018:ffffc900040a7320 EFLAGS: 00000206
\n RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900
\n RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001
\n RBP: ffffc900040a73b0 R08: ffffffff8fc3d0
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock<\/p>\n
Fix an issue where userspace or the guest can program an Hyper-V
\nsynthe<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24614","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}