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-8F6J-F2H2-WFRJ
Vulnerability from github – Published: 2025-09-23 06:30 – Updated: 2025-12-12 21:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix subvolume deletion lockup caused by inodes xarray race
There is a race condition between inode eviction and inode caching that can cause a live struct btrfs_inode to be missing from the root->inodes xarray. Specifically, there is a window during evict() between the inode being unhashed and deleted from the xarray. If btrfs_iget() is called for the same inode in that window, it will be recreated and inserted into the xarray, but then eviction will delete the new entry, leaving nothing in the xarray:
Thread 1 Thread 2
evict() remove_inode_hash() btrfs_iget_path() btrfs_iget_locked() btrfs_read_locked_inode() btrfs_add_inode_to_root() destroy_inode() btrfs_destroy_inode() btrfs_del_inode_from_root() __xa_erase
In turn, this can cause issues for subvolume deletion. Specifically, if an inode is in this lost state, and all other inodes are evicted, then btrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely. If the lost inode has a delayed_node attached to it, then when btrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(), it will loop forever because the delayed_nodes xarray will never become empty (unless memory pressure forces the inode out). We saw this manifest as soft lockups in production.
Fix it by only deleting the xarray entry if it matches the given inode (using __xa_cmpxchg()).
{
"affected": [],
"aliases": [
"CVE-2025-39884"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-23T06:15:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix subvolume deletion lockup caused by inodes xarray race\n\nThere is a race condition between inode eviction and inode caching that\ncan cause a live struct btrfs_inode to be missing from the root-\u003einodes\nxarray. Specifically, there is a window during evict() between the inode\nbeing unhashed and deleted from the xarray. If btrfs_iget() is called\nfor the same inode in that window, it will be recreated and inserted\ninto the xarray, but then eviction will delete the new entry, leaving\nnothing in the xarray:\n\nThread 1 Thread 2\n---------------------------------------------------------------\nevict()\n remove_inode_hash()\n btrfs_iget_path()\n btrfs_iget_locked()\n btrfs_read_locked_inode()\n btrfs_add_inode_to_root()\n destroy_inode()\n btrfs_destroy_inode()\n btrfs_del_inode_from_root()\n __xa_erase\n\nIn turn, this can cause issues for subvolume deletion. Specifically, if\nan inode is in this lost state, and all other inodes are evicted, then\nbtrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.\nIf the lost inode has a delayed_node attached to it, then when\nbtrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),\nit will loop forever because the delayed_nodes xarray will never become\nempty (unless memory pressure forces the inode out). We saw this\nmanifest as soft lockups in production.\n\nFix it by only deleting the xarray entry if it matches the given inode\n(using __xa_cmpxchg()).",
"id": "GHSA-8f6j-f2h2-wfrj",
"modified": "2025-12-12T21:31:32Z",
"published": "2025-09-23T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39884"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ba898c9fcbe6ebb88bcd4df8aab0f90090d202e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1498abaf74f8d7b1e7001f16ed77818d8ae6a59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6a6c280059c4ddc23e12e3de1b01098e240036f"
}
],
"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-8GRV-F28F-G844
Vulnerability from github – Published: 2024-09-11 18:31 – Updated: 2024-09-13 18:31In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix hugetlb vs. core-mm PT locking
We recently made GUP's common page table walking code to also walk hugetlb VMAs without most hugetlb special-casing, preparing for the future of having less hugetlb-specific page table walking code in the codebase. Turns out that we missed one page table locking detail: page table locking for hugetlb folios that are not mapped using a single PMD/PUD.
Assume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB hugetlb folios on arm64 with 4 KiB base page size). GUP, as it walks the page tables, will perform a pte_offset_map_lock() to grab the PTE table lock.
However, hugetlb that concurrently modifies these page tables would actually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the locks would differ. Something similar can happen right now with hugetlb folios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.
This issue can be reproduced [1], for example triggering:
[ 3105.936100] ------------[ cut here ]------------ [ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] Modules linked in: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0 [ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Call trace: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598
Let's make huge_pte_lockptr() effectively use the same PT locks as any core-mm page table walker would. Add ptep_lockptr() to obtain the PTE page table lock using a pte pointer -- unfortunately we cannot convert pte_lockptr() because virt_to_page() doesn't work with kmap'ed page tables we can have with CONFIG_HIGHPTE.
Handle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such that when e.g., CONFIG_PGTABLE_LEVELS==2 with PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected. Document why that works.
There is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb folio being mapped using two PTE page tables. While hugetlb wants to take the PMD table lock, core-mm would grab the PTE table lock of one of both PTE page tables. In such corner cases, we have to make sure that both locks match, which is (fortunately!) currently guaranteed for 8xx as it does not support SMP and consequently doesn't use split PT locks.
[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/
{
"affected": [],
"aliases": [
"CVE-2024-45024"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-11T16:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\n\nWe recently made GUP\u0027s common page table walking code to also walk hugetlb\nVMAs without most hugetlb special-casing, preparing for the future of\nhaving less hugetlb-specific page table walking code in the codebase. \nTurns out that we missed one page table locking detail: page table locking\nfor hugetlb folios that are not mapped using a single PMD/PUD.\n\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\nhugetlb folios on arm64 with 4 KiB base page size). GUP, as it walks the\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\nlock.\n\nHowever, hugetlb that concurrently modifies these page tables would\nactually grab the mm-\u003epage_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\nlocks would differ. Something similar can happen right now with hugetlb\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\n\nThis issue can be reproduced [1], for example triggering:\n\n[ 3105.936100] ------------[ cut here ]------------\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\n[ 3105.944634] Modules linked in: [...]\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\n[ 3105.996986] sp : ffff80008eafb8f0\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\n[ 3106.047957] Call trace:\n[ 3106.049522] try_grab_folio+0x11c/0x188\n[ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\n[ 3106.055527] follow_page_mask+0x1a0/0x2b8\n[ 3106.058118] __get_user_pages+0xf0/0x348\n[ 3106.060647] faultin_page_range+0xb0/0x360\n[ 3106.063651] do_madvise+0x340/0x598\n\nLet\u0027s make huge_pte_lockptr() effectively use the same PT locks as any\ncore-mm page table walker would. Add ptep_lockptr() to obtain the PTE\npage table lock using a pte pointer -- unfortunately we cannot convert\npte_lockptr() because virt_to_page() doesn\u0027t work with kmap\u0027ed page tables\nwe can have with CONFIG_HIGHPTE.\n\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected. Document\nwhy that works.\n\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\nfolio being mapped using two PTE page tables. While hugetlb wants to take\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\nPTE page tables. In such corner cases, we have to make sure that both\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\ndoes not support SMP and consequently doesn\u0027t use split PT locks.\n\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/",
"id": "GHSA-8grv-f28f-g844",
"modified": "2024-09-13T18:31:42Z",
"published": "2024-09-11T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45024"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62"
}
],
"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-8GXF-54JP-WCCF
Vulnerability from github – Published: 2024-08-21 00:30 – Updated: 2024-09-03 15:30In the Linux kernel, the following vulnerability has been resolved:
net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex
The carrier_lock spinlock protects the carrier detection. While it is held, framer_get_status() is called which in turn takes a mutex. This is not correct and can lead to a deadlock.
A run with PROVE_LOCKING enabled detected the issue: [ BUG: Invalid wait context ] ... c204ddbc (&framer->mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78 other info that might help us debug this: context-{4:4} 2 locks held by ifconfig/146: #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664 #1: c2006a40 (&qmc_hdlc->carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98
Avoid the spinlock usage and convert carrier_lock to a mutex.
{
"affected": [],
"aliases": [
"CVE-2024-43862"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T00:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex\n\nThe carrier_lock spinlock protects the carrier detection. While it is\nheld, framer_get_status() is called which in turn takes a mutex.\nThis is not correct and can lead to a deadlock.\n\nA run with PROVE_LOCKING enabled detected the issue:\n [ BUG: Invalid wait context ]\n ...\n c204ddbc (\u0026framer-\u003emutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78\n other info that might help us debug this:\n context-{4:4}\n 2 locks held by ifconfig/146:\n #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664\n #1: c2006a40 (\u0026qmc_hdlc-\u003ecarrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98\n\nAvoid the spinlock usage and convert carrier_lock to a mutex.",
"id": "GHSA-8gxf-54jp-wccf",
"modified": "2024-09-03T15:30:39Z",
"published": "2024-08-21T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43862"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c4d6a347ba7babdf9d90a0eb24048c266cae0532"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f223d2b4acb7a45a6e0581cb380e1af1a6dc7ab9"
}
],
"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-8J66-8F4J-H263
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2024-10-25 21:31In the Linux kernel, the following vulnerability has been resolved:
tracing/timerlat: Drop interface_lock in stop_kthread()
stop_kthread() is the offline callback for "trace/osnoise:online", since commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()"), the following ABBA deadlock scenario is introduced:
T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() |
As the interface_lock here in just for protecting the "kthread" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.
{
"affected": [],
"aliases": [
"CVE-2024-49976"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/timerlat: Drop interface_lock in stop_kthread()\n\nstop_kthread() is the offline callback for \"trace/osnoise:online\", since\ncommit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing\nof kthread in stop_kthread()\"), the following ABBA deadlock scenario is\nintroduced:\n\nT1 | T2 [BP] | T3 [AP]\nosnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun()\n | _cpu_down() | osnoise_cpu_die()\n mutex_lock(\u0026interface_lock) | | stop_kthread()\n | cpus_write_lock() | mutex_lock(\u0026interface_lock)\n cpus_read_lock() | cpuhp_kick_ap() |\n\nAs the interface_lock here in just for protecting the \"kthread\" field of\nthe osn_var, use xchg() instead to fix this issue. Also use\nfor_each_online_cpu() back in stop_per_cpu_kthreads() as it can take\ncpu_read_lock() again.",
"id": "GHSA-8j66-8f4j-h263",
"modified": "2024-10-25T21:31:26Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49976"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09cb44cc3d3df7ade2cebc939d6257a2fa8afc7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4a05ceffe8fad68b45de38fe2311bda619e76e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b484a02c9cedf8703eff8f0756f94618004bd165"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db8571a9a098086608c11a15856ff585789e67e8"
}
],
"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-8MCG-XRHW-92V3
Vulnerability from github – Published: 2025-08-16 12:30 – Updated: 2025-11-19 18:31In the Linux kernel, the following vulnerability has been resolved:
KVM: Allow CPU to reschedule while setting per-page memory attributes
When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+), the host can experience CPU soft lockups when running an operation in kvm_vm_set_mem_attributes() to set memory attributes on the whole range of guest memory.
watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372] CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary) Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024 RIP: 0010:xas_create+0x78/0x1f0 Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87 RSP: 0018:ffffad890a34b940 EFLAGS: 00000286 RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000 RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868 R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868 FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: xas_store+0x58/0x630 __xa_store+0xa5/0x130 xa_store+0x2c/0x50 kvm_vm_set_mem_attributes+0x343/0x710 [kvm] kvm_vm_ioctl+0x796/0xab0 [kvm] __x64_sys_ioctl+0xa3/0xd0 do_syscall_64+0x8c/0x7a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f5578d031bb Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000 R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120 R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0
While looping through the range of memory setting the attributes, call cond_resched() to give the scheduler a chance to run a higher priority task on the runqueue if necessary and avoid staying in kernel mode long enough to trigger the lockup.
{
"affected": [],
"aliases": [
"CVE-2025-38506"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T11:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Allow CPU to reschedule while setting per-page memory attributes\n\nWhen running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),\nthe host can experience CPU soft lockups when running an operation in\nkvm_vm_set_mem_attributes() to set memory attributes on the whole\nrange of guest memory.\n\nwatchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]\nCPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)\nHardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024\nRIP: 0010:xas_create+0x78/0x1f0\nCode: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 \u003c74\u003e 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87\nRSP: 0018:ffffad890a34b940 EFLAGS: 00000286\nRAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000\nRDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868\nR13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868\nFS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n xas_store+0x58/0x630\n __xa_store+0xa5/0x130\n xa_store+0x2c/0x50\n kvm_vm_set_mem_attributes+0x343/0x710 [kvm]\n kvm_vm_ioctl+0x796/0xab0 [kvm]\n __x64_sys_ioctl+0xa3/0xd0\n do_syscall_64+0x8c/0x7a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f5578d031bb\nCode: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb\nRDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b\nRBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000\nR10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120\nR13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0\n\nWhile looping through the range of memory setting the attributes,\ncall cond_resched() to give the scheduler a chance to run a higher\npriority task on the runqueue if necessary and avoid staying in\nkernel mode long enough to trigger the lockup.",
"id": "GHSA-8mcg-xrhw-92v3",
"modified": "2025-11-19T18:31:17Z",
"published": "2025-08-16T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38506"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ef45ae7a3938f0844032ba670b4f89180a5bffc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47bb584237cc285e3a860b70c01f7bda9dcfb05b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9bd1163c8d8f716f45e54d034ee28757cc85549"
}
],
"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-8P3X-34C5-5PMX
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2022-12-13 21:30A vulnerability in the logic that handles access control to one of the hardware components in Cisco's proprietary Secure Boot implementation could allow an authenticated, local attacker to write a modified firmware image to the component. This vulnerability affects multiple Cisco products that support hardware-based Secure Boot functionality. The vulnerability is due to an improper check on the area of code that manages on-premise updates to a Field Programmable Gate Array (FPGA) part of the Secure Boot hardware implementation. An attacker with elevated privileges and access to the underlying operating system that is running on the affected device could exploit this vulnerability by writing a modified firmware image to the FPGA. A successful exploit could either cause the device to become unusable (and require a hardware replacement) or allow tampering with the Secure Boot verification process, which under some circumstances may allow the attacker to install and boot a malicious software image. An attacker will need to fulfill all the following conditions to attempt to exploit this vulnerability: Have privileged administrative access to the device. Be able to access the underlying operating system running on the device; this can be achieved either by using a supported, documented mechanism or by exploiting another vulnerability that would provide an attacker with such access. Develop or have access to a platform-specific exploit. An attacker attempting to exploit this vulnerability across multiple affected platforms would need to research each one of those platforms and then develop a platform-specific exploit. Although the research process could be reused across different platforms, an exploit developed for a given hardware platform is unlikely to work on a different hardware platform.
{
"affected": [],
"aliases": [
"CVE-2019-1649"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-13T19:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the logic that handles access control to one of the hardware components in Cisco\u0027s proprietary Secure Boot implementation could allow an authenticated, local attacker to write a modified firmware image to the component. This vulnerability affects multiple Cisco products that support hardware-based Secure Boot functionality. The vulnerability is due to an improper check on the area of code that manages on-premise updates to a Field Programmable Gate Array (FPGA) part of the Secure Boot hardware implementation. An attacker with elevated privileges and access to the underlying operating system that is running on the affected device could exploit this vulnerability by writing a modified firmware image to the FPGA. A successful exploit could either cause the device to become unusable (and require a hardware replacement) or allow tampering with the Secure Boot verification process, which under some circumstances may allow the attacker to install and boot a malicious software image. An attacker will need to fulfill all the following conditions to attempt to exploit this vulnerability: Have privileged administrative access to the device. Be able to access the underlying operating system running on the device; this can be achieved either by using a supported, documented mechanism or by exploiting another vulnerability that would provide an attacker with such access. Develop or have access to a platform-specific exploit. An attacker attempting to exploit this vulnerability across multiple affected platforms would need to research each one of those platforms and then develop a platform-specific exploit. Although the research process could be reused across different platforms, an exploit developed for a given hardware platform is unlikely to work on a different hardware platform.",
"id": "GHSA-8p3x-34c5-5pmx",
"modified": "2022-12-13T21:30:28Z",
"published": "2022-05-24T16:45:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1649"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190513-secureboot"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/400865"
},
{
"type": "WEB",
"url": "https://www.us-cert.gov/ics/advisories/icsa-20-072-03"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108350"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8PF7-JHFF-4VGR
Vulnerability from github – Published: 2024-06-18 21:30 – Updated: 2024-08-29 03:30In the Linux kernel, the following vulnerability has been resolved:
Revert "media: v4l2-ctrls: show all owned controls in log_status"
This reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739.
This patch introduced a potential deadlock scenario:
[Wed May 8 10:02:06 2024] Possible unsafe locking scenario:
[Wed May 8 10:02:06 2024] CPU0 CPU1 [Wed May 8 10:02:06 2024] ---- ---- [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);
For now just revert.
{
"affected": [],
"aliases": [
"CVE-2024-36976"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-18T20:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"media: v4l2-ctrls: show all owned controls in log_status\"\n\nThis reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739.\n\nThis patch introduced a potential deadlock scenario:\n\n[Wed May 8 10:02:06 2024] Possible unsafe locking scenario:\n\n[Wed May 8 10:02:06 2024] CPU0 CPU1\n[Wed May 8 10:02:06 2024] ---- ----\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)-\u003e_lock);\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)-\u003e_lock);\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)-\u003e_lock);\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)-\u003e_lock);\n\nFor now just revert.",
"id": "GHSA-8pf7-jhff-4vgr",
"modified": "2024-08-29T03:30:48Z",
"published": "2024-06-18T21:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36976"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e0ce54a9c5c7013b1257be044d99cbe7305e9f1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eba63df7eb1f95df6bfb67722a35372b6994928d"
}
],
"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-8PQ8-WMV3-G27X
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
net: rose: lock the socket in rose_bind()
syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads.
rose_bind() must lock the socket to avoid this issue.
{
"affected": [],
"aliases": [
"CVE-2025-21749"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: lock the socket in rose_bind()\n\nsyzbot reported a soft lockup in rose_loopback_timer(),\nwith a repro calling bind() from multiple threads.\n\nrose_bind() must lock the socket to avoid this issue.",
"id": "GHSA-8pq8-wmv3-g27x",
"modified": "2025-11-03T21:32:59Z",
"published": "2025-02-27T03:34:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21749"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c04b0ab3a647e76d0e752b013de8e404abafc63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/667f61b3498df751c8b3f0be1637e7226cbe3ed0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/970cd2ed26cdab2b0f15b6d90d7eaa36538244a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1300691aed9ee852b0a9192e29e2bdc2411a7e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8bf5c3fb778bbb1f3ff7d98ec577c969f687513"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d308661a0f4e7c8e86dfc7074a55ee5894c61538"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0384efd45f615603e6869205b72040c209e69cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed00c5f907d08a647b8bf987514ad8c6b17971a7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.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-8QQ6-88XP-8GHP
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 00:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix deadlock in tc route query code
Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways:
-
RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is.
-
Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as "best effort" check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'.
-
Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.
[0]:
[ 164.599612] ====================================================== [ 164.600142] WARNING: possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021] ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.604459] which lock already depends on the new lock.
[ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [ 164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] _syssendmsg+0x1d0/0x1e0 [ 164.614934] _sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53591"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:55Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix deadlock in tc route query code\n\nCited commit causes ABBA deadlock[0] when peer flows are created while\nholding the devcom rw semaphore. Due to peer flows offload implementation\nthe lock is taken much higher up the call chain and there is no obvious way\nto easily fix the deadlock. Instead, since tc route query code needs the\npeer eswitch structure only to perform a lookup in xarray and doesn\u0027t\nperform any sleeping operations with it, refactor the code for lockless\nexecution in following ways:\n\n- RCUify the devcom \u0027data\u0027 pointer. When resetting the pointer\nsynchronously wait for RCU grace period before returning. This is fine\nsince devcom is currently only used for synchronization of\npairing/unpairing of eswitches which is rare and already expensive as-is.\n\n- Wrap all usages of \u0027paired\u0027 boolean in {READ|WRITE}_ONCE(). The flag has\nalready been used in some unlocked contexts without proper\nannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn\u0027t\nan issue since all relevant code paths checked it again after obtaining the\ndevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as\n\"best effort\" check to return NULL when devcom is being unpaired. Note that\nwhile RCU read lock doesn\u0027t prevent the unpaired flag from being changed\nconcurrently it still guarantees that reader can continue to use \u0027data\u0027.\n\n- Refactor mlx5e_tc_query_route_vport() function to use new\nmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.\n\n[0]:\n\n[ 164.599612] ======================================================\n[ 164.600142] WARNING: possible circular locking dependency detected\n[ 164.600667] 6.3.0-rc3+ #1 Not tainted\n[ 164.601021] ------------------------------------------------------\n[ 164.601557] handler1/3456 is trying to acquire lock:\n[ 164.601998] ffff88811f1714b0 (\u0026esw-\u003eoffloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[ 164.603078]\n but task is already holding lock:\n[ 164.603617] ffff88810137fc98 (\u0026comp-\u003esem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[ 164.604459]\n which lock already depends on the new lock.\n\n[ 164.605190]\n the existing dependency chain (in reverse order) is:\n[ 164.605848]\n -\u003e #1 (\u0026comp-\u003esem){++++}-{3:3}:\n[ 164.606380] down_read+0x39/0x50\n[ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]\n[ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]\n[ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]\n[ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]\n[ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]\n[ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]\n[ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]\n[ 164.610741] tc_setup_cb_add+0xd4/0x200\n[ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]\n[ 164.611661] fl_change+0xc95/0x18a0 [cls_flower]\n[ 164.612116] tc_new_tfilter+0x3fc/0xd20\n[ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0\n[ 164.612936] netlink_rcv_skb+0x54/0x100\n[ 164.613339] netlink_unicast+0x190/0x250\n[ 164.613746] netlink_sendmsg+0x245/0x4a0\n[ 164.614150] sock_sendmsg+0x38/0x60\n[ 164.614522] ____sys_sendmsg+0x1d0/0x1e0\n[ 164.614934] ___sys_sendmsg+0x80/0xc0\n[ 164.615320] __sys_sendmsg+0x51/0x90\n[ 164.615701] do_syscall_64+0x3d/0x90\n[ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 164.616568]\n -\u003e #0 (\u0026esw-\u003eoffloads.encap_tbl_lock){+.+.}-{3:3}:\n[ 164.617210] __lock_acquire+0x159e/0x26e0\n[ 164.617638] lock_acquire+0xc2/0x2a0\n[ 164.618018] __mutex_lock+0x92/0xcd0\n[ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]\n[ 164.618943] post_process_attr+0x153/0x2d0 [\n---truncated---",
"id": "GHSA-8qq6-88xp-8ghp",
"modified": "2026-02-10T00:30:28Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53591"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/362063df6ceec80b0b6798b61ae03504dcc125a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/691c041bf20899fc13c793f92ba61ab660fa3a30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69966bce28da6aadccfd968b75d128a79da32d17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7236e420a7d8082b1df4b3e05c739dd2642a662"
}
],
"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-8VV8-FMP2-X4C4
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-12-09 15:31In the Linux kernel, the following vulnerability has been resolved:
tpm: Lock TPM chip in tpm_pm_suspend() first
Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour.
Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.
{
"affected": [],
"aliases": [
"CVE-2024-53085"
],
"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\ntpm: Lock TPM chip in tpm_pm_suspend() first\n\nSetting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy\naccording, as this leaves window for tpm_hwrng_read() to be called while\nthe operation is in progress. The recent bug report gives also evidence of\nthis behaviour.\n\nAadress this by locking the TPM chip before checking any chip-\u003eflags both\nin tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED\ncheck inside tpm_get_random() so that it will be always checked only when\nthe lock is reserved.",
"id": "GHSA-8vv8-fmp2-x4c4",
"modified": "2024-12-09T15:31:33Z",
"published": "2024-11-19T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53085"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9265fed6db601ee2ec47577815387458ef4f047a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc203fe416abdd1c29da594565a7c3c4e979488e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfaf83501a0cbb104499c5b0892ee5ebde4e967f"
}
],
"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.