[PW_SID:1123513] RISC-V: KVM: Serialize virtual interrupt pending state updates#2244
[PW_SID:1123513] RISC-V: KVM: Serialize virtual interrupt pending state updates#2244linux-riscv-bot wants to merge 3 commits into
Conversation
A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(),
where image->segment[i].buf might be NULL and copied unchecked.
The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by
kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without
a check in machine_kexec_prepare():
kexec_file_load
-> kimage_file_alloc_init()
-> kimage_file_prepare_segments()
-> ima_add_kexec_buffer()
-> kexec_add_buffer()
-> machine_kexec_prepare()
-> memcpy()
Address this by adding a check before the data copy attempt.
Fixes: b7fb4d7 ("RISC-V: use memcpy for kexec_file mode")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/kexec/CAO7dBbVftLUhd2qrh7hmijTB3PEPfZAhykCGqEfrPoOcSrrj-w@mail.gmail.com/
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
Link: https://patch.msgid.link/20260705232706.30265-2-ltao@redhat.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
RISC-V KVM tracks guest interrupt state with two bitmaps:
- irqs_pending: interrupts that should be visible to the guest
- irqs_pending_mask: interrupts whose pending state changed
The current code updates those bitmaps with independent atomic bitops
and assumes a multiple-producer, single-consumer protocol. That model
does not actually hold.
kvm_riscv_vcpu_sync_interrupts() is not a pure consumer. When the guest
changes guest-visible HVIP state, sync_interrupts() writes both
irqs_pending and irqs_pending_mask to reflect the new guest state back
into KVM state. As a result, irqs_pending and irqs_pending_mask form a
single logical state transition, but they are not updated atomically as
a pair.
This allows a race where a newly injected interrupt is lost. For
example:
CPU0 CPU1
---- ----
kvm_riscv_vcpu_set_interrupt(VS_SOFT)
set_bit(VS_SOFT, irqs_pending)
kvm_riscv_vcpu_sync_interrupts()
sees guest-cleared HVIP.VSSIP
sets irqs_pending_mask
clears irqs_pending
set_bit(VS_SOFT, irqs_pending_mask)
kvm_vcpu_kick()
After that interleaving, a later flush can update HVIP without VSSIP
even though a new virtual interrupt was injected. In practice, the
guest can remain blocked in WFI with work pending.
The same pending/mask protocol is shared by VS soft interrupts, PMU
overflow delivery, and AIA high interrupt synchronization, so the race
is not limited to one interrupt source.
Fix this by serializing all updates to irqs_pending and
irqs_pending_mask with a per-vCPU raw spinlock. This keeps the pending
bit and the dirty mask as one state transition across:
- set/unset interrupt
- guest HVIP sync
- interrupt flush to guest CSR state
- vCPU reset
- AIA CSR writes that clear dirty state
This intentionally replaces the existing lockless protocol instead of
trying to repair it with additional barriers. The problem is not memory
ordering on a single field; it is that two separate bitmaps encode one
shared state machine while both producers and sync paths can modify
them. A per-vCPU raw spinlock keeps the fix small, local, and suitable
for backporting.
Observed symptom:
- guest occasionally remains blocked in WFI after host-side virtual
interrupt injection
Testing:
- reproduced on a RISC-V KVM setup running lkvm stress workloads
- observed guest stalls with WFI diagnostics while host-side kick and
interrupt injection had already happened
- stress run no longer reproduced the lost-VSSIP hang after applying
this change
Fixes: cce69af ("RISC-V: KVM: Implement VCPU interrupts and requests handling")
Cc: stable@vger.kernel.org
Signed-off-by: Xie Bo <xb@ultrarisc.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
|
Patch 1: "[v2,1/1] RISC-V: KVM: Serialize virtual interrupt pending state updates" |
2b6a725 to
da477a6
Compare
3 participants
PR for series 1123513 applied to workflow__riscv__fixes
Name: RISC-V: KVM: Serialize virtual interrupt pending state updates
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=1123513
Version: 2