CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
729 vulnerabilities reference this CWE, most recent first.
GHSA-35P2-9FG3-F2P2
Vulnerability from github – Published: 2023-07-24 18:30 – Updated: 2024-09-13 21:31A flaw was found in libvirt. The virStoragePoolObjListSearch function does not return a locked pool as expected, resulting in a race condition and denial of service when attempting to lock the same object from another thread. This issue could allow clients connecting to the read-only socket to crash the libvirt daemon.
{
"affected": [],
"aliases": [
"CVE-2023-3750"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-24T16:15:13Z",
"severity": "MODERATE"
},
"details": "A flaw was found in libvirt. The virStoragePoolObjListSearch function does not return a locked pool as expected, resulting in a race condition and denial of service when attempting to lock the same object from another thread. This issue could allow clients connecting to the read-only socket to crash the libvirt daemon.",
"id": "GHSA-35p2-9fg3-f2p2",
"modified": "2024-09-13T21:31:19Z",
"published": "2023-07-24T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3750"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:6409"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-3750"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2222210"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EVK6JKP36CHE7YAFDJNPNLTW4OWJJ7TQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-35QC-5X66-F277
Vulnerability from github – Published: 2024-09-11 18:31 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Take state lock during tx timeout reporter
mlx5e_safe_reopen_channels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the Fixes tag.
{
"affected": [],
"aliases": [
"CVE-2024-45019"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-11T16:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Take state lock during tx timeout reporter\n\nmlx5e_safe_reopen_channels() requires the state lock taken. The\nreferenced changed in the Fixes tag removed the lock to fix another\nissue. This patch adds it back but at a later point (when calling\nmlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the\nFixes tag.",
"id": "GHSA-35qc-5x66-f277",
"modified": "2025-11-04T00:31:23Z",
"published": "2024-09-11T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45019"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03d3734bd692affe4d0e9c9d638f491aaf37411b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e57e66ecbdd2fddc9fbf3e984b1c523b70e9809"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3b9a87adee97854bcd71057901d46943076267e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6b5afd30b99b43682a7764e1a74a42fe4d5f4b3"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3629-447P-WP7V
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix pci_slot_trylock() error handling
Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails.
Before a4e772898f8b, the code did:
if (!pci_dev_trylock(dev)) / <- lock bridge device / goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); / <- unlock bridge device / goto unlock; } }
After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug.
This yields one of two errors:
- A warning that the lock is being unlocked when no one holds it.
- An incorrect unlock of a lock that belongs to another thread.
Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path.
[Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]
{
"affected": [],
"aliases": [
"CVE-2026-43211"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix pci_slot_trylock() error handling\n\nCommit a4e772898f8b (\"PCI: Add missing bridge lock to pci_bus_lock()\")\ndelegates the bridge device\u0027s pci_dev_trylock() to pci_bus_trylock() in\npci_slot_trylock(), but it forgets to remove the corresponding\npci_dev_unlock() when pci_bus_trylock() fails.\n\nBefore a4e772898f8b, the code did:\n\n if (!pci_dev_trylock(dev)) /* \u003c- lock bridge device */\n goto unlock;\n if (dev-\u003esubordinate) {\n if (!pci_bus_trylock(dev-\u003esubordinate)) {\n pci_dev_unlock(dev); /* \u003c- unlock bridge device */\n goto unlock;\n }\n }\n\nAfter a4e772898f8b the bridge-device lock is no longer taken, but the\npci_dev_unlock(dev) on the failure path was left in place, leading to the\nbug.\n\nThis yields one of two errors:\n\n 1. A warning that the lock is being unlocked when no one holds it.\n 2. An incorrect unlock of a lock that belongs to another thread.\n\nFix it by removing the now-redundant pci_dev_unlock(dev) on the failure\npath.\n\n[Same patch later posted by Keith at\nhttps://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]",
"id": "GHSA-3629-447p-wp7v",
"modified": "2026-05-08T15:31:17Z",
"published": "2026-05-06T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43211"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0425aaf20b407d2f2cf3bf469808e4a35f9abb8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b08ea9690b212b7bf7f12414039259cf34b1aa0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9368d1ee62829b08aa31836b3ca003803caf0b72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/943ed56606a7ab2fe5a99cad572dd17d484310c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a19b61fdb958ffadbba85b43c991eb9fc70c1c1c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd435f4b738130d732ef64e0e57e45185f77165d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ebb27b7399ab8b9eb1f792b329aa5f6250c590d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fbe06a3058114bf95a17a4941b205f4b321c6f0a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-36QQ-553F-W4WW
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-26 18:31In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid double-rtnl_lock ELP metric worker
batadv_v_elp_get_throughput() might be called when the RTNL lock is already held. This could be problematic when the work queue item is cancelled via cancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case, an rtnl_lock() would cause a deadlock.
To avoid this, rtnl_trylock() was used in this function to skip the retrieval of the ethtool information in case the RTNL lock was already held.
But for cfg80211 interfaces, batadv_get_real_netdev() was called - which also uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must also be used instead and the lockless version __batadv_get_real_netdev() has to be called.
{
"affected": [],
"aliases": [
"CVE-2026-43382"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T15:16:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Avoid double-rtnl_lock ELP metric worker\n\nbatadv_v_elp_get_throughput() might be called when the RTNL lock is already\nheld. This could be problematic when the work queue item is cancelled via\ncancel_delayed_work_sync() in batadv_v_elp_iface_disable(). In this case,\nan rtnl_lock() would cause a deadlock.\n\nTo avoid this, rtnl_trylock() was used in this function to skip the\nretrieval of the ethtool information in case the RTNL lock was already\nheld.\n\nBut for cfg80211 interfaces, batadv_get_real_netdev() was called - which\nalso uses rtnl_lock(). The approach for __ethtool_get_link_ksettings() must\nalso be used instead and the lockless version __batadv_get_real_netdev()\nhas to be called.",
"id": "GHSA-36qq-553f-w4ww",
"modified": "2026-05-26T18:31:37Z",
"published": "2026-05-08T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43382"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/192f40ad8a7dac58dae9199a065dbf7e6e67b75b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ab9f2531d37775cd79228c1f5d80e6bd08d11d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c3ae249431b4fcb315d7dfb4c3a13f9e443fd9b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77808fe7d03ad0062840b95f431869a8b3d88b24"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7e5d8ddfdf1d6e9e0808d1adf7736a107372d77"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfc83a3c71517b59c1047db57da31e26a9dc2f33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3ca45673dab0514a887231de6f3243a699d5bfd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa7b4edfbabdf9235b0ab4bea297fc12b3bec9ca"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-379F-CJ7P-7FJJ
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2024-10-22 18:32In the Linux kernel, the following vulnerability has been resolved:
fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set
This may be a typo. The comment has said shared locks are
not allowed when this bit is set. If using shared lock, the
wait in fuse_file_cached_io_open may be forever.
{
"affected": [],
"aliases": [
"CVE-2024-47746"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set\n\nThis may be a typo. The comment has said shared locks are\nnot allowed when this bit is set. If using shared lock, the\nwait in `fuse_file_cached_io_open` may be forever.",
"id": "GHSA-379f-cj7p-7fjj",
"modified": "2024-10-22T18:32:10Z",
"published": "2024-10-21T15:32:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47746"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f3d8ff457982f4055fe8f7bf19d3821ba22c376"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e181761ffec67307157a7e8a78d58ee4130cf00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa4890bd8237e5a1e7428acd7328729db2703b23"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-37C3-QM4G-JF9G
Vulnerability from github – Published: 2024-05-19 09:34 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep:
CPU0 CPU1
---- ----
lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); lock(&host->lock);
Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is not hardirq-unsafe, that is interrupts are disabled, and bail out with an error.
Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.
{
"affected": [],
"aliases": [
"CVE-2024-35895"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T09:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Prevent lock inversion deadlock in map delete elem\n\nsyzkaller started using corpuses where a BPF tracing program deletes\nelements from a sockmap/sockhash map. Because BPF tracing programs can be\ninvoked from any interrupt context, locks taken during a map_delete_elem\noperation must be hardirq-safe. Otherwise a deadlock due to lock inversion\nis possible, as reported by lockdep:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026htab-\u003ebuckets[i].lock);\n local_irq_disable();\n lock(\u0026host-\u003elock);\n lock(\u0026htab-\u003ebuckets[i].lock);\n \u003cInterrupt\u003e\n lock(\u0026host-\u003elock);\n\nLocks in sockmap are hardirq-unsafe by design. We expects elements to be\ndeleted from sockmap/sockhash only in task (normal) context with interrupts\nenabled, or in softirq context.\n\nDetect when map_delete_elem operation is invoked from a context which is\n_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an\nerror.\n\nNote that map updates are not affected by this issue. BPF verifier does not\nallow updating sockmap/sockhash from a BPF tracing program today.",
"id": "GHSA-37c3-qm4g-jf9g",
"modified": "2026-05-12T12:31:48Z",
"published": "2024-05-19T09:34:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35895"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/913c30f827e17d8cda1da6eeb990f350d36cb69b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-37H8-63P8-QHHG
Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: use the backlog for mirred ingress
The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep.
The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls.
In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.
{
"affected": [],
"aliases": [
"CVE-2024-26740"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T17:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_mirred: use the backlog for mirred ingress\n\nThe test Davide added in commit ca22da2fbd69 (\"act_mirred: use the backlog\nfor nested calls to mirred ingress\") hangs our testing VMs every 10 or so\nruns, with the familiar tcp_v4_rcv -\u003e tcp_v4_rcv deadlock reported by\nlockdep.\n\nThe problem as previously described by Davide (see Link) is that\nif we reverse flow of traffic with the redirect (egress -\u003e ingress)\nwe may reach the same socket which generated the packet. And we may\nstill be holding its socket lock. The common solution to such deadlocks\nis to put the packet in the Rx backlog, rather than run the Rx path\ninline. Do that for all egress -\u003e ingress reversals, not just once\nwe started to nest mirred calls.\n\nIn the past there was a concern that the backlog indirection will\nlead to loss of error reporting / less accurate stats. But the current\nworkaround does not seem to address the issue.",
"id": "GHSA-37h8-63p8-qhhg",
"modified": "2025-03-17T18:31:40Z",
"published": "2024-04-03T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26740"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-37VF-XCVF-JRJR
Vulnerability from github – Published: 2026-01-14 15:32 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in update_target_expiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-71104"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-14T15:15:59Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer\n\nWhen advancing the target expiration for the guest\u0027s APIC timer in periodic\nmode, set the expiration to \"now\" if the target expiration is in the past\n(similar to what is done in update_target_expiration()). Blindly adding\nthe period to the previous target expiration can result in KVM generating\na practically unbounded number of hrtimer IRQs due to programming an\nexpired timer over and over. In extreme scenarios, e.g. if userspace\npauses/suspends a VM for an extended duration, this can even cause hard\nlockups in the host.\n\nCurrently, the bug only affects Intel CPUs when using the hypervisor timer\n(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,\na.k.a. hrtimer, which KVM keeps running even on exits to userspace, the\nHV timer only runs while the guest is active. As a result, if the vCPU\ndoes not run for an extended duration, there will be a huge gap between\nthe target expiration and the current time the vCPU resumes running.\nBecause the target expiration is incremented by only one period on each\ntimer expiration, this leads to a series of timer expirations occurring\nrapidly after the vCPU/VM resumes.\n\nMore critically, when the vCPU first triggers a periodic HV timer\nexpiration after resuming, advancing the expiration by only one period\nwill result in a target expiration in the past. As a result, the delta\nmay be calculated as a negative value. When the delta is converted into\nan absolute value (tscdeadline is an unsigned u64), the resulting value\ncan overflow what the HV timer is capable of programming. I.e. the large\nvalue will exceed the VMX Preemption Timer\u0027s maximum bit width of\ncpu_preemption_timer_multi + 32, and thus cause KVM to switch from the\nHV timer to the software timer (hrtimers).\n\nAfter switching to the software timer, periodic timer expiration callbacks\nmay be executed consecutively within a single clock interrupt handler,\nbecause hrtimers honors KVM\u0027s request for an expiration in the past and\nimmediately re-invokes KVM\u0027s callback after reprogramming. And because\nthe interrupt handler runs with IRQs disabled, restarting KVM\u0027s hrtimer\nover and over until the target expiration is advanced to \"now\" can result\nin a hard lockup.\n\nE.g. the following hard lockup was triggered in the host when running a\nWindows VM (only relevant because it used the APIC timer in periodic mode)\nafter resuming the VM from a long suspend (in the host).\n\n NMI watchdog: Watchdog detected hard LOCKUP on cpu 45\n ...\n RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]\n ...\n RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046\n RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc\n RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500\n RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0\n R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0\n R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8\n FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0\n PKRU: 55555554\n Call Trace:\n \u003cIRQ\u003e\n apic_timer_fn+0x31/0x50 [kvm]\n __hrtimer_run_queues+0x100/0x280\n hrtimer_interrupt+0x100/0x210\n ? ttwu_do_wakeup+0x19/0x160\n smp_apic_timer_interrupt+0x6a/0x130\n apic_timer_interrupt+0xf/0x20\n \u003c/IRQ\u003e\n\nMoreover, if the suspend duration of the virtual machine is not long enough\nto trigger a hard lockup in this scenario, since commit 98c25ead5eda\n(\"KVM: VMX: Move preemption timer \u003c=\u003e hrtimer dance to common x86\"), KVM\nwill continue using the software timer until the guest reprograms the APIC\ntimer in some way. Since the periodic timer does not require frequent APIC\ntimer register programming, the guest may continue to use the software\ntimer in \n---truncated---",
"id": "GHSA-37vf-xcvf-jrjr",
"modified": "2026-07-14T15:31:32Z",
"published": "2026-01-14T15:32:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71104"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18ab3fc8e880791aa9f7c000261320fc812b5465"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/786ed625c125c5cd180d6aaa37e653e3e4ffb8d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b54ccef865e0aa62e4871d4ada2ba4b9dcb8bed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/807dbe8f3862fa7c164155857550ce94b36a11b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2da0df7bbc4fb4fd7d0a1da704f81a09c72fe73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e23f46f1a971c73dad2fd63e1408696114ddebe2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e746e51947053a02af2ea964593dc4887108d379"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-38P5-W7J2-VWRV
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.
{
"affected": [],
"aliases": [
"CVE-2025-39782"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: prevent softlockup in jbd2_log_do_checkpoint()\n\nBoth jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()\nperiodically release j_list_lock after processing a batch of buffers to\navoid long hold times on the j_list_lock. However, since both functions\ncontend for j_list_lock, the combined time spent waiting and processing\ncan be significant.\n\njbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when\nneed_resched() is true to avoid softlockups during prolonged operations.\nBut jbd2_log_do_checkpoint() only exits its loop when need_resched() is\ntrue, relying on potentially sleeping functions like __flush_batch() or\nwait_on_buffer() to trigger rescheduling. If those functions do not sleep,\nthe kernel may hit a softlockup.\n\nwatchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]\nCPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10\nHardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017\nWorkqueue: writeback wb_workfn (flush-7:2)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : native_queued_spin_lock_slowpath+0x358/0x418\nlr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\nCall trace:\n native_queued_spin_lock_slowpath+0x358/0x418\n jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]\n __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]\n add_transaction_credits+0x3bc/0x418 [jbd2]\n start_this_handle+0xf8/0x560 [jbd2]\n jbd2__journal_start+0x118/0x228 [jbd2]\n __ext4_journal_start_sb+0x110/0x188 [ext4]\n ext4_do_writepages+0x3dc/0x740 [ext4]\n ext4_writepages+0xa4/0x190 [ext4]\n do_writepages+0x94/0x228\n __writeback_single_inode+0x48/0x318\n writeback_sb_inodes+0x204/0x590\n __writeback_inodes_wb+0x54/0xf8\n wb_writeback+0x2cc/0x3d8\n wb_do_writeback+0x2e0/0x2f8\n wb_workfn+0x80/0x2a8\n process_one_work+0x178/0x3e8\n worker_thread+0x234/0x3b8\n kthread+0xf0/0x108\n ret_from_fork+0x10/0x20\n\nSo explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid\nsoftlockup.",
"id": "GHSA-38p5-w7j2-vwrv",
"modified": "2026-07-14T15:31:27Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39782"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26cb9aad94cb1811d8fae115594cc71fa3d91ab0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3faac5e1d14c63260fd1bf789d96bde3ab3d9e54"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41f40038de62e8306897cf6840791b268996432a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/429d50cbaff45090d52a1ea850d5de8c14881ee7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84ff98c1ea19acd3f9389e4bb6061364e943f85e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d98cf4632258720f18265a058e62fde120c0151"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f683d611518d30334813eecf9a8c687453e2800e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7ee8fd689e6d534f9fd2494b9266f7998082e65"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3C2R-W857-W87R
Vulnerability from github – Published: 2022-01-05 00:00 – Updated: 2022-01-12 00:01In vow driver, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS05862986; Issue ID: ALPS05862986.
{
"affected": [],
"aliases": [
"CVE-2022-20016"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-04T16:15:00Z",
"severity": "MODERATE"
},
"details": "In vow driver, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS05862986; Issue ID: ALPS05862986.",
"id": "GHSA-3c2r-w857-w87r",
"modified": "2022-01-12T00:01:35Z",
"published": "2022-01-05T00:00:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20016"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/January-2022"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.