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-M2V9-W374-5HJ9
Vulnerability from github – Published: 2024-04-25 19:50 – Updated: 2025-01-14 16:37Summary
Prior to v0.3.0, __default__() functions did not respect the @nonreentrancy decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches.
A contract search was additionally performed and no vulnerable contracts were found in production.
PoC
@external
@payable
@nonreentrant("default")
def __default__():
pass
after codegen:
[seq,
[if, [lt, calldatasize, 4], [goto, fallback]],
[mstore, 28, [calldataload, 0]],
[with, _func_sig, [mload, 0], seq],
[seq_unchecked,
[label, fallback],
[seq,
pass,
# Line 5
pass,
pass,
# Line 4
stop]]],
Impact
No vulnerable production contracts were found. Additionally, using a lock on a default function is a very sparsely used pattern. As such, the impact is low.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.16"
},
"package": {
"ecosystem": "PyPI",
"name": "vyper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32648"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T19:50:35Z",
"nvd_published_at": "2024-04-25T18:15:09Z",
"severity": "MODERATE"
},
"details": "### Summary\nPrior to v0.3.0, `__default__()` functions did not respect the `@nonreentrancy` decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches.\n\nA contract search was additionally performed and no vulnerable contracts were found in production.\n\n### PoC\n```vyper\n@external\n@payable\n@nonreentrant(\"default\")\ndef __default__():\n pass\n```\n\nafter codegen:\n```\n[seq,\n [if, [lt, calldatasize, 4], [goto, fallback]],\n [mstore, 28, [calldataload, 0]],\n [with, _func_sig, [mload, 0], seq],\n [seq_unchecked,\n [label, fallback],\n [seq,\n pass,\n # Line 5\n pass,\n pass,\n # Line 4\n stop]]],\n```\n\n### Impact\nNo vulnerable production contracts were found. Additionally, using a lock on a `default` function is a very sparsely used pattern. As such, the impact is `low`.\n",
"id": "GHSA-m2v9-w374-5hj9",
"modified": "2025-01-14T16:37:11Z",
"published": "2024-04-25T19:50:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-m2v9-w374-5hj9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32648"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/issues/2455"
},
{
"type": "WEB",
"url": "https://github.com/vyperlang/vyper/commit/93287e5ac184b53b395c907d40701f721daf8177"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-163.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/vyperlang/vyper"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "vyper default functions don\u0027t respect nonreentrancy keys"
}
GHSA-M484-77R4-H4VF
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-08-21 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: Fix a deadlock in the error handler
The following deadlock has been observed on a test setup:
-
All tags allocated
-
The SCSI error handler calls ufshcd_eh_host_reset_handler()
-
ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler()
-
ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request.
{
"affected": [],
"aliases": [
"CVE-2021-47622"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:02Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: Fix a deadlock in the error handler\n\nThe following deadlock has been observed on a test setup:\n\n - All tags allocated\n\n - The SCSI error handler calls ufshcd_eh_host_reset_handler()\n\n - ufshcd_eh_host_reset_handler() queues work that calls\n ufshcd_err_handler()\n\n - ufshcd_err_handler() locks up as follows:\n\nWorkqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt\nCall trace:\n __switch_to+0x298/0x5d8\n __schedule+0x6cc/0xa94\n schedule+0x12c/0x298\n blk_mq_get_tag+0x210/0x480\n __blk_mq_alloc_request+0x1c8/0x284\n blk_get_request+0x74/0x134\n ufshcd_exec_dev_cmd+0x68/0x640\n ufshcd_verify_dev_init+0x68/0x35c\n ufshcd_probe_hba+0x12c/0x1cb8\n ufshcd_host_reset_and_restore+0x88/0x254\n ufshcd_reset_and_restore+0xd0/0x354\n ufshcd_err_handler+0x408/0xc58\n process_one_work+0x24c/0x66c\n worker_thread+0x3e8/0xa4c\n kthread+0x150/0x1b4\n ret_from_fork+0x10/0x30\n\nFix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved\nrequest.",
"id": "GHSA-m484-77r4-h4vf",
"modified": "2024-08-21T18:31:26Z",
"published": "2024-07-16T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47622"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768"
}
],
"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-M4W5-F9XF-8FGR
Vulnerability from github – Published: 2025-02-09 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
gpio: xilinx: Convert gpio_lock to raw spinlock
irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking.
This fixes the following lockdep splat:
[ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)
{
"affected": [],
"aliases": [
"CVE-2025-21684"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-09T12:15:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: xilinx: Convert gpio_lock to raw spinlock\n\nirq_chip functions may be called in raw spinlock context. Therefore, we\nmust also use a raw spinlock for our own internal locking.\n\nThis fixes the following lockdep splat:\n\n[ 5.349336] =============================\n[ 5.353349] [ BUG: Invalid wait context ]\n[ 5.357361] 6.13.0-rc5+ #69 Tainted: G W\n[ 5.363031] -----------------------------\n[ 5.367045] kworker/u17:1/44 is trying to lock:\n[ 5.371587] ffffff88018b02c0 (\u0026chip-\u003egpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[ 5.380079] other info that might help us debug this:\n[ 5.385138] context-{5:5}\n[ 5.387762] 5 locks held by kworker/u17:1/44:\n[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)\n[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)\n[ 5.411528] #2: ffffff880172c900 (\u0026dev-\u003emutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)\n[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)\n[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)\n[ 5.436472] stack backtrace:\n[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69\n[ 5.448690] Tainted: [W]=WARN\n[ 5.451656] Hardware name: xlnx,zynqmp (DT)\n[ 5.455845] Workqueue: events_unbound deferred_probe_work_func\n[ 5.461699] Call trace:\n[ 5.464147] show_stack+0x18/0x24 C\n[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)\n[ 5.471501] dump_stack (lib/dump_stack.c:130)\n[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)\n[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)\n[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)\n[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)\n[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)\n[ 5.497645] irq_startup (kernel/irq/chip.c:270)\n[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)\n[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)",
"id": "GHSA-m4w5-f9xf-8fgr",
"modified": "2025-11-03T21:32:35Z",
"published": "2025-02-09T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21684"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9860370c2172704b6b4f0075a0c2a29fd84af96a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c035105c5537d2ecad6b9415e9417a1ffbd0a62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0111650ee596219bb5defa0ce1a1308e6e77ccf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d25041d4a3b2af64c888cf762362b2528ba59294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0ed2d0abc021f56fa27dc6d0770535c1851a43b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.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-M5Q9-GX2F-VVF3
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-09-06 18:31In the Linux kernel, the following vulnerability has been resolved:
xen: privcmd: Switch from mutex to spinlock for irqfds
irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock.
Fix it by switching over to a spin lock.
{
"affected": [],
"aliases": [
"CVE-2024-44957"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: privcmd: Switch from mutex to spinlock for irqfds\n\nirqfd_wakeup() gets EPOLLHUP, when it is called by\neventfd_release() by way of wake_up_poll(\u0026ctx-\u003ewqh, EPOLLHUP), which\ngets called under spin_lock_irqsave(). We can\u0027t use a mutex here as it\nwill lead to a deadlock.\n\nFix it by switching over to a spin lock.",
"id": "GHSA-m5q9-gx2f-vvf3",
"modified": "2024-09-06T18:31:28Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae037662440346e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c"
}
],
"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-M65F-MMQM-4FQ6
Vulnerability from github – Published: 2024-08-22 03:31 – Updated: 2024-09-12 15:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: get rid of warning on transaction commit when using flushoncommit
When using the flushoncommit mount option, during almost every transaction commit we trigger a warning from __writeback_inodes_sb_nr():
$ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)
The trace produced in dmesg looks like the following:
[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]---
This is because we started using writeback_inodes_sb() to flush delalloc when committing a transaction (when using -o flushoncommit), in order to avoid deadlocks with filesystem freeze operations. This change was made by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots in flushoncommit"). After that change we started producing that warning, and every now and then a user reports this since the warning happens too often, it spams dmesg/syslog, and a user is unsure if this reflects any problem that might compromise the filesystem's reliability.
We can not just lock the sb->s_umount semaphore before calling writeback_inodes_sb(), because that would at least deadlock with filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem() is called while we are holding that semaphore in write mode, and that can trigger a transaction commit, resulting in a deadlock. It would also trigger the same type of deadlock in the unmount path. Possibly, it could also introduce some other locking dependencies that lockdep would report.
To fix this call try_to_writeback_inodes_sb() instead of writeback_inodes_sb(), because that will try to read lock sb->s_umount and then will only call writeback_inodes_sb() if it was able to lock it. This is fine because the cases where it can't read lock sb->s_umount are during a filesystem unmount or during a filesystem freeze - in those cases sb->s_umount is write locked and sync_filesystem() is called, which calls writeback_inodes_sb(). In other words, in all cases where we can't take a read lock on sb->s_umount, writeback is already being triggered elsewhere.
An alternative would be to call btrfs_start_delalloc_roots() with a number of pages different from LONG_MAX, for example matching the number of delalloc bytes we currently have, in ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-48920"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T02:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: get rid of warning on transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, during almost every transaction\ncommit we trigger a warning from __writeback_inodes_sb_nr():\n\n $ cat fs/fs-writeback.c:\n (...)\n static void __writeback_inodes_sb_nr(struct super_block *sb, ...\n {\n (...)\n WARN_ON(!rwsem_is_locked(\u0026sb-\u003es_umount));\n (...)\n }\n (...)\n\nThe trace produced in dmesg looks like the following:\n\n [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3\n [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif\n [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186\n [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3\n [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)\n [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246\n [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000\n [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50\n [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000\n [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488\n [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460\n [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000\n [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0\n [947.571072] Call Trace:\n [947.572354] \u003cTASK\u003e\n [947.573266] btrfs_commit_transaction+0x1f1/0x998\n [947.576785] ? start_transaction+0x3ab/0x44e\n [947.579867] ? schedule_timeout+0x8a/0xdd\n [947.582716] transaction_kthread+0xe9/0x156\n [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407\n [947.590104] kthread+0x131/0x139\n [947.592168] ? set_kthread_struct+0x32/0x32\n [947.595174] ret_from_fork+0x22/0x30\n [947.597561] \u003c/TASK\u003e\n [947.598553] ---[ end trace 644721052755541c ]---\n\nThis is because we started using writeback_inodes_sb() to flush delalloc\nwhen committing a transaction (when using -o flushoncommit), in order to\navoid deadlocks with filesystem freeze operations. This change was made\nby commit ce8ea7cc6eb313 (\"btrfs: don\u0027t call btrfs_start_delalloc_roots\nin flushoncommit\"). After that change we started producing that warning,\nand every now and then a user reports this since the warning happens too\noften, it spams dmesg/syslog, and a user is unsure if this reflects any\nproblem that might compromise the filesystem\u0027s reliability.\n\nWe can not just lock the sb-\u003es_umount semaphore before calling\nwriteback_inodes_sb(), because that would at least deadlock with\nfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()\nis called while we are holding that semaphore in write mode, and that can\ntrigger a transaction commit, resulting in a deadlock. It would also\ntrigger the same type of deadlock in the unmount path. Possibly, it could\nalso introduce some other locking dependencies that lockdep would report.\n\nTo fix this call try_to_writeback_inodes_sb() instead of\nwriteback_inodes_sb(), because that will try to read lock sb-\u003es_umount\nand then will only call writeback_inodes_sb() if it was able to lock it.\nThis is fine because the cases where it can\u0027t read lock sb-\u003es_umount\nare during a filesystem unmount or during a filesystem freeze - in those\ncases sb-\u003es_umount is write locked and sync_filesystem() is called, which\ncalls writeback_inodes_sb(). In other words, in all cases where we can\u0027t\ntake a read lock on sb-\u003es_umount, writeback is already being triggered\nelsewhere.\n\nAn alternative would be to call btrfs_start_delalloc_roots() with a\nnumber of pages different from LONG_MAX, for example matching the number\nof delalloc bytes we currently have, in \n---truncated---",
"id": "GHSA-m65f-mmqm-4fq6",
"modified": "2024-09-12T15:32:59Z",
"published": "2024-08-22T03:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48920"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/850a77c999b81dd2724efd2684068d6f90db8c16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0f0cf8341e34e5d2265bfd3a7ad68342da1e2aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4d044dbffcd570351f21c747fc77ff90aed7f2e"
}
],
"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-M8CC-C87R-9QR2
Vulnerability from github – Published: 2025-10-01 09:30 – Updated: 2025-12-12 18:30In the Linux kernel, the following vulnerability has been resolved:
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand why it cannot be the other way around, it is sufficient to consider phylink_phy_change(), phylink's callback from the PHY device's phy->phy_link_change() virtual method, invoked by the PHY state machine.
phy_link_up() and phy_link_down(), the (indirect) callers of phylink_phy_change(), are called with &phydev->lock acquired. Then phylink_phy_change() acquires its own &pl->state_mutex, to serialize changes made to its pl->phy_state and pl->link_config. So all other instances of &pl->state_mutex and &phydev->lock must be consistent with this order.
Problem impact
I think the kernel runs a serious deadlock risk if an existing phylink_resolve() thread, which results in a phy_config_inband() call, is concurrent with a phy_link_up() or phy_link_down() call, which will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be limited by the slow speed of the medium auto-negotiation protocol, which makes it unlikely for the current state to still be unresolved when a new one is detected, but I think the problem is there. Nonetheless, the problem was discovered using lockdep.
Proposed solution
Practically speaking, the phy_config_inband() requirement of having phydev->lock acquired must transfer to the caller (phylink is the only caller). There, it must bubble up until immediately before &pl->state_mutex is acquired, for the cases where that takes place.
Solution details, considerations, notes
This is the phy_config_inband() call graph:
sfp_upstream_ops :: connect_phy()
|
v
phylink_sfp_connect_phy()
|
v
phylink_sfp_config_phy()
|
| sfp_upstream_ops :: module_insert()
| |
| v
| phylink_sfp_module_insert()
| |
| | sfp_upstream_ops :: module_start()
| | |
| | v
| | phylink_sfp_module_start()
| | |
| v v
| phylink_sfp_config_optical()
phylink_start() | | | phylink_resume() v v | | phylink_sfp_set_config() | | | v v v phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() | v phy_config_inband()
phylink_major_config() caller #1, phylink_mac_initial_config(), does not acquire &pl->state_mutex nor do its callers. It must acquire &pl->phydev->lock prior to calling phylink_major_config().
phylink_major_config() caller #2, phylink_resolve() acquires &pl->state_mutex, thus also needs to acquire &pl->phydev->lock.
phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-39915"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T08:15:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: transfer phy_config_inband() locking responsibility to phylink\n\nProblem description\n===================\n\nLockdep reports a possible circular locking dependency (AB/BA) between\n\u0026pl-\u003estate_mutex and \u0026phy-\u003elock, as follows.\n\nphylink_resolve() // acquires \u0026pl-\u003estate_mutex\n-\u003e phylink_major_config()\n -\u003e phy_config_inband() // acquires \u0026pl-\u003ephydev-\u003elock\n\nwhereas all the other call sites where \u0026pl-\u003estate_mutex and\n\u0026pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else,\n\u0026pl-\u003ephydev-\u003elock is acquired at the top level, and \u0026pl-\u003estate_mutex at\nthe lower level. A clear example is phylink_bringup_phy().\n\nThe outlier is the newly introduced phy_config_inband() and the existing\nlock order is the correct one. To understand why it cannot be the other\nway around, it is sufficient to consider phylink_phy_change(), phylink\u0027s\ncallback from the PHY device\u0027s phy-\u003ephy_link_change() virtual method,\ninvoked by the PHY state machine.\n\nphy_link_up() and phy_link_down(), the (indirect) callers of\nphylink_phy_change(), are called with \u0026phydev-\u003elock acquired.\nThen phylink_phy_change() acquires its own \u0026pl-\u003estate_mutex, to\nserialize changes made to its pl-\u003ephy_state and pl-\u003elink_config.\nSo all other instances of \u0026pl-\u003estate_mutex and \u0026phydev-\u003elock must be\nconsistent with this order.\n\nProblem impact\n==============\n\nI think the kernel runs a serious deadlock risk if an existing\nphylink_resolve() thread, which results in a phy_config_inband() call,\nis concurrent with a phy_link_up() or phy_link_down() call, which will\ndeadlock on \u0026pl-\u003estate_mutex in phylink_phy_change(). Practically\nspeaking, the impact may be limited by the slow speed of the medium\nauto-negotiation protocol, which makes it unlikely for the current state\nto still be unresolved when a new one is detected, but I think the\nproblem is there. Nonetheless, the problem was discovered using lockdep.\n\nProposed solution\n=================\n\nPractically speaking, the phy_config_inband() requirement of having\nphydev-\u003elock acquired must transfer to the caller (phylink is the only\ncaller). There, it must bubble up until immediately before\n\u0026pl-\u003estate_mutex is acquired, for the cases where that takes place.\n\nSolution details, considerations, notes\n=======================================\n\nThis is the phy_config_inband() call graph:\n\n sfp_upstream_ops :: connect_phy()\n |\n v\n phylink_sfp_connect_phy()\n |\n v\n phylink_sfp_config_phy()\n |\n | sfp_upstream_ops :: module_insert()\n | |\n | v\n | phylink_sfp_module_insert()\n | |\n | | sfp_upstream_ops :: module_start()\n | | |\n | | v\n | | phylink_sfp_module_start()\n | | |\n | v v\n | phylink_sfp_config_optical()\n phylink_start() | |\n | phylink_resume() v v\n | | phylink_sfp_set_config()\n | | |\n v v v\n phylink_mac_initial_config()\n | phylink_resolve()\n | | phylink_ethtool_ksettings_set()\n v v v\n phylink_major_config()\n |\n v\n phy_config_inband()\n\nphylink_major_config() caller #1, phylink_mac_initial_config(), does not\nacquire \u0026pl-\u003estate_mutex nor do its callers. It must acquire\n\u0026pl-\u003ephydev-\u003elock prior to calling phylink_major_config().\n\nphylink_major_config() caller #2, phylink_resolve() acquires\n\u0026pl-\u003estate_mutex, thus also needs to acquire \u0026pl-\u003ephydev-\u003elock.\n\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\ncompletely uninteresting, because it only call\n---truncated---",
"id": "GHSA-m8cc-c87r-9qr2",
"modified": "2025-12-12T18:30:28Z",
"published": "2025-10-01T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39915"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84"
}
],
"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-M8X7-F64C-28W3
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-05-07 15:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix deadlock in nilfs_count_free_blocks()
A semaphore deadlock can occur if nilfs_get_block() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time:
task 1 task 2 ------ ------ * A file operation * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Prepare to write superblock * down_write(rwsem B) <-- nilfs_cleanup_super() * Detect b-tree corruption * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <--
*** DEADLOCK ***
Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem) and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata corruption, __nilfs_error() is called from nilfs_bmap_convert_error() inside the lock section.
Since __nilfs_error() calls nilfs_set_error() unless the filesystem is read-only and nilfs_set_error() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B.
Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfs_count_free_blocks().
However, there is actually no need to take rwsem A in nilfs_count_free_blocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfs_sufile_get_ncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced.
So, this resolves the deadlock problem by just not taking the semaphore in nilfs_count_free_blocks().
{
"affected": [],
"aliases": [
"CVE-2022-49850"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:16:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix deadlock in nilfs_count_free_blocks()\n\nA semaphore deadlock can occur if nilfs_get_block() detects metadata\ncorruption while locating data blocks and a superblock writeback occurs at\nthe same time:\n\ntask 1 task 2\n------ ------\n* A file operation *\nnilfs_truncate()\n nilfs_get_block()\n down_read(rwsem A) \u003c--\n nilfs_bmap_lookup_contig()\n ... generic_shutdown_super()\n nilfs_put_super()\n * Prepare to write superblock *\n down_write(rwsem B) \u003c--\n nilfs_cleanup_super()\n * Detect b-tree corruption * nilfs_set_log_cursor()\n nilfs_bmap_convert_error() nilfs_count_free_blocks()\n __nilfs_error() down_read(rwsem A) \u003c--\n nilfs_set_error()\n down_write(rwsem B) \u003c--\n\n *** DEADLOCK ***\n\nHere, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)-\u003emi_sem)\nand then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata\ncorruption, __nilfs_error() is called from nilfs_bmap_convert_error()\ninside the lock section.\n\nSince __nilfs_error() calls nilfs_set_error() unless the filesystem is\nread-only and nilfs_set_error() attempts to writelock rwsem B (=\nnilfs-\u003ens_sem) to write back superblock exclusively, hierarchical lock\nacquisition occurs in the order rwsem A -\u003e rwsem B.\n\nNow, if another task starts updating the superblock, it may writelock\nrwsem B during the lock sequence above, and can deadlock trying to\nreadlock rwsem A in nilfs_count_free_blocks().\n\nHowever, there is actually no need to take rwsem A in\nnilfs_count_free_blocks() because it, within the lock section, only reads\na single integer data on a shared struct with\nnilfs_sufile_get_ncleansegs(). This has been the case after commit\naa474a220180 (\"nilfs2: add local variable to cache the number of clean\nsegments\"), that is, even before this bug was introduced.\n\nSo, this resolves the deadlock problem by just not taking the semaphore in\nnilfs_count_free_blocks().",
"id": "GHSA-m8x7-f64c-28w3",
"modified": "2025-05-07T15:31:25Z",
"published": "2025-05-01T15:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49850"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1d4ff73062096c21b47954d2996b4df259777bda"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36ff974b0310771417c0be64b64aa221bd70d63d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c89ca6d3dfa6c09c515807a7a97a521f5d5147e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ac932a4921a96ca52f61935dbba64ea87bbd5dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b4506cff6630bb474bb46a2a75c31e533a756ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/abc082aac0d9b6b926038fc3adb7008306581be2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb029b54953420f7a2d65100f1c5107f14411bdc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0cc93080d4c09510b74ecba87fd778cca390bb1"
}
],
"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-M95F-RWPM-5J9F
Vulnerability from github – Published: 2022-04-30 18:15 – Updated: 2024-02-08 21:30qpopper POP server creates lock files with predictable names, which allows local users to cause a denial of service for other users (lack of mail access) by creating lock files for other mail boxes.
{
"affected": [],
"aliases": [
"CVE-2000-1198"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2001-08-31T04:00:00Z",
"severity": "LOW"
},
"details": "qpopper POP server creates lock files with predictable names, which allows local users to cause a denial of service for other users (lack of mail access) by creating lock files for other mail boxes.",
"id": "GHSA-m95f-rwpm-5j9f",
"modified": "2024-02-08T21:30:28Z",
"published": "2022-04-30T18:15:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2000-1198"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=95624629924545\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=95634229925906\u0026w=2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/1132"
}
],
"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-MC7V-WPQV-V4G2
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2024-11-06 18:31In the Linux kernel, the following vulnerability has been resolved:
Input: cyapa - add missing input core locking to suspend/resume functions
Grab input->mutex during suspend/resume functions like it is done in other input drivers. This fixes the following warning during system suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]---
{
"affected": [],
"aliases": [
"CVE-2023-52884"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T11:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: cyapa - add missing input core locking to suspend/resume functions\n\nGrab input-\u003emutex during suspend/resume functions like it is done in\nother input drivers. This fixes the following warning during system\nsuspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c\nModules linked in: ...\nCPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109\nHardware name: Samsung Exynos (Flattened Device Tree)\nWorkqueue: events_unbound async_run_entry_fn\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x58/0x70\n dump_stack_lvl from __warn+0x1a8/0x1cc\n __warn from warn_slowpath_fmt+0x18c/0x1b4\n warn_slowpath_fmt from input_device_enabled+0x68/0x6c\n input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc\n cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c\n cyapa_reinitialize from cyapa_resume+0x48/0x98\n cyapa_resume from dpm_run_callback+0x90/0x298\n dpm_run_callback from device_resume+0xb4/0x258\n device_resume from async_resume+0x20/0x64\n async_resume from async_run_entry_fn+0x40/0x15c\n async_run_entry_fn from process_scheduled_works+0xbc/0x6a8\n process_scheduled_works from worker_thread+0x188/0x454\n worker_thread from kthread+0x108/0x140\n kthread from ret_from_fork+0x14/0x28\nException stack(0xf1625fb0 to 0xf1625ff8)\n...\n---[ end trace 0000000000000000 ]---\n...\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c\nModules linked in: ...\nCPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109\nHardware name: Samsung Exynos (Flattened Device Tree)\nWorkqueue: events_unbound async_run_entry_fn\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x58/0x70\n dump_stack_lvl from __warn+0x1a8/0x1cc\n __warn from warn_slowpath_fmt+0x18c/0x1b4\n warn_slowpath_fmt from input_device_enabled+0x68/0x6c\n input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc\n cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c\n cyapa_reinitialize from cyapa_resume+0x48/0x98\n cyapa_resume from dpm_run_callback+0x90/0x298\n dpm_run_callback from device_resume+0xb4/0x258\n device_resume from async_resume+0x20/0x64\n async_resume from async_run_entry_fn+0x40/0x15c\n async_run_entry_fn from process_scheduled_works+0xbc/0x6a8\n process_scheduled_works from worker_thread+0x188/0x454\n worker_thread from kthread+0x108/0x140\n kthread from ret_from_fork+0x14/0x28\nException stack(0xf1625fb0 to 0xf1625ff8)\n...\n---[ end trace 0000000000000000 ]---",
"id": "GHSA-mc7v-wpqv-v4g2",
"modified": "2024-11-06T18:31:05Z",
"published": "2024-06-21T12:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52884"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75"
}
],
"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-MF7M-5PJ7-586W
Vulnerability from github – Published: 2023-06-28 18:30 – Updated: 2024-04-04 05:15In startLockTaskMode of LockTaskController.java, there is a possible bypass of lock task mode due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-213942596
{
"affected": [],
"aliases": [
"CVE-2023-21189"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-28T18:15:15Z",
"severity": "HIGH"
},
"details": "In startLockTaskMode of LockTaskController.java, there is a possible bypass of lock task mode due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-213942596",
"id": "GHSA-mf7m-5pj7-586w",
"modified": "2024-04-04T05:15:25Z",
"published": "2023-06-28T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21189"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/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.