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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-339C-XPH3-FJ7G
Vulnerability from github – Published: 2022-05-01 07:25 – Updated: 2024-02-15 21:31The nlmclnt_mark_reclaim in clntlock.c in NFS lockd in Linux kernel before 2.6.16 allows remote attackers to cause a denial of service (process crash) and deny access to NFS exports via unspecified vectors that trigger a kernel oops (null dereference) and a deadlock.
{
"affected": [],
"aliases": [
"CVE-2006-5158"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-10-05T04:04:00Z",
"severity": "LOW"
},
"details": "The nlmclnt_mark_reclaim in clntlock.c in NFS lockd in Linux kernel before 2.6.16 allows remote attackers to cause a denial of service (process crash) and deny access to NFS exports via unspecified vectors that trigger a kernel oops (null dereference) and a deadlock.",
"id": "GHSA-339c-xph3-fj7g",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-01T07:25:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-5158"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10128"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=113476665626446\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=linux-kernel\u0026m=113494474208973\u0026w=2"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2007-0488.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/23361"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/23384"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/23752"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/25838"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/26289"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2007-287.htm"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=9b5b1f5bf9dcdb6f23abf65977a675eb4deba3c0"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b5b1f5bf9dcdb6f23abf65977a675eb4deba3c0"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2007:012"
},
{
"type": "WEB",
"url": "http://www.novell.com/linux/security/advisories/2006_57_kernel.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/21581"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-395-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-34XG-89CF-QR7J
Vulnerability from github – Published: 2022-10-15 12:01 – Updated: 2022-10-18 12:00In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.
{
"affected": [],
"aliases": [
"CVE-2022-38690"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-667",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-14T19:15:00Z",
"severity": "MODERATE"
},
"details": "In camera driver, there is a possible memory corruption due to improper locking. This could lead to local denial of service in kernel.",
"id": "GHSA-34xg-89cf-qr7j",
"modified": "2022-10-18T12:00:32Z",
"published": "2022-10-15T12:01:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38690"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1575654905820020738"
}
],
"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-354Q-38F3-JH4J
Vulnerability from github – Published: 2023-04-25 21:30 – Updated: 2024-02-01 03:30A denial of service problem was found, due to a possible recursive locking scenario, resulting in a deadlock in table_clear in drivers/md/dm-ioctl.c in the Linux Kernel Device Mapper-Multipathing sub-component.
{
"affected": [],
"aliases": [
"CVE-2023-2269"
],
"database_specific": {
"cwe_ids": [
"CWE-413",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-25T21:15:10Z",
"severity": "MODERATE"
},
"details": "A denial of service problem was found, due to a possible recursive locking scenario, resulting in a deadlock in table_clear in drivers/md/dm-ioctl.c in the Linux Kernel Device Mapper-Multipathing sub-component.",
"id": "GHSA-354q-38f3-jh4j",
"modified": "2024-02-01T03:30:22Z",
"published": "2023-04-25T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2269"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/63AJUCJTZCII2JMAF7MGZEM66KY7IALT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FBLBKW2WM5YSTS6OGEU5SYHXSJ5EWSTV"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IXHBLWYNSUBS77TYPOJTADPDXKBH2F4U"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/63AJUCJTZCII2JMAF7MGZEM66KY7IALT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FBLBKW2WM5YSTS6OGEU5SYHXSJ5EWSTV"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IXHBLWYNSUBS77TYPOJTADPDXKBH2F4U"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/ZD1xyZxb3rHot8PV%40redhat.com/t"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/ZD1xyZxb3rHot8PV@redhat.com/t"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230929-0004"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5448"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5480"
}
],
"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-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"
}
]
}
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.