{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "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"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-107674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-16T19:17:02Z",
    "severity": "MODERATE"
  },
  "details": "IBM i 7.3, 7.4, 7.5, and 7.6 is vulnerable to a denial of service to Digital Certificate Manager (DCM) for System TLS using applications attempting to create secure network connections. A bad actor could use this to prevent a service from starting or cause it to fallback to non-secure connections.",
  "id": "GHSA-72f7-c8f3-jxmm",
  "modified": "2026-10-16T21:32:58Z",
  "published": "2026-10-16T21:32:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107674"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7292225"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-37907"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-20T16:15:27Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix locking order in ivpu_job_submit\n\nFix deadlock in job submission and abort handling.\nWhen a thread aborts currently executing jobs due to a fault,\nit first locks the global lock protecting submitted_jobs (#1).\n\nAfter the last job is destroyed, it proceeds to release the related context\nand locks file_priv (#2). Meanwhile, in the job submission thread,\nthe file_priv lock (#2) is taken first, and then the submitted_jobs\nlock (#1) is obtained when a job is added to the submitted jobs list.\n\n       CPU0                            CPU1\n       ----                    \t       ----\n  (for example due to a fault)         (jobs submissions keep coming)\n\n  lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n  ivpu_jobs_abort_all()\n  job_destroy()\n                                      lock(\u0026file_priv-\u003elock)           #2\n                                      lock(\u0026vdev-\u003esubmitted_jobs_lock) #1\n  file_priv_release()\n  lock(\u0026vdev-\u003econtext_list_lock)\n  lock(\u0026file_priv-\u003elock)           #2\n\nThis order of locking causes a deadlock. To resolve this issue,\nchange the order of locking in ivpu_job_submit().",
  "id": "GHSA-73j2-7869-745f",
  "modified": "2025-11-17T15:30:31Z",
  "published": "2025-05-20T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37907"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/079d2622f8c9e0c380149645fff21d35c59ce6ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab680dc6c78aa035e944ecc8c48a1caab9f39924"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b9b70924a272c2d72023306bc56f521c056212ee"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-50045"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:33Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pci: Fix get_phb_number() locking\n\nThe recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP\nwarning on some systems:\n\n  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper\n  preempt_count: 1, expected: 0\n  RCU nest depth: 0, expected: 0\n  1 lock held by swapper/1:\n   #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220\n  Preemption disabled at:\n  [\u003c00000000\u003e] 0x0\n  CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1\n  Call Trace:\n  [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)\n  [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8\n  [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec\n  [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4\n  [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220\n  [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784\n  [d101de50] [c140852c] discover_phbs+0x30/0x4c\n  [d101de60] [c0007fd4] do_one_initcall+0x94/0x344\n  [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c\n  [d101df10] [c00086e0] kernel_init+0x34/0x160\n  [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64\n\nThis is because pcibios_alloc_controller() holds hose_spinlock but\nof_alias_get_id() takes of_mutex which can sleep.\n\nThe hose_spinlock protects the phb_bitmap, and also the hose_list, but\nit doesn\u0027t need to be held while get_phb_number() calls the OF routines,\nbecause those are only looking up information in the device tree.\n\nSo fix it by having get_phb_number() take the hose_spinlock itself, only\nwhere required, and then dropping the lock before returning.\npcibios_alloc_controller() then needs to take the lock again before the\nlist_add() but that\u0027s safe, the order of the list is not important.",
  "id": "GHSA-752v-r57r-j98p",
  "modified": "2025-11-13T21:31:18Z",
  "published": "2025-06-18T12:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50045"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1d9e75c3d8cdf7c96a94cb77450d4ee070279e6a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5db5ce0f1963c6c8275719a80cb65e9c98d32726"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6f75057c21eab12c6ccb7f06f859641a6edfab99"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d48562a2729742f767b0fdd994d6b2a56a49c63"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/90f195c01a2e8d8da6281791617e21109719c981"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a868f771ee41c97a25a04b8c632a7f06689b307b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ccb0a42d3f40c436295e0fef57ab613ae5b925a4"
    }
  ],
  "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"
    }
  ]
}