Common Weakness Enumeration

CWE-667

Allowed-with-Review

Improper Locking

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

733 vulnerabilities reference this CWE, most recent first.

GHSA-6RH8-WW5V-VX2C

Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2025-11-04 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

rtmutex: Drop rt_mutex::wait_lock before scheduling

rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning.

Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop.

[ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-46829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-27T13:15:15Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtmutex: Drop rt_mutex::wait_lock before scheduling\n\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0027scheduling in atomic\u0027 warning.\n\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\n\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ]",
  "id": "GHSA-6rh8-ww5v-vx2c",
  "modified": "2025-11-04T00:31:30Z",
  "published": "2024-09-27T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1401da1486dc1cdbef6025fd74a3977df3a3e5d0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab1441752a38"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6a976e9a47e8e5b326de671811561cab12e6fb1f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/85f03ca98e07cd0786738b56ae73740bce0ac27f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/93f44655472d9cd418293d328f9d141ca234ad83"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a92d81c9efec9280681c27a2c0a963fd0f1338e0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d33d26036a0274b472299d7dcdaa5fb34329f91b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f13b5afc5c4889569d84c3011ce449f61fccfb28"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6RHP-8RX2-2869

Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2026-05-12 12:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix i_data_sem unlock order in ext4_ind_migrate()

Fuzzing reports a possible deadlock in jbd2_log_wait_commit.

This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.

This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.

Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Rule: add

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-50006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T19:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix i_data_sem unlock order in ext4_ind_migrate()\n\nFuzzing reports a possible deadlock in jbd2_log_wait_commit.\n\nThis issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require\nsynchronous updates because the file descriptor is opened with O_SYNC.\nThis can lead to the jbd2_journal_stop() function calling\njbd2_might_wait_for_commit(), potentially causing a deadlock if the\nEXT4_IOC_MIGRATE call races with a write(2) system call.\n\nThis problem only arises when CONFIG_PROVE_LOCKING is enabled. In this\ncase, the jbd2_might_wait_for_commit macro locks jbd2_handle in the\njbd2_journal_stop function while i_data_sem is locked. This triggers\nlockdep because the jbd2_journal_start function might also lock the same\njbd2_handle simultaneously.\n\nFound by Linux Verification Center (linuxtesting.org) with syzkaller.\n\nRule: add",
  "id": "GHSA-6rhp-8rx2-2869",
  "modified": "2026-05-12T12:32:12Z",
  "published": "2024-10-21T21:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50006"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3c46d6060d3e38de22196c1fe7706c5a3c696285"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4192adefc9c570698821c5eb9873320eac2fcbf1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/53b1999cfd2c7addf2e581a32865fe8835467b44"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6252cb6bde7fc76cb8dcb49d1def7c326b190820"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9fedf51ab8cf7b69bff08f37fe0989fec7f5d870"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc749e61c011c255d81b192a822db650c68b313f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d43776b907659affef1de888525847d64b244194"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d58a00e981d3118b91d503da263e640b7cde6729"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ef05572da0c0eb89614ed01cc17d3c882bdbd1ff"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6V44-4W2G-HXP9

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35
VLAI
Details

A locking inconsistency issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_io.c and drivers/tty/tty_jobctrl.c may allow a read-after-free attack against TIOCGSID, aka CID-c8bcd9c5be24.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-29660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416",
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A locking inconsistency issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_io.c and drivers/tty/tty_jobctrl.c may allow a read-after-free attack against TIOCGSID, aka CID-c8bcd9c5be24.",
  "id": "GHSA-6v44-4w2g-hxp9",
  "modified": "2022-05-24T17:35:46Z",
  "published": "2022-05-24T17:35:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29660"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BOB25SU6XUL4TNP7KB63WNZSYTIYFDPP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MZ7OAKAEFAXQRGBZK4LYUWINCD3D2XCL"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210122-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4843"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/164950/Kernel-Live-Patch-Security-Notice-LSN-0082-1.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/12/10/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6VR7-4HPQ-76R6

Vulnerability from github – Published: 2024-02-29 06:30 – Updated: 2024-12-10 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

When running an SVA case, the following soft lockup is triggered:

watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8

Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains.

The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } }

Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-29T06:15:46Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range\n\nWhen running an SVA case, the following soft lockup is triggered:\n--------------------------------------------------------------------\nwatchdog: BUG: soft lockup - CPU#244 stuck for 26s!\npstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50\nlr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50\nsp : ffff8000d83ef290\nx29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000\nx26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000\nx23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0\nx20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0\nx14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a\nx2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001\nCall trace:\n arm_smmu_cmdq_issue_cmdlist+0x178/0xa50\n __arm_smmu_tlb_inv_range+0x118/0x254\n arm_smmu_tlb_inv_range_asid+0x6c/0x130\n arm_smmu_mm_invalidate_range+0xa0/0xa4\n __mmu_notifier_invalidate_range_end+0x88/0x120\n unmap_vmas+0x194/0x1e0\n unmap_region+0xb4/0x144\n do_mas_align_munmap+0x290/0x490\n do_mas_munmap+0xbc/0x124\n __vm_munmap+0xa8/0x19c\n __arm64_sys_munmap+0x28/0x50\n invoke_syscall+0x78/0x11c\n el0_svc_common.constprop.0+0x58/0x1c0\n do_el0_svc+0x34/0x60\n el0_svc+0x2c/0xd4\n el0t_64_sync_handler+0x114/0x140\n el0t_64_sync+0x1a4/0x1a8\n--------------------------------------------------------------------\n\nNote that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed\nto \"arm_smmu_mm_arch_invalidate_secondary_tlbs\", yet the problem remains.\n\nThe commit 06ff87bae8d3 (\"arm64: mm: remove unused functions and variable\nprotoypes\") fixed a similar lockup on the CPU MMU side. Yet, it can occur\nto SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called\ntypically next to MMU tlb flush function, e.g.\n\ttlb_flush_mmu_tlbonly {\n\t\ttlb_flush {\n\t\t\t__flush_tlb_range {\n\t\t\t\t// check MAX_TLBI_OPS\n\t\t\t}\n\t\t}\n\t\tmmu_notifier_arch_invalidate_secondary_tlbs {\n\t\t\tarm_smmu_mm_arch_invalidate_secondary_tlbs {\n\t\t\t\t// does not check MAX_TLBI_OPS\n\t\t\t}\n\t\t}\n\t}\n\nClone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an\nSVA case SMMU uses the CPU page table, so it makes sense to align with the\ntlbflush code. Then, replace per-page TLBI commands with a single per-asid\nTLBI command, if the request size hits this threshold.",
  "id": "GHSA-6vr7-4hpq-76r6",
  "modified": "2024-12-10T21:30:51Z",
  "published": "2024-02-29T06:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52484"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264"
    }
  ],
  "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-6VRX-35FP-7WHC

Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-05-26 15:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/imagination: Fix deadlock in soft reset sequence

The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disable_irq() which internally waits for IRQ handlers, i.e. itself, to complete.

Use disable_irq_nosync() during a soft reset instead.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-23470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-03T16:16:34Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Fix deadlock in soft reset sequence\n\nThe soft reset sequence is currently executed from the threaded IRQ\nhandler, hence it cannot call disable_irq() which internally waits\nfor IRQ handlers, i.e. itself, to complete.\n\nUse disable_irq_nosync() during a soft reset instead.",
  "id": "GHSA-6vrx-35fp-7whc",
  "modified": "2026-05-26T15:32:07Z",
  "published": "2026-04-03T18:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23470"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6f39b48a2d3b1fe83f99477250cd0cd67ca1e1c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9497b1f309436971726e229aa6026954ea7c28e9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a55c2a5c8d680156495b7b1e2a9f5a3e313ba524"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f99e8b813ae5ce8ffd62c33f5753bf0a008af4b1"
    }
  ],
  "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-6W26-4VM6-C7F2

Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-11-27 21:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL

Upon failure all locks need to be dropped before returning to the user.

(cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-53086"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-19T18:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL\n\nUpon failure all locks need to be dropped before returning to the user.\n\n(cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)",
  "id": "GHSA-6w26-4vm6-c7f2",
  "modified": "2024-11-27T21:32:44Z",
  "published": "2024-11-19T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53086"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64a2b6ed4bfd890a0e91955dd8ef8422a3944ed9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/96397b1e25dda8389dea63ec914038a170bf953d"
    }
  ],
  "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-6W9W-8G4V-J4M6

Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2025-04-14 18:31
VLAI
Details

An issue was discovered in illumos before f859e7171bb5db34321e45585839c6c3200ebb90, OmniOS Community Edition r151038, OpenIndiana Hipster 2021.04, and SmartOS 20210923. A local unprivileged user can cause a deadlock and kernel panic via crafted rename and rmdir calls on tmpfs filesystems. Oracle Solaris 10 and 11 is also affected.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-43395"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-26T06:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in illumos before f859e7171bb5db34321e45585839c6c3200ebb90, OmniOS Community Edition r151038, OpenIndiana Hipster 2021.04, and SmartOS 20210923. A local unprivileged user can cause a deadlock and kernel panic via crafted rename and rmdir calls on tmpfs filesystems. Oracle Solaris 10 and 11 is also affected.",
  "id": "GHSA-6w9w-8g4v-j4m6",
  "modified": "2025-04-14T18:31:42Z",
  "published": "2022-12-26T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43395"
    },
    {
      "type": "WEB",
      "url": "https://github.com/illumos/illumos-gate/commit/f859e7171bb5db34321e45585839c6c3200ebb90"
    },
    {
      "type": "WEB",
      "url": "https://github.com/illumos/illumos-gate/blob/069654420de4aade43c63c43cd2896e66945fc8a/usr/src/uts/common/fs/tmpfs/tmp_vnops.c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/illumos/illumos-gate/blob/b3403853e80914bd0aade9b5b605da4878078173/usr/src/uts/common/fs/tmpfs/tmp_dir.c"
    },
    {
      "type": "WEB",
      "url": "https://illumos.topicbox.com/groups/developer/T1c9e4f27f8c2f959/security-heads-up-illumos14424"
    },
    {
      "type": "WEB",
      "url": "https://jgardner100.wordpress.com/2022/01/20/security-heads-up"
    },
    {
      "type": "WEB",
      "url": "https://kebe.com/blog/?p=505"
    },
    {
      "type": "WEB",
      "url": "https://www.illumos.org/issues/14424"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "http://www.tribblix.org/relnotes.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-6WQ5-2J9J-6RVR

Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2026-05-12 12:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

USB: core: Fix deadlock in usb_deauthorize_interface()

Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device.

The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback.

Reported-and-tested by: Yue Sun samsun1006219@gmail.com Reported by: xingwei lee xrivendell7@gmail.com

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26934"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:08Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix deadlock in usb_deauthorize_interface()\n\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface\u0027s parent\nUSB device.\n\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected.  As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete.  But usb_deauthorize_interface() can\u0027t complete\nuntil the device lock has been released, and the lock won\u0027t be\nreleased until the removal has finished.\n\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\n\nReported-and-tested by: Yue Sun \u003csamsun1006219@gmail.com\u003e\nReported by: xingwei lee \u003cxrivendell7@gmail.com\u003e",
  "id": "GHSA-6wq5-2j9j-6rvr",
  "modified": "2026-05-12T12:31:42Z",
  "published": "2024-05-01T06:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26934"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6WX8-W4F5-WWCR

Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47
VLAI
Summary
Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption
Details

Summary

Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.

Concurrent::ReadWriteLock#release_read_lock also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from 0 to -1, after which normal read acquisition raises Concurrent::ResourceLimitError.

This is a synchronization correctness issue in the public Concurrent::ReadWriteLock API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.

Version

Software: concurrent-ruby Version: 1.3.6 Commit: 7a1b78941c081106c20a9ca0144ac73a48d254ab

Details

release_write_lock checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:

def release_write_lock
  return true unless running_writer?
  c = @Counter.update { |counter| counter - RUNNING_WRITER }
  @ReadLock.broadcast
  @WriteLock.signal if waiting_writers(c) > 0
  true
end

Because ownership is not checked, a different thread can clear the RUNNING_WRITER bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.

release_read_lock unconditionally decrements the shared counter:

def release_read_lock
  while true
    c = @Counter.value
    if @Counter.compare_and_set(c, c-1)
      if waiting_writer?(c) && running_readers(c) == 1
        @WriteLock.signal
      end
      break
    end
  end
  true
end

On a fresh lock, this changes the counter from 0 to -1. A later acquire_read_lock raises Concurrent::ResourceLimitError because the maximum-reader check masks the negative counter as saturated.

Reproduce

From the root of a concurrent-ruby checkout, run:

ruby -Ilib/concurrent-ruby - <<'RUBY'
require 'concurrent/atomic/read_write_lock'
require 'concurrent/version'
require 'thread'

puts "ruby=#{RUBY_DESCRIPTION}"
puts "concurrent_ruby_version=#{Concurrent::VERSION}"
puts "poc=ReadWriteLock release methods corrupt or bypass lock state"

lock = Concurrent::ReadWriteLock.new
events = Queue.new
writer1_inside = false

writer1 = Thread.new do
  lock.acquire_write_lock
  writer1_inside = true
  events << :writer1_acquired
  sleep 0.5
  writer1_inside = false
  lock.release_write_lock
  events << :writer1_finished
end

events.pop
puts 'writer1_acquired=true'

intruder_result = nil
intruder = Thread.new do
  intruder_result = lock.release_write_lock
end
intruder.join

puts "wrong_thread_release_write_lock_returned=#{intruder_result}"

writer2_entered_while_writer1_inside = nil
writer2 = Thread.new do
  lock.acquire_write_lock
  writer2_entered_while_writer1_inside = writer1_inside
  lock.release_write_lock
end

writer2.join(0.25)

puts "writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}"

writer1.join

lock2 = Concurrent::ReadWriteLock.new
stray_read_release_result = lock2.release_read_lock
counter_after_stray_read_release = lock2.instance_eval { @Counter.value }
read_after_stray_release = begin
  lock2.acquire_read_lock
  'acquired'
rescue => error
  "#{error.class}: #{error.message}"
end

puts "stray_release_read_lock_returned=#{stray_read_release_result}"
puts "counter_after_stray_read_release=#{counter_after_stray_read_release}"
puts "acquire_read_after_stray_release=#{read_after_stray_release}"

if intruder_result && writer2_entered_while_writer1_inside && counter_after_stray_read_release == -1
  puts 'result=REPRODUCED wrong-thread write release and stray read-release corruption'
else
  puts 'result=NOT_REPRODUCED'
end

Expected result:

  • A second thread successfully calls release_write_lock while the first writer still holds the lock.
  • A second writer enters while the first writer is still inside the write critical section.
  • Calling release_read_lock on a fresh lock changes the counter to -1.
  • A subsequent read acquisition fails with Concurrent::ResourceLimitError.

Log evidence

Local reproduction output:

ruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
concurrent_ruby_version=1.3.6
poc=ReadWriteLock release methods corrupt or bypass lock state
writer1_acquired=true
wrong_thread_release_write_lock_returned=true
writer2_acquired_while_writer1_inside=true
stray_release_read_lock_returned=true
counter_after_stray_read_release=-1
acquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads
result=REPRODUCED wrong-thread write release and stray read-release corruption

Impact

This can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release. The impact is local to applications that expose or misuse the manual acquire_* / release_* APIs. If the lock protects integrity-sensitive mutable state, wrong-thread write release can allow concurrent writers and data races. The stray read-release path can cause denial of service by corrupting the lock counter.

Credit

Pranjali Thakur - depthfirst (depthfirst.com)

Severity
2.1 (Low)
CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "concurrent-ruby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-414",
      "CWE-667"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:47:41Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n`Concurrent::ReadWriteLock#release_write_lock` does not verify that the calling thread acquired the write lock. Any thread with access to the lock object can release an active write lock held by another thread. A second writer can then enter its critical section while the first writer is still running.\n\n`Concurrent::ReadWriteLock#release_read_lock` also decrements the shared counter even when no read lock is held. Calling it on a fresh lock changes the counter from `0` to `-1`, after which normal read acquisition raises `Concurrent::ResourceLimitError`.\n\nThis is a synchronization correctness issue in the public `Concurrent::ReadWriteLock` API. It should not be framed as an authorization bypass; the lock is an in-process concurrency primitive, not an access-control boundary.\n\n###  Version\nSoftware: concurrent-ruby\nVersion: 1.3.6\nCommit: 7a1b78941c081106c20a9ca0144ac73a48d254ab\n\n### Details\n\n`release_write_lock` checks only whether the global counter indicates that a writer is running. It does not track or verify ownership:\n\n```ruby\ndef release_write_lock\n  return true unless running_writer?\n  c = @Counter.update { |counter| counter - RUNNING_WRITER }\n  @ReadLock.broadcast\n  @WriteLock.signal if waiting_writers(c) \u003e 0\n  true\nend\n```\n\nBecause ownership is not checked, a different thread can clear the `RUNNING_WRITER` bit while the original writer is still inside its critical section. Another writer can then acquire the write lock and run concurrently with the first writer.\n\n`release_read_lock` unconditionally decrements the shared counter:\n\n```ruby\ndef release_read_lock\n  while true\n    c = @Counter.value\n    if @Counter.compare_and_set(c, c-1)\n      if waiting_writer?(c) \u0026\u0026 running_readers(c) == 1\n        @WriteLock.signal\n      end\n      break\n    end\n  end\n  true\nend\n```\n\nOn a fresh lock, this changes the counter from `0` to `-1`. A later `acquire_read_lock` raises `Concurrent::ResourceLimitError` because the maximum-reader check masks the negative counter as saturated.\n\n# Reproduce\n\nFrom the root of a `concurrent-ruby` checkout, run:\n\n```bash\nruby -Ilib/concurrent-ruby - \u003c\u003c\u0027RUBY\u0027\nrequire \u0027concurrent/atomic/read_write_lock\u0027\nrequire \u0027concurrent/version\u0027\nrequire \u0027thread\u0027\n\nputs \"ruby=#{RUBY_DESCRIPTION}\"\nputs \"concurrent_ruby_version=#{Concurrent::VERSION}\"\nputs \"poc=ReadWriteLock release methods corrupt or bypass lock state\"\n\nlock = Concurrent::ReadWriteLock.new\nevents = Queue.new\nwriter1_inside = false\n\nwriter1 = Thread.new do\n  lock.acquire_write_lock\n  writer1_inside = true\n  events \u003c\u003c :writer1_acquired\n  sleep 0.5\n  writer1_inside = false\n  lock.release_write_lock\n  events \u003c\u003c :writer1_finished\nend\n\nevents.pop\nputs \u0027writer1_acquired=true\u0027\n\nintruder_result = nil\nintruder = Thread.new do\n  intruder_result = lock.release_write_lock\nend\nintruder.join\n\nputs \"wrong_thread_release_write_lock_returned=#{intruder_result}\"\n\nwriter2_entered_while_writer1_inside = nil\nwriter2 = Thread.new do\n  lock.acquire_write_lock\n  writer2_entered_while_writer1_inside = writer1_inside\n  lock.release_write_lock\nend\n\nwriter2.join(0.25)\n\nputs \"writer2_acquired_while_writer1_inside=#{writer2_entered_while_writer1_inside}\"\n\nwriter1.join\n\nlock2 = Concurrent::ReadWriteLock.new\nstray_read_release_result = lock2.release_read_lock\ncounter_after_stray_read_release = lock2.instance_eval { @Counter.value }\nread_after_stray_release = begin\n  lock2.acquire_read_lock\n  \u0027acquired\u0027\nrescue =\u003e error\n  \"#{error.class}: #{error.message}\"\nend\n\nputs \"stray_release_read_lock_returned=#{stray_read_release_result}\"\nputs \"counter_after_stray_read_release=#{counter_after_stray_read_release}\"\nputs \"acquire_read_after_stray_release=#{read_after_stray_release}\"\n\nif intruder_result \u0026\u0026 writer2_entered_while_writer1_inside \u0026\u0026 counter_after_stray_read_release == -1\n  puts \u0027result=REPRODUCED wrong-thread write release and stray read-release corruption\u0027\nelse\n  puts \u0027result=NOT_REPRODUCED\u0027\nend\n```\nExpected result:\n\n- A second thread successfully calls `release_write_lock` while the first writer still holds the lock.\n- A second writer enters while the first writer is still inside the write critical section.\n- Calling `release_read_lock` on a fresh lock changes the counter to `-1`.\n- A subsequent read acquisition fails with `Concurrent::ResourceLimitError`.\n\n### Log evidence\n\nLocal reproduction output:\n\n```text\nruby=ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]\nconcurrent_ruby_version=1.3.6\npoc=ReadWriteLock release methods corrupt or bypass lock state\nwriter1_acquired=true\nwrong_thread_release_write_lock_returned=true\nwriter2_acquired_while_writer1_inside=true\nstray_release_read_lock_returned=true\ncounter_after_stray_read_release=-1\nacquire_read_after_stray_release=Concurrent::ResourceLimitError: Too many reader threads\nresult=REPRODUCED wrong-thread write release and stray read-release corruption\n```\n\n### Impact\nThis can break the write-lock mutual exclusion guarantee and can also leave a lock unusable after a stray read release.\nThe impact is local to applications that expose or misuse the manual `acquire_*` / `release_*` APIs. If the lock protects integrity-sensitive mutable state, wrong-thread write release can allow concurrent writers and data races. The stray read-release path can cause denial of service by corrupting the lock counter.\n\n### Credit\nPranjali Thakur - depthfirst ([depthfirst.com](\u003chttp://depthfirst.com\u003e))",
  "id": "GHSA-6wx8-w4f5-wwcr",
  "modified": "2026-06-19T20:47:41Z",
  "published": "2026-06-19T20:47:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby-concurrency/concurrent-ruby/security/advisories/GHSA-6wx8-w4f5-wwcr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby-concurrency/concurrent-ruby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Concurrent Ruby: ReadWriteLock allows wrong-thread write release and stray read-release counter corruption"
}

GHSA-72W6-32C7-VF7P

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-06-01 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ublk: fix deadlock when reading partition table

When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur:

  1. bdev_open() grabs disk->open_mutex
  2. The process issues read I/O to ublk backend to read partition table
  3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks
  4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation)
  5. This eventually calls blkdev_release() from the same context
  6. blkdev_release() tries to grab disk->open_mutex again
  7. Deadlock: same task waiting for a mutex it already holds

The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock.

[axboe: rewrite comment in ublk]

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-68823"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T16:16:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fix deadlock when reading partition table\n\nWhen one process(such as udev) opens ublk block device (e.g., to read\nthe partition table via bdev_open()), a deadlock[1] can occur:\n\n1. bdev_open() grabs disk-\u003eopen_mutex\n2. The process issues read I/O to ublk backend to read partition table\n3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()\n   runs bio-\u003ebi_end_io() callbacks\n4. If this triggers fput() on file descriptor of ublk block device, the\n   work may be deferred to current task\u0027s task work (see fput() implementation)\n5. This eventually calls blkdev_release() from the same context\n6. blkdev_release() tries to grab disk-\u003eopen_mutex again\n7. Deadlock: same task waiting for a mutex it already holds\n\nThe fix is to run blk_update_request() and blk_mq_end_request() with bottom\nhalves disabled. This forces blkdev_release() to run in kernel work-queue\ncontext instead of current task work context, and allows ublk server to make\nforward progress, and avoids the deadlock.\n\n[axboe: rewrite comment in ublk]",
  "id": "GHSA-72w6-32c7-vf7p",
  "modified": "2026-06-01T18:31:21Z",
  "published": "2026-01-13T18:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68823"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0460e09a614291f06c008443f47393c37b7358e7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/27bb79b7717b2fbb111a1c13548b2786ee712dca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64c0b7e2293757e8320f13434cd809f1c9257a62"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9bcc47343ee0ef346aa7b2b460c8ff56bd882fe7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c258f5c4502c9667bccf5d76fa731ab9c96687c1"
    }
  ],
  "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
Implementation

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.

← Back to the CWE list