CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
3636 vulnerabilities reference this CWE, most recent first.
GHSA-H3V4-524H-5JPX
Vulnerability from github – Published: 2026-02-14 15:32 – Updated: 2026-03-18 15:30In the Linux kernel, the following vulnerability has been resolved:
mISDN: annotate data-race around dev->work
dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.
BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read
write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000000 -> 0x00000001
{
"affected": [],
"aliases": [
"CVE-2026-23121"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T15:16:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: annotate data-race around dev-\u003ework\n\ndev-\u003ework can re read locklessly in mISDN_read()\nand mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.\n\nBUG: KCSAN: data-race in mISDN_ioctl / mISDN_read\n\nwrite to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1:\n misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]\n mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583\n __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583\n x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0:\n mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112\n do_loop_readv_writev fs/read_write.c:847 [inline]\n vfs_readv+0x3fb/0x690 fs/read_write.c:1020\n do_readv+0xe7/0x210 fs/read_write.c:1080\n __do_sys_readv fs/read_write.c:1165 [inline]\n __se_sys_readv fs/read_write.c:1162 [inline]\n __x64_sys_readv+0x45/0x50 fs/read_write.c:1162\n x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nvalue changed: 0x00000000 -\u003e 0x00000001",
"id": "GHSA-h3v4-524h-5jpx",
"modified": "2026-03-18T15:30:40Z",
"published": "2026-02-14T15:32:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23121"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13f3b3b87068898056db4c79ee67052fbde11d43"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ac345a93af31358e18e9606eb7b354691bf6757"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8175dbf174d487afab81e936a862a8d9b8a1ccb6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa6e33cd74ca4965f2bbcb025e0b672fb0168a69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/accc3f8266d2a49881dbcf78c459477f4efa0ff3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5d99cb9e0839093cd53aa3b28176fce2f820ca0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc8ba17fd3337bd8b1913c30b95df0fee00d8fb7"
}
],
"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-H3WW-Q6XX-W7X3
Vulnerability from github – Published: 2026-05-14 20:28 – Updated: 2026-07-15 21:50Summary
The LDAP and OAuth authentication flows use a TOCTOU (Time-of-Check-Time-of-Use) pattern for first-user admin role assignment. The regular signup handler (signup_handler in auths.py, line 663) was explicitly patched to prevent this race with the comment "Insert with default role first to avoid TOCTOU race", but the LDAP and OAuth code paths were never updated with the same fix.
Vulnerable Code
LDAP (auths.py, lines 479-490)
# Line 482 - CHECK: is the user table empty?
role = 'admin' if not Users.has_users(db=db) else request.app.state.config.DEFAULT_USER_ROLE
# Lines 484-490 - USE: create user with the role determined above
user = Auths.insert_new_auth(
email=email,
password=str(uuid.uuid4()),
name=cn,
role=role, # <-- role was determined BEFORE insert, race window exists
db=db,
)
OAuth (oauth.py, lines 1103-1112, 1566-1574)
# Line 1104 - CHECK: count users
def get_user_role(self, user, user_data):
user_count = Users.get_num_users()
if not user and user_count == 0:
return 'admin' # Line 1112
# Lines 1566-1574 - USE: create user with pre-determined role
user = Auths.insert_new_auth(
...
role=self.get_user_role(None, user_data), # Line 1571
...
)
Both paths determine the role BEFORE inserting the user, creating a race window where multiple concurrent requests on a fresh instance can all observe an empty database and all receive the admin role.
Comparison with Patched Signup
The signup_handler (auths.py, line 663) was explicitly fixed:
# Insert with default role first to avoid TOCTOU race
user = Auths.insert_new_auth(..., role=DEFAULT_USER_ROLE, ...)
# Then check if this is the only user and upgrade
if Users.get_num_users() == 1:
Users.update_user_role_by_id(user.id, 'admin')
The LDAP and OAuth paths did NOT receive this fix.
Exploitation
- Deploy Open WebUI with LDAP or OAuth enabled on a fresh instance (no existing users)
- Send multiple concurrent authentication requests from different users
- Multiple requests pass the
has_users()/get_num_users() == 0check simultaneously - All concurrent users become administrators
DATABASE_ENABLE_SESSION_SHARING defaults to False (env.py:387), so each call uses its own database session, widening the race window.
Impact
Any LDAP/OAuth user who times their first login concurrently with the legitimate first admin can escalate to full admin privileges, gaining access to all user data, system configuration, API keys, and connected LLM backends.
Suggested Fix
Apply the same insert-then-check pattern used in signup_handler: insert the user with DEFAULT_USER_ROLE first, then atomically check if this is the only user and upgrade to admin only if so.
Resolution
Fixed in PR #23626 (commit 96a0b3239), first released in v0.9.0 (Apr 2026). Both LDAP (routers/auths.py) and OAuth (utils/oauth.py) registration paths now use the same insert-first-check-after pattern that signup_handler already had:
- Insert the new user with
DEFAULT_USER_ROLEunconditionally — no pre-insert role decision based on user count. - After the insert commits, atomically call
Users.get_num_users() == 1to check whether this is the sole user. - Only the sole user gets promoted to
adminviaUsers.update_user_role_by_id.
OAuthManager.get_user_role was also updated to return DEFAULT_USER_ROLE (not admin) for first-user bootstrap; admin promotion is deferred to the post-insert check above. With this ordering, two concurrent first-user registrations that both observe an empty table can both insert, but only one will see get_num_users() == 1 afterward — the other will see == 2 and not be promoted.
Users on >= 0.9.0 are not affected.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.12"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45675"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:28:46Z",
"nvd_published_at": "2026-05-15T20:16:49Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe LDAP and OAuth authentication flows use a TOCTOU (Time-of-Check-Time-of-Use) pattern for first-user admin role assignment. The regular signup handler (`signup_handler` in auths.py, line 663) was explicitly patched to prevent this race with the comment *\"Insert with default role first to avoid TOCTOU race\"*, but the LDAP and OAuth code paths were never updated with the same fix.\n\n## Vulnerable Code\n\n### LDAP (auths.py, lines 479-490)\n```python\n# Line 482 - CHECK: is the user table empty?\nrole = \u0027admin\u0027 if not Users.has_users(db=db) else request.app.state.config.DEFAULT_USER_ROLE\n\n# Lines 484-490 - USE: create user with the role determined above\nuser = Auths.insert_new_auth(\n email=email,\n password=str(uuid.uuid4()),\n name=cn,\n role=role, # \u003c-- role was determined BEFORE insert, race window exists\n db=db,\n)\n```\n\n### OAuth (oauth.py, lines 1103-1112, 1566-1574)\n```python\n# Line 1104 - CHECK: count users\ndef get_user_role(self, user, user_data):\n user_count = Users.get_num_users()\n if not user and user_count == 0:\n return \u0027admin\u0027 # Line 1112\n\n# Lines 1566-1574 - USE: create user with pre-determined role\nuser = Auths.insert_new_auth(\n ...\n role=self.get_user_role(None, user_data), # Line 1571\n ...\n)\n```\n\nBoth paths determine the role BEFORE inserting the user, creating a race window where multiple concurrent requests on a fresh instance can all observe an empty database and all receive the `admin` role.\n\n## Comparison with Patched Signup\n\nThe `signup_handler` (auths.py, line 663) was explicitly fixed:\n```python\n# Insert with default role first to avoid TOCTOU race\nuser = Auths.insert_new_auth(..., role=DEFAULT_USER_ROLE, ...)\n# Then check if this is the only user and upgrade\nif Users.get_num_users() == 1:\n Users.update_user_role_by_id(user.id, \u0027admin\u0027)\n```\n\nThe LDAP and OAuth paths did NOT receive this fix.\n\n## Exploitation\n\n1. Deploy Open WebUI with LDAP or OAuth enabled on a fresh instance (no existing users)\n2. Send multiple concurrent authentication requests from different users\n3. Multiple requests pass the `has_users()` / `get_num_users() == 0` check simultaneously\n4. All concurrent users become administrators\n\n`DATABASE_ENABLE_SESSION_SHARING` defaults to `False` (env.py:387), so each call uses its own database session, widening the race window.\n\n## Impact\n\nAny LDAP/OAuth user who times their first login concurrently with the legitimate first admin can escalate to full admin privileges, gaining access to all user data, system configuration, API keys, and connected LLM backends.\n\n## Suggested Fix\n\nApply the same insert-then-check pattern used in `signup_handler`: insert the user with `DEFAULT_USER_ROLE` first, then atomically check if this is the only user and upgrade to admin only if so.\n\n## Resolution\n\nFixed in PR [#23626](https://github.com/open-webui/open-webui/pull/23626) (commit [96a0b3239](https://github.com/open-webui/open-webui/commit/96a0b3239b1aadb23fc359bf10849c9ba12fd6ec)), first released in **v0.9.0** (Apr 2026). Both LDAP (`routers/auths.py`) and OAuth (`utils/oauth.py`) registration paths now use the same insert-first-check-after pattern that `signup_handler` already had:\n\n1. Insert the new user with `DEFAULT_USER_ROLE` unconditionally \u2014 no pre-insert role decision based on user count.\n2. After the insert commits, atomically call `Users.get_num_users() == 1` to check whether this is the sole user.\n3. Only the sole user gets promoted to `admin` via `Users.update_user_role_by_id`.\n\n`OAuthManager.get_user_role` was also updated to return `DEFAULT_USER_ROLE` (not `admin`) for first-user bootstrap; admin promotion is deferred to the post-insert check above. With this ordering, two concurrent first-user registrations that both observe an empty table can both insert, but only one will see `get_num_users() == 1` afterward \u2014 the other will see `== 2` and not be promoted.\n\nUsers on `\u003e= 0.9.0` are not affected.",
"id": "GHSA-h3ww-q6xx-w7x3",
"modified": "2026-07-15T21:50:58Z",
"published": "2026-05-14T20:28:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-h3ww-q6xx-w7x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45675"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/23626"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/96a0b3239b1aadb23fc359bf10849c9ba12fd6ec"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.9.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2730.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: LDAP and OAuth First-User Race Condition Allows Multiple Admin Accounts"
}
GHSA-H3XQ-RCRH-9XC3
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-07 18:30In wlan driver, there is a race condition, This could lead to local denial of service in wlan services.
{
"affected": [],
"aliases": [
"CVE-2022-42771"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "MODERATE"
},
"details": "In wlan driver, there is a race condition, This could lead to local denial of service in wlan services.",
"id": "GHSA-h3xq-rcrh-9xc3",
"modified": "2022-12-07T18:30:27Z",
"published": "2022-12-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42771"
},
{
"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:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H43G-M94V-WFPV
Vulnerability from github – Published: 2022-10-01 00:00 – Updated: 2025-05-20 21:30drivers/char/pcmcia/synclink_cs.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling ioctl, aka a race condition between mgslpc_ioctl and mgslpc_detach.
{
"affected": [],
"aliases": [
"CVE-2022-41848"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-30T06:15:00Z",
"severity": "MODERATE"
},
"details": "drivers/char/pcmcia/synclink_cs.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling ioctl, aka a race condition between mgslpc_ioctl and mgslpc_detach.",
"id": "GHSA-h43g-m94v-wfpv",
"modified": "2025-05-20T21:30:27Z",
"published": "2022-10-01T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41848"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270"
},
{
"type": "WEB",
"url": "https://lore.kernel.org/lkml/20220919040251.GA302541@ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H484-RM8P-M8MW
Vulnerability from github – Published: 2026-10-28 15:31 – Updated: 2026-10-28 15:31OpenVPN ovpn-dco-win 0.6.5 through 2.8.13 allows unprivileged local users to cause a denial of service (system crash) via a race condition in the TCP connect path.
{
"affected": [],
"aliases": [
"CVE-2026-115402"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-28T15:17:04Z",
"severity": "MODERATE"
},
"details": "OpenVPN ovpn-dco-win 0.6.5 through 2.8.13 allows unprivileged local users to cause a denial of service (system crash) via a\u00a0race condition in the TCP connect path.",
"id": "GHSA-h484-rm8p-m8mw",
"modified": "2026-10-28T15:31:54Z",
"published": "2026-10-28T15:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115402"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/Security%20Announcements/CVE-2026-115402"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-H494-X7P4-QCW3
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in UI Automation Manager (uiamanager.dll) allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-45597"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:27Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in UI Automation Manager (uiamanager.dll) allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-h494-x7p4-qcw3",
"modified": "2026-06-09T18:30:51Z",
"published": "2026-06-09T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45597"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45597"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H49R-VQ54-F89J
Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33Windows Remote Desktop Services Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-49128"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-12T02:04:39Z",
"severity": "HIGH"
},
"details": "Windows Remote Desktop Services Remote Code Execution Vulnerability",
"id": "GHSA-h49r-vq54-f89j",
"modified": "2024-12-12T03:33:05Z",
"published": "2024-12-12T03:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49128"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49128"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H4F8-J958-689C
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-10-19 21:35In the Linux kernel, the following vulnerability has been resolved:
audit: Fix data races of skb_queue_len() readers on audit_queue
Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races.
All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn()
KCSAN reports the following conflicting access pattern (one example):
BUG: KCSAN: data-race in audit_log_start / skb_dequeue
write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30
read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0
value changed: 0x00000001 -> 0x00000000
Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side.
[PM: line length tweak]
{
"affected": [],
"aliases": [
"CVE-2026-64435"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:27Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naudit: Fix data races of skb_queue_len() readers on audit_queue\n\nMultiple readers access audit_queue.qlen via skb_queue_len() without\nholding the queue lock or using READ_ONCE(), while kauditd writes to\nthis field via the skb_dequeue() \u2192 __skb_unlink() path with WRITE_ONCE()\nprotected by a spinlock. This constitutes data races.\n\nAll affected skb_queue_len(\u0026audit_queue) call sites:\n - kauditd_thread() wait_event_freezable() condition\n - audit_receive_msg() AUDIT_GET handler (s.backlog assignment)\n - audit_receive() backlog check\n - audit_log_start() backlog check and pr_warn()\n\nKCSAN reports the following conflicting access pattern (one example):\n==================================================================\nBUG: KCSAN: data-race in audit_log_start / skb_dequeue\n\nwrite (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57:\n skb_dequeue+0x70/0xf0\n kauditd_send_queue+0x71/0x220\n kauditd_thread+0x1cb/0x430\n kthread+0x1c2/0x210\n ret_from_fork+0x162/0x1a0\n ret_from_fork_asm+0x1a/0x30\n\nread to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1:\n audit_log_start+0x2a0/0x6b0\n audit_core_dumps+0x64/0xa0\n do_coredump+0x14b/0x1260\n get_signal+0xeb2/0xf70\n arch_do_signal_or_restart+0x41/0x170\n exit_to_user_mode_loop+0xa2/0x1c0\n do_syscall_64+0x1a3/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0xe0\n\nvalue changed: 0x00000001 -\u003e 0x00000000\n==================================================================\n\nResolve the race by switching to lockless helper skb_queue_len_lockless(),\nwhich internally uses READ_ONCE() and properly pairs with the WRITE_ONCE()\nwrite accesses already present on the writer side.\n\n[PM: line length tweak]",
"id": "GHSA-h4f8-j958-689c",
"modified": "2026-10-19T21:35:34Z",
"published": "2026-07-25T12:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64435"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69f98fff30bdaa72b0cb0e7e078ab6456a0a59b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ff42312ccde549f8c698723822c7db35107a39b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3d85dec60bb0622360fc176b2a51abdbe2ff0ad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b35597bdae1a5d8395da4b9baa993b9b71f74d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5186201fa7030289cc4fe23fae87a3fcb566856"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9a71daaecb2fb1d8c704545cc0b1c920b9bf5d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e575dabb805252e3113fdc3f56f6ecacfde422d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe997a84a385f840b593ead92e575503a5046cee"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H4FF-8JR3-P6JP
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Use after free in Windows Storage allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-58526"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T17:17:12Z",
"severity": "HIGH"
},
"details": "Use after free in Windows Storage allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-h4ff-8jr3-p6jp",
"modified": "2026-07-14T18:32:11Z",
"published": "2026-07-14T18:32:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58526"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-58526"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H52V-87C4-F7QG
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2026-10-30 15:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix block group refcount race in btrfs_create_pending_block_groups()
Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'.
However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur:
btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail
And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent.
The broken refcount aspect will result in a warning like:
[1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]---
Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc.
Fix this fully by taking the lock arou ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-22115"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix block group refcount race in btrfs_create_pending_block_groups()\n\nBlock group creation is done in two phases, which results in a slightly\nunintuitive property: a block group can be allocated/deallocated from\nafter btrfs_make_block_group() adds it to the space_info with\nbtrfs_add_bg_to_space_info(), but before creation is completely completed\nin btrfs_create_pending_block_groups(). As a result, it is possible for a\nblock group to go unused and have \u0027btrfs_mark_bg_unused\u0027 called on it\nconcurrently with \u0027btrfs_create_pending_block_groups\u0027. This causes a\nnumber of issues, which were fixed with the block group flag\n\u0027BLOCK_GROUP_FLAG_NEW\u0027.\n\nHowever, this fix is not quite complete. Since it does not use the\nunused_bg_lock, it is possible for the following race to occur:\n\nbtrfs_create_pending_block_groups btrfs_mark_bg_unused\n if list_empty // false\n list_del_init\n clear_bit\n else if (test_bit) // true\n list_move_tail\n\nAnd we get into the exact same broken ref count and invalid new_bgs\nstate for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to\nprevent.\n\nThe broken refcount aspect will result in a warning like:\n\n [1272.943527] refcount_t: underflow; use-after-free.\n [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110\n [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs]\n [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108\n [1272.946368] Tainted: [W]=WARN\n [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs]\n [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110\n [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282\n [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000\n [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff\n [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268\n [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0\n [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0\n [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000\n [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0\n [1272.954474] Call Trace:\n [1272.954655] \u003cTASK\u003e\n [1272.954812] ? refcount_warn_saturate+0xba/0x110\n [1272.955173] ? __warn.cold+0x93/0xd7\n [1272.955487] ? refcount_warn_saturate+0xba/0x110\n [1272.955816] ? report_bug+0xe7/0x120\n [1272.956103] ? handle_bug+0x53/0x90\n [1272.956424] ? exc_invalid_op+0x13/0x60\n [1272.956700] ? asm_exc_invalid_op+0x16/0x20\n [1272.957011] ? refcount_warn_saturate+0xba/0x110\n [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs]\n [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs]\n [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs]\n [1272.958729] process_one_work+0x130/0x290\n [1272.959026] worker_thread+0x2ea/0x420\n [1272.959335] ? __pfx_worker_thread+0x10/0x10\n [1272.959644] kthread+0xd7/0x1c0\n [1272.959872] ? __pfx_kthread+0x10/0x10\n [1272.960172] ret_from_fork+0x30/0x50\n [1272.960474] ? __pfx_kthread+0x10/0x10\n [1272.960745] ret_from_fork_asm+0x1a/0x30\n [1272.961035] \u003c/TASK\u003e\n [1272.961238] ---[ end trace 0000000000000000 ]---\n\nThough we have seen them in the async discard workfn as well. It is\nmost likely to happen after a relocation finishes which cancels discard,\ntears down the block group, etc.\n\nFix this fully by taking the lock arou\n---truncated---",
"id": "GHSA-h52v-87c4-f7qg",
"modified": "2026-10-30T15:32:06Z",
"published": "2025-04-16T15:34:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22115"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2d8e5168d48a91e7a802d3003e72afb4304bebfa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3232bdf8a135877345c25bf4c0d892334a4c03f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77fd40b7ed0c3acf989a0f2a07b15a0a59ea8f96"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d383a6fc59271aaaf07a33b23b2eac5b9268b7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee56da95f8962b86fec4ef93f866e64c8d025a58"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
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-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.