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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-3VVP-54WC-F6JR
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-15 18:30In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback
SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using smp_cond_load_acquire() until the target CPU's kick_sync advances. Because the irq_work runs in hardirq context, the waiting CPU cannot reschedule and its own kick_sync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.
Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to force the CPU through do_pick_task_scx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the sched_core_balance() pattern, so the CPU can process IPIs while waiting. The local CPU's kick_sync is advanced on entry to do_pick_task_scx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.
{
"affected": [],
"aliases": [
"CVE-2026-43326"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback\n\nSCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using\nsmp_cond_load_acquire() until the target CPU\u0027s kick_sync advances. Because\nthe irq_work runs in hardirq context, the waiting CPU cannot reschedule and\nits own kick_sync never advances. If multiple CPUs form a wait cycle, all\nCPUs deadlock.\n\nReplace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to\nforce the CPU through do_pick_task_scx(), which queues a balance callback\nto perform the wait. The balance callback drops the rq lock and enables\nIRQs following the sched_core_balance() pattern, so the CPU can process\nIPIs while waiting. The local CPU\u0027s kick_sync is advanced on entry to\ndo_pick_task_scx() and continuously during the wait, ensuring any CPU that\nstarts waiting for us sees the advancement and cannot form cyclic\ndependencies.",
"id": "GHSA-3vvp-54wc-f6jr",
"modified": "2026-05-15T18:30:30Z",
"published": "2026-05-08T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43326"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/415cb193bb9736f0e830286c72a6fa8eb2a9cc5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3a7903f65cf4c7fb0477eb0f8b94f326a47fe54"
}
],
"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-3W6Q-RQW9-H6QX
Vulnerability from github – Published: 2025-11-12 21:31 – Updated: 2025-11-13 18:31An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).
{
"affected": [],
"aliases": [
"CVE-2025-63396"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-12T21:15:52Z",
"severity": "LOW"
},
"details": "An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).",
"id": "GHSA-3w6q-rqw9-h6qx",
"modified": "2025-11-13T18:31:03Z",
"published": "2025-11-12T21:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63396"
},
{
"type": "WEB",
"url": "https://github.com/pytorch/pytorch/issues/156563"
},
{
"type": "WEB",
"url": "https://github.com/Daisy2ang"
},
{
"type": "WEB",
"url": "https://github.com/pytorch/pytorch"
},
{
"type": "WEB",
"url": "http://pytorch.com"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-3WJP-7H53-CFV8
Vulnerability from github – Published: 2024-06-20 12:31 – Updated: 2025-09-17 18:31In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix hang in usb_kill_urb by adding memory barriers
The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received.
The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions:
CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue);
Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is:
write urb->reject, then read urb->use_count;
whereas the overall pattern of accesses on CPU 1 is:
write urb->use_count, then read urb->reject.
This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb().
The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb().
The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect.
This patch adds the necessary memory barriers.
{
"affected": [],
"aliases": [
"CVE-2022-48760"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T12:15:14Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\n\nThe syzbot fuzzer has identified a bug in which processes hang waiting\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\nthe URB; that works just fine. Rather, the problem arises when the\nwakeup notification that the URB has completed is not received.\n\nThe reason is memory-access ordering on SMP systems. In outline form,\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\ndifferent CPUs perform the following actions:\n\nCPU 0\t\t\t\t\tCPU 1\n----------------------------\t\t---------------------------------\nusb_kill_urb():\t\t\t\t__usb_hcd_giveback_urb():\n ...\t\t\t\t\t ...\n atomic_inc(\u0026urb-\u003ereject);\t\t atomic_dec(\u0026urb-\u003euse_count);\n ...\t\t\t\t\t ...\n wait_event(usb_kill_urb_queue,\n\tatomic_read(\u0026urb-\u003euse_count) == 0);\n\t\t\t\t\t if (atomic_read(\u0026urb-\u003ereject))\n\t\t\t\t\t\twake_up(\u0026usb_kill_urb_queue);\n\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb-\u003ereject, then read urb-\u003euse_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb-\u003euse_count, then read urb-\u003ereject.\n\nThis pattern is referred to in memory-model circles as SB (for \"Store\nBuffering\"), and it is well known that without suitable enforcement of\nthe desired order of accesses -- in the form of memory barriers -- it\nis entirely possible for one or both CPUs to execute their reads ahead\nof their writes. The end result will be that sometimes CPU 0 sees the\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\nun-incremented value of urb-\u003ereject. Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\n\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\n\nThe problem is fixed by adding suitable memory barriers. To provide\nproper memory-access ordering in the SB pattern, a full barrier is\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\nthemselves don\u0027t provide any memory ordering, but since they are\npresent, we can use the optimized smp_mb__after_atomic() memory\nbarrier in the various routines to obtain the desired effect.\n\nThis patch adds the necessary memory barriers.",
"id": "GHSA-3wjp-7h53-cfv8",
"modified": "2025-09-17T18:31:14Z",
"published": "2024-06-20T12:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48760"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3WW8-8V8C-WRR2
Vulnerability from github – Published: 2022-07-07 00:00 – Updated: 2022-07-14 00:00In sched driver, there is a possible use after free 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: ALPS06479032; Issue ID: ALPS06479032.
{
"affected": [],
"aliases": [
"CVE-2022-21775"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-06T14:15:00Z",
"severity": "MODERATE"
},
"details": "In sched driver, there is a possible use after free 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: ALPS06479032; Issue ID: ALPS06479032.",
"id": "GHSA-3ww8-8v8c-wrr2",
"modified": "2022-07-14T00:00:19Z",
"published": "2022-07-07T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21775"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/July-2022"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3WWR-WV4X-4GXG
Vulnerability from github – Published: 2024-03-18 12:30 – Updated: 2024-12-12 15:31In the Linux kernel, the following vulnerability has been resolved:
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks.
Fix this by using a stack buffer when calling copy_to_user.
{
"affected": [],
"aliases": [
"CVE-2023-52615"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-18T11:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: core - Fix page fault dead lock on mmap-ed hwrng\n\nThere is a dead-lock in the hwrng device read path. This triggers\nwhen the user reads from /dev/hwrng into memory also mmap-ed from\n/dev/hwrng. The resulting page fault triggers a recursive read\nwhich then dead-locks.\n\nFix this by using a stack buffer when calling copy_to_user.",
"id": "GHSA-3wwr-wv4x-4gxg",
"modified": "2024-12-12T15:31:06Z",
"published": "2024-03-18T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52615"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-3XVM-4G57-GVJ6
Vulnerability from github – Published: 2023-07-23 03:30 – Updated: 2024-04-04 06:19A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat.
{
"affected": [],
"aliases": [
"CVE-2023-2430"
],
"database_specific": {
"cwe_ids": [
"CWE-413",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-23T02:15:11Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat.",
"id": "GHSA-3xvm-4g57-gvj6",
"modified": "2024-04-04T06:19:26Z",
"published": "2023-07-23T03:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2430"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5492"
}
],
"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-42CJ-99W8-CP2P
Vulnerability from github – Published: 2026-08-20 17:26 – Updated: 2026-08-20 17:26Summary
go.opentelemetry.io/otel/bridge/opentracing introduced an unsynchronized extraBaggageItems map on bridgeSpan. One goroutine can write this map through Span.SetBaggageItem while another goroutine reads and iterates it during correlation baggage propagation, which can trigger Go's fatal concurrent map access panic and crash the process. The finding is low severity because exploitation requires a specific OpenTracing bridge configuration and concurrent use of the same span.
Introduced in commit: 8cddf30
Details
bridge/opentracing/bridge.go:80-85 adds extraBaggageItems map[string]string to bridgeSpan without a mutex or other synchronization primitive. bridge/opentracing/bridge.go:219-234 shows SetBaggageItem calling updateOtelContext, which lazily creates the map and writes s.extraBaggageItems[restrictedKey] = value without locking. bridge/opentracing/bridge.go:359-377 shows correlationGetHook reading bSpan.extraBaggageItems, checking len(items), and iterating for k, v := range items without locking. The finding evidence also identifies api/correlation/context.go:160-165 as the path where correlation.MapFromContext invokes the get hook, allowing a read path to run concurrently with baggage writes.
Because Go maps are not safe for concurrent read/write access, concurrent SetBaggageItem and correlation.MapFromContext calls on the same hooked bridgeSpan can terminate the process with a runtime error such as fatal error: concurrent map read and map write or fatal error: concurrent map iteration and map write.
PoC
The validation artifact contains a PoC at validation-artifact.tar:validation_poc_concurrent_map.go and supporting notes at validation-artifact.tar:validation_poc_README.txt.
Use a checkout of pellared/opentelemetry-go at commit 8cddf30 with Go module downloads enabled. The local validation environment could not complete the run because GOPROXY=off blocked dependency resolution; that blocked output is saved in validation-artifact.tar:validation_poc_run.log.
Commands:
cd /path/to/opentelemetry-go
git checkout 8cddf30
tar -xOf /path/to/finding-directory/validation-artifact.tar validation_poc_concurrent_map.go > ./validation_poc_concurrent_map.go
GOPROXY=https://proxy.golang.org,direct go run ./validation_poc_concurrent_map.go
The PoC starts a BridgeTracer, creates a span, installs correlation hooks with tracer.NewHookedContext(ctx), initializes baggage once, then runs one goroutine repeatedly calling span.SetBaggageItem(...) while another repeatedly calls otelcorrelation.MapFromContext(ctx). A vulnerable build is expected to terminate with a Go runtime concurrent map access error, for example:
fatal error: concurrent map read and map write
or:
fatal error: concurrent map iteration and map write
Impact
This is a race condition / improper synchronization vulnerability in a shared Go map. Applications using the OpenTelemetry OpenTracing bridge with correlation hooks can crash if the same bridgeSpan is accessed concurrently, with one execution path setting baggage and another propagating correlation baggage. The practical impact is denial of service for the affected application process; exposure depends on whether application request handling or internal concurrency can trigger those operations on the same span.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/bridge/opentracing"
},
"ranges": [
{
"events": [
{
"introduced": "0.11.0"
},
{
"fixed": "1.45.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45404"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T17:26:14Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`go.opentelemetry.io/otel/bridge/opentracing` introduced an unsynchronized `extraBaggageItems` map on `bridgeSpan`. One goroutine can write this map through `Span.SetBaggageItem` while another goroutine reads and iterates it during correlation baggage propagation, which can trigger Go\u0027s fatal concurrent map access panic and crash the process. The finding is low severity because exploitation requires a specific OpenTracing bridge configuration and concurrent use of the same span.\n\nIntroduced in commit: 8cddf30\n\n### Details\n\n`bridge/opentracing/bridge.go:80-85` adds `extraBaggageItems map[string]string` to `bridgeSpan` without a mutex or other synchronization primitive. `bridge/opentracing/bridge.go:219-234` shows `SetBaggageItem` calling `updateOtelContext`, which lazily creates the map and writes `s.extraBaggageItems[restrictedKey] = value` without locking. `bridge/opentracing/bridge.go:359-377` shows `correlationGetHook` reading `bSpan.extraBaggageItems`, checking `len(items)`, and iterating `for k, v := range items` without locking. The finding evidence also identifies `api/correlation/context.go:160-165` as the path where `correlation.MapFromContext` invokes the get hook, allowing a read path to run concurrently with baggage writes.\n\nBecause Go maps are not safe for concurrent read/write access, concurrent `SetBaggageItem` and `correlation.MapFromContext` calls on the same hooked `bridgeSpan` can terminate the process with a runtime error such as `fatal error: concurrent map read and map write` or `fatal error: concurrent map iteration and map write`.\n\n### PoC\n\n[validation-artifact.zip](https://github.com/user-attachments/files/27494614/validation-artifact.zip)\n\n\nThe validation artifact contains a PoC at `validation-artifact.tar:validation_poc_concurrent_map.go` and supporting notes at `validation-artifact.tar:validation_poc_README.txt`.\n\nUse a checkout of `pellared/opentelemetry-go` at commit `8cddf30` with Go module downloads enabled. The local validation environment could not complete the run because `GOPROXY=off` blocked dependency resolution; that blocked output is saved in `validation-artifact.tar:validation_poc_run.log`.\n\nCommands:\n\n```sh\ncd /path/to/opentelemetry-go\ngit checkout 8cddf30\ntar -xOf /path/to/finding-directory/validation-artifact.tar validation_poc_concurrent_map.go \u003e ./validation_poc_concurrent_map.go\nGOPROXY=https://proxy.golang.org,direct go run ./validation_poc_concurrent_map.go\n```\n\nThe PoC starts a `BridgeTracer`, creates a span, installs correlation hooks with `tracer.NewHookedContext(ctx)`, initializes baggage once, then runs one goroutine repeatedly calling `span.SetBaggageItem(...)` while another repeatedly calls `otelcorrelation.MapFromContext(ctx)`. A vulnerable build is expected to terminate with a Go runtime concurrent map access error, for example:\n\n```text\nfatal error: concurrent map read and map write\n```\n\nor:\n\n```text\nfatal error: concurrent map iteration and map write\n```\n\n\n### Impact\n\nThis is a race condition / improper synchronization vulnerability in a shared Go map. Applications using the OpenTelemetry OpenTracing bridge with correlation hooks can crash if the same `bridgeSpan` is accessed concurrently, with one execution path setting baggage and another propagating correlation baggage. The practical impact is denial of service for the affected application process; exposure depends on whether application request handling or internal concurrency can trigger those operations on the same span.",
"id": "GHSA-42cj-99w8-cp2p",
"modified": "2026-08-20T17:26:14Z",
"published": "2026-08-20T17:26:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-42cj-99w8-cp2p"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/pull/8693"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/commit/93a693edeed0e07ce5ebd1dfe67af42d1e2055d8"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.45.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenTelemetry-Go: Unsynchronized baggage map can panic under concurrent access"
}
GHSA-435P-F446-GXF4
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.
{
"affected": [],
"aliases": [
"CVE-2024-44995"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T20:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n pf reset start\n \u2502\n \u25bc\n ......\nsetup tc \u2502\n \u2502 \u25bc\n \u25bc DOWN: napi_disable()\nnapi_disable()(skip) \u2502\n \u2502 \u2502\n \u25bc \u25bc\n ...... ......\n \u2502 \u2502\n \u25bc \u2502\nnapi_enable() \u2502\n \u25bc\n UINIT: netif_napi_del()\n \u2502\n \u25bc\n ......\n \u2502\n \u25bc\n INIT: netif_napi_add()\n \u2502\n \u25bc\n ...... global reset start\n \u2502 \u2502\n \u25bc \u25bc\n UP: napi_enable()(skip) ......\n \u2502 \u2502\n \u25bc \u25bc\n ...... napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.",
"id": "GHSA-435p-f446-gxf4",
"modified": "2025-11-04T00:31:23Z",
"published": "2024-09-04T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ced30a109"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"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-437H-4CV6-6Q92
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 21:30In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: Do a runtime PM get on controllers during probe
mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack:
CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()
CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()
Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression.
Verified on MT8183 and MT8192 Chromebooks.
{
"affected": [],
"aliases": [
"CVE-2024-27002"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mediatek: Do a runtime PM get on controllers during probe\n\nmt8183-mfgcfg has a mutual dependency with genpd during the probing\nstage, which leads to a deadlock in the following call stack:\n\nCPU0: genpd_lock --\u003e clk_prepare_lock\ngenpd_power_off_work_fn()\n genpd_lock()\n generic_pm_domain::power_off()\n clk_unprepare()\n clk_prepare_lock()\n\nCPU1: clk_prepare_lock --\u003e genpd_lock\nclk_register()\n __clk_core_init()\n clk_prepare_lock()\n clk_pm_runtime_get()\n genpd_lock()\n\nDo a runtime PM get at the probe function to make sure clk_register()\nwon\u0027t acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,\ndo this on all mediatek clock controller probings because we don\u0027t\nbelieve this would cause any regression.\n\nVerified on MT8183 and MT8192 Chromebooks.",
"id": "GHSA-437h-4cv6-6q92",
"modified": "2024-12-23T21:30:50Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27002"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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-443G-XXFV-37VX
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 18:31In the Linux kernel, the following vulnerability has been resolved:
mm/swapfile: add cond_resched() in get_swap_pages()
The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently.
The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup.
{
"affected": [],
"aliases": [
"CVE-2023-52932"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swapfile: add cond_resched() in get_swap_pages()\n\nThe softlockup still occurs in get_swap_pages() under memory pressure. 64\nCPU cores, 64GB memory, and 28 zram devices, the disksize of each zram\ndevice is 50MB with same priority as si. Use the stress-ng tool to\nincrease memory pressure, causing the system to oom frequently.\n\nThe plist_for_each_entry_safe() loops in get_swap_pages() could reach tens\nof thousands of times to find available space (extreme case:\ncond_resched() is not called in scan_swap_map_slots()). Let\u0027s add\ncond_resched() into get_swap_pages() when failed to find available space\nto avoid softlockup.",
"id": "GHSA-443g-xxfv-37vx",
"modified": "2025-04-15T18:31:42Z",
"published": "2025-03-27T18:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52932"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29f0349c5c76b627fe06b87d4b13fa03a6ce8e64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/387217b97e99699c34e6d95ce2b91b327fcd853e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49178d4d61e78aed8c837dfeea8a450700f196e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d433106ef2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7717fc1a12f88701573f9ed897cc4f6699c661e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d49c85a1913385eed46dd16a25ad0928253767f0"
}
],
"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.