GHSA-5QJH-387M-MGRJ

Vulnerability from github – Published: 2026-09-16 12:30 – Updated: 2026-09-16 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock

Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall.

Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns ticks. These timers may be set both by the guest (WRMSR) and the host (KVM_SET_MSRS).

When the timer is enabled, stimer_start() translates COUNT to an absolute monotonic deadline and arms an hrtimer. If COUNT is set to a value close to U64_MAX, the deadline calculation can overflow.

ktime_add_ns(ktime_now, 100 * (stimer->exp_time - time_now))

This can result in a CPU livelock. stimer_start() arms the timer via hrtimer_start() with a deadline in the past, which causes it to immediately fire. The stimer callback then raises KVM_RQ_HV_STIMER, with the intention of causing KVM to deliver a synthetic interrupt on the next vCPU guest enter.

Then, once userspace issues KVM_RUN, vcpu_enter_guest() consumes the request, calling kvm_hv_process_stimers(). This would normally disable the timer via stimer_expiration() once the deadline is in the past. However, the deadline comparison is done between the KVM reference counter and stime->exp_time, which is a big value close to U64_MAX, so this never happens for a few thousand years.

kvm_hv_process_timers() then re-arms the timer via stimer_start(), since it was not disabled, which again fires immediately. Before entering the guest, kvm_vcpu_exit_request() checks kvm_request_pending(), which returns true due to the newly raised KVM_REQ_HV_STIMER. Then vcpu_enter_guest() aborts the guest entry, returning early into vcpu_run(), which loops back again into vcpu_enter_guest(), restarting the cycle.

Since there are no manual yields in this loop, a task with SCHED_FIFO may starve RCU grace-period kthreads, which exposes the stalls found by syzcaller:

rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu:    (detected by 1, t=10502 jiffies, g=14269, q=1142 ncpus=2)
rcu: All QSes seen, last rcu_preempt kthread activity 10500 (4294965239-4294954739), jiffies_till_next_fqs=1, root ->qsmask 0x0
rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
    ( ... )
Call Trace:
 <IRQ>
 __run_hrtimer kernel/time/hrtimer.c:1773 [inline]
 __hrtimer_run_queues+0x408/0xc30 kernel/time/hrtimer.c:1841
 hrtimer_interrupt+0x45b/0xaa0 kernel/time/hrtimer.c:1903
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1045 [inline]
 __sysvec_apic_timer_interrupt+0x102/0x3e0 arch/x86/kernel/apic/apic.c:1062
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
 sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1056
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline]
RIP: 0010:_raw_spin_unlock_irqrestore+0xa8/0x110 kernel/locking/spinlock.c:194
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 <e8> 23 6b 27 f6 65 8b 05 7c 60 5a 07 85 c0 74 40 48 c7 04 24 0e 36
RSP: 0018:ffffc900040a7320 EFLAGS: 00000206
RAX: 5de15cb931505900 RBX: 0000000000000a06 RCX: 5de15cb931505900
RDX: 0000000000000007 RSI: ffffffff8daa9dc3 RDI: 0000000000000001
RBP: ffffc900040a73b0 R08: ffffffff8fc3d0

---truncated---

Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-89927"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T11:17:01Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: hyper-v: Clamp stimer deadline to avoid livelock\n\nFix 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.\n\nHyper-V\u0027s 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).\n\nWhen 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.\n\n    ktime_add_ns(ktime_now, 100 * (stimer-\u003eexp_time - time_now))\n\nThis 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.\n\nThen, 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-\u003eexp_time, which is a big value close to U64_MAX, so\nthis never happens for a few thousand years.\n\nkvm_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.\n\nSince 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:\n\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 -\u003eqsmask 0x0\n    rcu: rcu_preempt kthread starved for 10500 jiffies! g14269 f0x2 RCU_GP_WAIT_FQS(5) -\u003estate=0x0 -\u003ecpu=0\n    rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.\n        ( ... )\n    Call Trace:\n     \u003cIRQ\u003e\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\n     \u003c/IRQ\u003e\n     \u003cTASK\u003e\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 \u003ce8\u003e 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---",
  "id": "GHSA-5qjh-387m-mgrj",
  "modified": "2026-09-16T15:31:02Z",
  "published": "2026-09-16T12:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89927"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ca49fbd2883cd53d32d85b50feef17fa04d0fbf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3097582b73a8ed1cd6f6790fa78706f4a79b5a49"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61954727ee08f026f5e1c9ee69e1b404a68f2f7a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6a8ba9213cce613455b1502ee0fd178656bf617b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8aa467fe757d8cb2278e98d7fbf44fc05eb0dbf8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8e19ded84336891646b31375720717635f0fdd90"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a4665762388750e08df99baabe5fce2a21d1423e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bdb732ebee545b7e3bee7060efc754a8d99818b9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.