aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/fpga/fpga-region.c
diff options
context:
space:
mode:
authorSean Christopherson <[email protected]>2024-01-10 00:42:39 +0000
committerSean Christopherson <[email protected]>2024-01-29 16:16:58 +0000
commitd489ec95658392a000dd26fba511eec1900245b0 (patch)
treef6795331c52740b72c6a60156a43fdfe289624b3 /drivers/fpga/fpga-region.c
parentLinux 6.8-rc2 (diff)
downloadkernel-d489ec95658392a000dd26fba511eec1900245b0.tar.gz
kernel-d489ec95658392a000dd26fba511eec1900245b0.zip
KVM: Harden against unpaired kvm_mmu_notifier_invalidate_range_end() calls
When handling the end of an mmu_notifier invalidation, WARN if mn_active_invalidate_count is already 0 do not decrement it further, i.e. avoid causing mn_active_invalidate_count to underflow/wrap. In the worst case scenario, effectively corrupting mn_active_invalidate_count could cause kvm_swap_active_memslots() to hang indefinitely. end() calls are *supposed* to be paired with start(), i.e. underflow can only happen if there is a bug elsewhere in the kernel, but due to lack of lockdep assertions in the mmu_notifier helpers, it's all too easy for a bug to go unnoticed for some time, e.g. see the recently introduced PAGEMAP_SCAN ioctl(). Ideally, mmu_notifiers would incorporate lockdep assertions, but users of mmu_notifiers aren't required to hold any one specific lock, i.e. adding the necessary annotations to make lockdep aware of all locks that are mutally exclusive with mm_take_all_locks() isn't trivial. Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]>
Diffstat (limited to 'drivers/fpga/fpga-region.c')
0 files changed, 0 insertions, 0 deletions