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-FGJ9-8C8V-JFWQ
Vulnerability from github – Published: 2022-04-30 18:18 – Updated: 2024-02-08 21:30Windows 2000 allows local users to prevent the application of new group policy settings by opening Group Policy files with exclusive-read access.
{
"affected": [],
"aliases": [
"CVE-2002-0051"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2002-04-04T05:00:00Z",
"severity": "MODERATE"
},
"details": "Windows 2000 allows local users to prevent the application of new group policy settings by opening Group Policy files with exclusive-read access.",
"id": "GHSA-fgj9-8c8v-jfwq",
"modified": "2024-02-08T21:30:29Z",
"published": "2022-04-30T18:18:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-0051"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2002/ms02-016"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A38"
},
{
"type": "WEB",
"url": "http://online.securityfocus.com/archive/1/244329"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/4438"
}
],
"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-FH88-V2MJ-CP79
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
erofs: handle overlapped pclusters out of crafted images properly
syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os.
After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below:
Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ...
Here, extent 0/1 are physically overlapped although it's entirely impossible for normal filesystem images generated by mkfs.
First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits.
Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness.
Additionally, it justifies that referenced managed folios cannot be
truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy
up struct z_erofs_bvec") for simplicity although it shouldn't be any
difference.
{
"affected": [],
"aliases": [
"CVE-2024-47736"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: handle overlapped pclusters out of crafted images properly\n\nsyzbot reported a task hang issue due to a deadlock case where it is\nwaiting for the folio lock of a cached folio that will be used for\ncache I/Os.\n\nAfter looking into the crafted fuzzed image, I found it\u0027s formed with\nseveral overlapped big pclusters as below:\n\n Ext: logical offset | length : physical offset | length\n 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384\n 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384\n 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384\n...\n\nHere, extent 0/1 are physically overlapped although it\u0027s entirely\n_impossible_ for normal filesystem images generated by mkfs.\n\nFirst, managed folios containing compressed data will be marked as\nup-to-date and then unlocked immediately (unlike in-place folios) when\ncompressed I/Os are complete. If physical blocks are not submitted in\nthe incremental order, there should be separate BIOs to avoid dependency\nissues. However, the current code mis-arranges z_erofs_fill_bio_vec()\nand BIO submission which causes unexpected BIO waits.\n\nSecond, managed folios will be connected to their own pclusters for\nefficient inter-queries. However, this is somewhat hard to implement\neasily if overlapped big pclusters exist. Again, these only appear in\nfuzzed images so let\u0027s simply fall back to temporary short-lived pages\nfor correctness.\n\nAdditionally, it justifies that referenced managed folios cannot be\ntruncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy\nup `struct z_erofs_bvec`\") for simplicity although it shouldn\u0027t be any\ndifference.",
"id": "GHSA-fh88-v2mj-cp79",
"modified": "2026-07-14T15:31:15Z",
"published": "2024-10-21T15:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47736"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1172e65aad4b115392ea4c6e61e56e5b9b69df4"
}
],
"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-FHMX-7JHG-8H34
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:
task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963
with the attempting freezer stuck trying to grab the rwsem:
task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170
Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.
Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.
{
"affected": [],
"aliases": [
"CVE-2024-53052"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rw: fix missing NOWAIT check for O_DIRECT start write\n\nWhen io_uring starts a write, it\u0027ll call kiocb_start_write() to bump the\nsuper block rwsem, preventing any freezes from happening while that\nwrite is in-flight. The freeze side will grab that rwsem for writing,\nexcluding any new writers from happening and waiting for existing writes\nto finish. But io_uring unconditionally uses kiocb_start_write(), which\nwill block if someone is currently attempting to freeze the mount point.\nThis causes a deadlock where freeze is waiting for previous writes to\ncomplete, but the previous writes cannot complete, as the task that is\nsupposed to complete them is blocked waiting on starting a new write.\nThis results in the following stuck trace showing that dependency with\nthe write blocked starting a new write:\n\ntask:fio state:D stack:0 pid:886 tgid:886 ppid:876\nCall trace:\n __switch_to+0x1d8/0x348\n __schedule+0x8e8/0x2248\n schedule+0x110/0x3f0\n percpu_rwsem_wait+0x1e8/0x3f8\n __percpu_down_read+0xe8/0x500\n io_write+0xbb8/0xff8\n io_issue_sqe+0x10c/0x1020\n io_submit_sqes+0x614/0x2110\n __arm64_sys_io_uring_enter+0x524/0x1038\n invoke_syscall+0x74/0x268\n el0_svc_common.constprop.0+0x160/0x238\n do_el0_svc+0x44/0x60\n el0_svc+0x44/0xb0\n el0t_64_sync_handler+0x118/0x128\n el0t_64_sync+0x168/0x170\nINFO: task fsfreeze:7364 blocked for more than 15 seconds.\n Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963\n\nwith the attempting freezer stuck trying to grab the rwsem:\n\ntask:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995\nCall trace:\n __switch_to+0x1d8/0x348\n __schedule+0x8e8/0x2248\n schedule+0x110/0x3f0\n percpu_down_write+0x2b0/0x680\n freeze_super+0x248/0x8a8\n do_vfs_ioctl+0x149c/0x1b18\n __arm64_sys_ioctl+0xd0/0x1a0\n invoke_syscall+0x74/0x268\n el0_svc_common.constprop.0+0x160/0x238\n do_el0_svc+0x44/0x60\n el0_svc+0x44/0xb0\n el0t_64_sync_handler+0x118/0x128\n el0t_64_sync+0x168/0x170\n\nFix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a\nblocking grab of the super block rwsem if it isn\u0027t set. For normal issue\nwhere IOCB_NOWAIT would always be set, this returns -EAGAIN which will\nhave io_uring core issue a blocking attempt of the write. That will in\nturn also get completions run, ensuring forward progress.\n\nSince freezing requires CAP_SYS_ADMIN in the first place, this isn\u0027t\nsomething that can be triggered by a regular user.",
"id": "GHSA-fhmx-7jhg-8h34",
"modified": "2025-11-04T00:32:04Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53052"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/003d2996964c03dfd34860500428f4cdf1f5879e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d60d74e852647255bd8e76f5a22dc42531e4389"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26b8c48f369b7591f5679e0b90612f4862a32929"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/485d9232112b17f389b29497ff41b97b3189546b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e24041ba86d50aaa4c792ae2c88ed01b3d96243"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e8debb8e51354b201db494689198078ec2c1e75"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FP9W-CXGG-VH4H
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-08 06:30In 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-42775"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07: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-fp9w-cxgg-vh4h",
"modified": "2022-12-08T06:30:30Z",
"published": "2022-12-06T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42775"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
}
],
"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-FQ5H-CM7Q-5GG6
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-25 21:31In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix deadlock in ni_read_folio_cmpr
Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr). This is caused by a lock inversion deadlock involving the inode mutex (ni_lock) and page locks.
Scenario: 1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock. 2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in the compressed frame (including page Y). 3. Concurrently, Task B (e.g., via readahead) has locked page Y and calls ntfs_read_folio(). 4. Task B waits for ni_lock (held by A). 5. Task A waits for page Y lock (held by B). -> DEADLOCK.
The fix is to restructure locking: do not take ni_lock in ntfs_read_folio(). Instead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required page locks for the frame have been successfully acquired. This restores the correct lock ordering (Page Lock -> ni_lock) consistent with VFS.
[almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]
{
"affected": [],
"aliases": [
"CVE-2025-71309"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:16:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: fix deadlock in ni_read_folio_cmpr\n\nSyzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr).\nThis is caused by a lock inversion deadlock involving the inode mutex\n(ni_lock) and page locks.\n\nScenario:\n1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock.\n2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in\n the compressed frame (including page Y).\n3. Concurrently, Task B (e.g., via readahead) has locked page Y and\n calls ntfs_read_folio().\n4. Task B waits for ni_lock (held by A).\n5. Task A waits for page Y lock (held by B).\n -\u003e DEADLOCK.\n\nThe fix is to restructure locking: do not take ni_lock in ntfs_read_folio().\nInstead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required\npage locks for the frame have been successfully acquired. This restores the\ncorrect lock ordering (Page Lock -\u003e ni_lock) consistent with VFS.\n\n[almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]",
"id": "GHSA-fq5h-cm7q-5gg6",
"modified": "2026-06-25T21:31:18Z",
"published": "2026-05-27T15:33:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71309"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfe246b318106e1691bd6c9466c739e8559d25c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e37a75bb866c29da954b51d0dd7670406246d9ee"
}
],
"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-FQHG-58RX-5GHM
Vulnerability from github – Published: 2022-05-26 00:01 – Updated: 2024-05-03 00:30MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (i.e., going to the err label) while executing the method create_worker_threads, the held lock thd->ctrl_mutex is not released correctly, which allows local users to trigger a denial of service due to the deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-31623"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-25T21:15:00Z",
"severity": "MODERATE"
},
"details": "MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (i.e., going to the err label) while executing the method create_worker_threads, the held lock thd-\u003ectrl_mutex is not released correctly, which allows local users to trigger a denial of service due to the deadlock.",
"id": "GHSA-fqhg-58rx-5ghm",
"modified": "2024-05-03T00:30:43Z",
"published": "2022-05-26T00:01:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31623"
},
{
"type": "WEB",
"url": "https://github.com/MariaDB/server/pull/1938"
},
{
"type": "WEB",
"url": "https://github.com/MariaDB/server/commit/7c30bc38a588b22b01f11130cfe99e7f36accf94"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26561"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26574"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220707-0006"
}
],
"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-FQPV-6GRR-R8M7
Vulnerability from github – Published: 2022-04-08 00:00 – Updated: 2022-04-16 00:01A Denial of Service vulnerability exists in CORTX-S3 Server as of 11/7/2021 via the mempool_destroy method due to a failture to release locks pool->lock.
{
"affected": [],
"aliases": [
"CVE-2021-43429"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-07T17:15:00Z",
"severity": "HIGH"
},
"details": "A Denial of Service vulnerability exists in CORTX-S3 Server as of 11/7/2021 via the mempool_destroy method due to a failture to release locks pool-\u003elock.",
"id": "GHSA-fqpv-6grr-r8m7",
"modified": "2022-04-16T00:01:30Z",
"published": "2022-04-08T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43429"
},
{
"type": "WEB",
"url": "https://github.com/Seagate/cortx-s3server/issues/1037"
},
{
"type": "WEB",
"url": "https://github.com/Seagate/cortx-s3server/pull/1041"
}
],
"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-FV7F-R8H4-5HH2
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-12-16 18:31In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.
{
"affected": [],
"aliases": [
"CVE-2025-38094"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T08:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: cadence: macb: Fix a possible deadlock in macb_halt_tx.\n\nThere is a situation where after THALT is set high, TGO stays high as\nwell. Because jiffies are never updated, as we are in a context with\ninterrupts disabled, we never exit that loop and have a deadlock.\n\nThat deadlock was noticed on a sama5d4 device that stayed locked for days.\n\nUse retries instead of jiffies so that the timeout really works and we do\nnot have a deadlock anymore.",
"id": "GHSA-fv7f-r8h4-5hh2",
"modified": "2025-12-16T18:31:28Z",
"published": "2025-07-03T09:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38094"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0772a608d799ac0d127c0a36047a2725777aba9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e64d35475aa21d13dab71da51de51923c1a3a48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64675a9c00443b2e8af42af08c38fc1b78b68ba2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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-FWR4-VX34-QHJP
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in set_track_prepare
set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since slaballoc() has preemption disabled, we mask out GFP_DIRECT_RECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c slaballoc+0xccc kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...
{
"affected": [],
"aliases": [
"CVE-2025-39843"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T16:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...",
"id": "GHSA-fwr4-vx34-qhjp",
"modified": "2026-05-12T15:31:09Z",
"published": "2025-09-22T21:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39843"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/243b705a90ed8449f561a271cf251fd2e939f3db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/522ffe298627cfe72539d72167c2e20e72b5e856"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/850470a8413a8a78e772c4f6bd9fe81ec6bd5b0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/994b03b9605d36d814c611385fbf90ca6db20aa8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb3240ffd243bfb8b1e9dc568d484ecf9fd660ab"
},
{
"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-FX99-8M8G-RFWX
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-12-17 09:31In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Lock XArray when getting entries for the VM
Similar to commit cac075706f29 ("drm/panthor: Fix race when converting group handle to group object") we need to use the XArray's internal locking when retrieving a vm pointer from there.
v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.
{
"affected": [],
"aliases": [
"CVE-2024-53080"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panthor: Lock XArray when getting entries for the VM\n\nSimilar to commit cac075706f29 (\"drm/panthor: Fix race when converting\ngroup handle to group object\") we need to use the XArray\u0027s internal\nlocking when retrieving a vm pointer from there.\n\nv2: Removed part of the patch that was trying to protect fetching\nthe heap pointer from XArray, as that operation is protected by\nthe @pool-\u003elock.",
"id": "GHSA-fx99-8m8g-rfwx",
"modified": "2024-12-17T09:31:05Z",
"published": "2024-11-19T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3342f066a8e1020a6f7d1fbd6b23bfdeda473eb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/444fa5b100e5c90550d6bccfe4476efb0391b3ca"
},
{
"type": "WEB",
"url": "https://project-zero.issues.chromium.org/issues/377500597"
}
],
"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.