CWE-667

{
  "affected": [],
  "aliases": [
    "CVE-2024-27004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  rpm_resume+0xe0/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  clk_pm_runtime_get+0x30/0xb0\n  clk_disable_unused_subtree+0x58/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused+0x4c/0xe4\n  do_one_initcall+0xcc/0x2d8\n  do_initcall_level+0xa4/0x148\n  do_initcalls+0x5c/0x9c\n  do_basic_setup+0x24/0x30\n  kernel_init_freeable+0xec/0x164\n  kernel_init+0x28/0x120\n  ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  schedule_preempt_disabled+0x2c/0x48\n  __mutex_lock+0x238/0x488\n  __mutex_lock_slowpath+0x1c/0x28\n  mutex_lock+0x50/0x74\n  clk_prepare_lock+0x7c/0x9c\n  clk_core_prepare_lock+0x20/0x44\n  clk_prepare+0x24/0x30\n  clk_bulk_prepare+0x40/0xb0\n  mdss_runtime_resume+0x54/0x1c8\n  pm_generic_runtime_resume+0x30/0x44\n  __genpd_runtime_resume+0x68/0x7c\n  genpd_runtime_resume+0x108/0x1f4\n  __rpm_callback+0x84/0x144\n  rpm_callback+0x30/0x88\n  rpm_resume+0x1f4/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  __device_attach+0xe0/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  device_add+0x644/0x814\n  mipi_dsi_device_register_full+0xe4/0x170\n  devm_mipi_dsi_device_register_full+0x28/0x70\n  ti_sn_bridge_probe+0x1dc/0x2c0\n  auxiliary_bus_probe+0x4c/0x94\n  really_probe+0xcc/0x2c8\n  __driver_probe_device+0xa8/0x130\n  driver_probe_device+0x48/0x110\n  __device_attach_driver+0xa4/0xcc\n  bus_for_each_drv+0x8c/0xd8\n  __device_attach+0xf8/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  deferred_probe_work_func+0x9c/0xd8\n  process_one_work+0x148/0x518\n  worker_thread+0x138/0x350\n  kthread+0x138/0x1e0\n  ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0027ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0027re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0027t have the chance to\nschedule away with the prepare_lock held. Let\u0027s fix this immediate\nproblem that can be\n---truncated---",
  "id": "GHSA-cf9c-p3v8-r72c",
  "modified": "2026-05-12T12:31:44Z",
  "published": "2024-05-01T06:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/115554862294397590088ba02f11f2aba6d5016c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/253ab38d1ee652a596942156978a233970d185ba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4af115f1a20a3d9093586079206ee37c2ac55123"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/60ff482c4205a5aac3b0595ab794cfd62295dab5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a29ec0465dce0b871003698698ac6fa92c9a5034"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a424e713e0cc33d4b969cfda25b9f46df4d7b5bc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e581cf5d216289ef292d1a4036d53ce90e122469"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
    }
  ],
  "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-31629"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-24T15:16:42Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: llcp: add missing return after LLCP_CLOSED checks\n\nIn nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket\nstate is LLCP_CLOSED, the code correctly calls release_sock() and\nnfc_llcp_sock_put() but fails to return. Execution falls through to\nthe remainder of the function, which calls release_sock() and\nnfc_llcp_sock_put() again. This results in a double release_sock()\nand a refcount underflow via double nfc_llcp_sock_put(), leading to\na use-after-free.\n\nAdd the missing return statements after the LLCP_CLOSED branches\nin both functions to prevent the fall-through.",
  "id": "GHSA-cfpg-q83x-6923",
  "modified": "2026-06-01T18:31:28Z",
  "published": "2026-04-24T15:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31629"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0eb1263a3b8c36418c9ba295c9ab3abed664edbf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2b5dd4632966c39da6ba74dbc8689b309065e82c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/665315df9c3486cb213fc44d83cc8bcd47fe0d26"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/796e0cac058252d0ad34ebe288e6f7979b5fc9b2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8977fad2b3c6eefd414131168d597c5d1d5e1abf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9b49e2a4b8219a2fc5cebf94f4ec34e509aff8a6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aba4712e8f0381cd5d196534ce2ad082626a5ab6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b2a23529593d011fb433a3d711fc597ed6a6bd2f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ff3d9e8f7244293e303f7b6ef70774291c7c27e9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-47637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T06:37:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix deadlock in concurrent rename whiteout and inode writeback\n\nFollowing hung tasks:\n[   77.028764] task:kworker/u8:4    state:D stack:    0 pid:  132\n[   77.028820] Call Trace:\n[   77.029027]  schedule+0x8c/0x1b0\n[   77.029067]  mutex_lock+0x50/0x60\n[   77.029074]  ubifs_write_inode+0x68/0x1f0 [ubifs]\n[   77.029117]  __writeback_single_inode+0x43c/0x570\n[   77.029128]  writeback_sb_inodes+0x259/0x740\n[   77.029148]  wb_writeback+0x107/0x4d0\n[   77.029163]  wb_workfn+0x162/0x7b0\n\n[   92.390442] task:aa              state:D stack:    0 pid: 1506\n[   92.390448] Call Trace:\n[   92.390458]  schedule+0x8c/0x1b0\n[   92.390461]  wb_wait_for_completion+0x82/0xd0\n[   92.390469]  __writeback_inodes_sb_nr+0xb2/0x110\n[   92.390472]  writeback_inodes_sb_nr+0x14/0x20\n[   92.390476]  ubifs_budget_space+0x705/0xdd0 [ubifs]\n[   92.390503]  do_rename.cold+0x7f/0x187 [ubifs]\n[   92.390549]  ubifs_rename+0x8b/0x180 [ubifs]\n[   92.390571]  vfs_rename+0xdb2/0x1170\n[   92.390580]  do_renameat2+0x554/0x770\n\n, are caused by concurrent rename whiteout and inode writeback processes:\n\trename_whiteout(Thread 1)\t        wb_workfn(Thread2)\nubifs_rename\n  do_rename\n    lock_4_inodes (Hold ui_mutex)\n    ubifs_budget_space\n      make_free_space\n        shrink_liability\n\t  __writeback_inodes_sb_nr\n\t    bdi_split_work_to_wbs (Queue new wb work)\n\t\t\t\t\t      wb_do_writeback(wb work)\n\t\t\t\t\t\t__writeback_single_inode\n\t\t\t\t\t          ubifs_write_inode\n\t\t\t\t\t            LOCK(ui_mutex)\n\t\t\t\t\t\t\t   \u2191\n\t      wb_wait_for_completion (Wait wb work) \u003c-- deadlock!\n\nReproducer (Detail program in [Link]):\n  1. SYS_renameat2(\"/mp/dir/file\", \"/mp/dir/whiteout\", RENAME_WHITEOUT)\n  2. Consume out of space before kernel(mdelay) doing budget for whiteout\n\nFix it by doing whiteout space budget before locking ubifs inodes.\nBTW, it also fixes wrong goto tag \u0027out_release\u0027 in whiteout budget\nerror handling path(It should at least recover dir i_size and unlock\n4 ubifs inodes).",
  "id": "GHSA-cgfp-5vmp-v4j6",
  "modified": "2025-10-01T21:30:52Z",
  "published": "2025-03-18T21:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47637"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b"
    }
  ],
  "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-48800"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-16T12:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmscan: remove deadlock due to throttling failing to make progress\n\nA soft lockup bug in kcompactd was reported in a private bugzilla with\nthe following visible in dmesg;\n\n  watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]\n  watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]\n  watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]\n  watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]\n\nThe machine had 256G of RAM with no swap and an earlier failed\nallocation indicated that node 0 where kcompactd was run was potentially\nunreclaimable;\n\n  Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB\n    inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB\n    mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:\n    0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB\n    kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes\n\nVlastimil Babka investigated a crash dump and found that a task\nmigrating pages was trying to drain PCP lists;\n\n  PID: 52922  TASK: ffff969f820e5000  CPU: 19  COMMAND: \"kworker/u128:3\"\n  Call Trace:\n     __schedule\n     schedule\n     schedule_timeout\n     wait_for_completion\n     __flush_work\n     __drain_all_pages\n     __alloc_pages_slowpath.constprop.114\n     __alloc_pages\n     alloc_migration_target\n     migrate_pages\n     migrate_to_node\n     do_migrate_pages\n     cpuset_migrate_mm_workfn\n     process_one_work\n     worker_thread\n     kthread\n     ret_from_fork\n\nThis failure is specific to CONFIG_PREEMPT=n builds.  The root of the\nproblem is that kcompact0 is not rescheduling on a CPU while a task that\nhas isolated a large number of the pages from the LRU is waiting on\nkcompact0 to reschedule so the pages can be released.  While\nshrink_inactive_list() only loops once around too_many_isolated, reclaim\ncan continue without rescheduling if sc-\u003eskipped_deactivate == 1 which\ncould happen if there was no file LRU and the inactive anon list was not\nlow.",
  "id": "GHSA-cgvj-gwgx-p5f7",
  "modified": "2024-08-21T18:31:27Z",
  "published": "2024-07-16T12:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48800"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3980cff6349687f73d5109f156f23cb261c24164"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b485c6f1f9f54b81443efda5f3d8a5036ba2cd91"
    }
  ],
  "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-3735"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-26T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.",
  "id": "GHSA-ch7h-w2mm-gm7m",
  "modified": "2025-02-28T15:30:57Z",
  "published": "2022-08-27T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3735"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3735"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1997184"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2021-3735"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250228-0009"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-53580"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-04T16:15:53Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: Gadget: core: Help prevent panic during UVC unconfigure\n\nAvichal Rakesh reported a kernel panic that occurred when the UVC\ngadget driver was removed from a gadget\u0027s configuration.  The panic\ninvolves a somewhat complicated interaction between the kernel driver\nand a userspace component (as described in the Link tag below), but\nthe analysis did make one thing clear: The Gadget core should\naccomodate gadget drivers calling usb_gadget_deactivate() as part of\ntheir unbind procedure.\n\nCurrently this doesn\u0027t work.  gadget_unbind_driver() calls\ndriver-\u003eunbind() while holding the udc-\u003econnect_lock mutex, and\nusb_gadget_deactivate() attempts to acquire that mutex, which will\nresult in a deadlock.\n\nThe simple fix is for gadget_unbind_driver() to release the mutex when\ninvoking the -\u003eunbind() callback.  There is no particular reason for\nit to be holding the mutex at that time, and the mutex isn\u0027t held\nwhile the -\u003ebind() callback is invoked.  So we\u0027ll drop the mutex\nbefore performing the unbind callback and reacquire it afterward.\n\nWe\u0027ll also add a couple of comments to usb_gadget_activate() and\nusb_gadget_deactivate().  Because they run in process context they\nmust not be called from a gadget driver\u0027s -\u003edisconnect() callback,\nwhich (according to the kerneldoc for struct usb_gadget_driver in\ninclude/linux/usb/gadget.h) may run in interrupt context.  This may\nhelp prevent similar bugs from arising in the future.",
  "id": "GHSA-cj4h-ch85-55p9",
  "modified": "2026-02-10T15:30:20Z",
  "published": "2025-10-04T18:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53580"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/65dadb2beeb7360232b09ebc4585b54475dfee06"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8c1edc00db65f6d4408b3d1cd845e8da3b9e0ca4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bed19d95fcb9c98dfaa9585922b39a2dfba7898d"
    }
  ],
  "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-49993"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count\n\nIf qi_submit_sync() is invoked with 0 invalidation descriptors (for\ninstance, for DMA draining purposes), we can run into a bug where a\nsubmitting thread fails to detect the completion of invalidation_wait.\nSubsequently, this led to a soft lockup. Currently, there is no impact\nby this bug on the existing users because no callers are submitting\ninvalidations with 0 descriptors. This fix will enable future users\n(such as DMA drain) calling qi_submit_sync() with 0 count.\n\nSuppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while\nconcurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both\nthreads then enter a while loop, waiting for their respective descriptors\nto complete. T1 detects its completion (i.e., T1\u0027s invalidation_wait status\nchanges to QI_DONE by HW) and proceeds to call reclaim_free_desc() to\nreclaim all descriptors, potentially including adjacent ones of other\nthreads that are also marked as QI_DONE.\n\nDuring this time, while T2 is waiting to acquire the qi-\u003eq_lock, the IOMMU\nhardware may complete the invalidation for T2, setting its status to\nQI_DONE. However, if T1\u0027s execution of reclaim_free_desc() frees T2\u0027s\ninvalidation_wait descriptor and changes its status to QI_FREE, T2 will\nnot observe the QI_DONE status for its invalidation_wait and will\nindefinitely remain stuck.\n\nThis soft lockup does not occur when only non-zero descriptors are\nsubmitted.In such cases, invalidation descriptors are interspersed among\nwait descriptors with the status QI_IN_USE, acting as barriers. These\nbarriers prevent the reclaim code from mistakenly freeing descriptors\nbelonging to other submitters.\n\nConsidered the following example timeline:\n\tT1\t\t\tT2\n========================================\n\tID1\n\tWD1\n\twhile(WD1!=QI_DONE)\n\tunlock\n\t\t\t\tlock\n\tWD1=QI_DONE*\t\tWD2\n\t\t\t\twhile(WD2!=QI_DONE)\n\t\t\t\tunlock\n\tlock\n\tWD1==QI_DONE?\n\tID1=QI_DONE\t\tWD2=DONE*\n\treclaim()\n\tID1=FREE\n\tWD1=FREE\n\tWD2=FREE\n\tunlock\n\t\t\t\tsoft lockup! T2 never sees QI_DONE in WD2\n\nWhere:\nID = invalidation descriptor\nWD = wait descriptor\n* Written by hardware\n\nThe root of the problem is that the descriptor status QI_DONE flag is used\nfor two conflicting purposes:\n1. signal a descriptor is ready for reclaim (to be freed)\n2. signal by the hardware that a wait descriptor is complete\n\nThe solution (in this patch) is state separation by using QI_FREE flag\nfor #1.\n\nOnce a thread\u0027s invalidation descriptors are complete, their status would\nbe set to QI_FREE. The reclaim_free_desc() function would then only\nfree descriptors marked as QI_FREE instead of those marked as\nQI_DONE. This change ensures that T2 (from the previous example) will\ncorrectly observe the completion of its invalidation_wait (marked as\nQI_DONE).",
  "id": "GHSA-cjwf-5vh9-w48g",
  "modified": "2024-10-25T15:31:26Z",
  "published": "2024-10-21T18:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49993"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07e4e92f84b7d3018b7064ef8d8438aeb54a2ca5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3cf74230c139f208b7fb313ae0054386eee31a81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8840dc73ac9e1028291458ef1429ec3c2524ffec"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/92ba5b014d5435dd7a1ee02a2c7f2a0e8fe06c36"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de9e7f68762585f7532de8a06de9485bf39dbd38"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dfdbc5ba10fb792c9d6d12ba8cb6e465f97365ed"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e03f00aa4a6c0c49c17857a4048f586636abdc32"
    }
  ],
  "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-2023-20618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-06T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In vcu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519184; Issue ID: ALPS07519184.",
  "id": "GHSA-cm68-wv9q-pqfq",
  "modified": "2023-02-14T18:30:20Z",
  "published": "2023-02-06T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20618"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/February-2023"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-53231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:41Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: don\u0027t try to setup PHY-driven SFP cages when using genphy\n\nWe don\u0027t have support for PHY-driver SFP cages with the genphy code.\n\nOn top of that, it was found by sashiko that running\nsfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY\nprobing runs under RTNL, which isn\u0027t the case for non-genphy drivers.\n\nThis problem was reproduced, and does lead to a deadlock on RTNL.\n\nBefore the blamed commit, the phy_sfp_probe() call was made by\nindividual PHY drivers, so there was no way to get to the SFP probing\npath when using genphy.\n\nLet\u0027s therefore only run phy_sfp_probe when not using genphy.",
  "id": "GHSA-cmgx-qw5m-5j29",
  "modified": "2026-07-02T21:32:06Z",
  "published": "2026-06-25T09:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53231"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a0082ec20a05ef2378410323a5089a8f1786f4a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ef8d739eee6f85303cbecebc01eb72f063de74e0"
    }
  ],
  "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-21807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T20:16:03Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix queue freeze vs limits lock order in sysfs store methods\n\nqueue_attr_store() always freezes a device queue before calling the\nattribute store operation. For attributes that control queue limits, the\nstore operation will also lock the queue limits with a call to\nqueue_limits_start_update(). However, some drivers (e.g. SCSI sd) may\nneed to issue commands to a device to obtain limit values from the\nhardware with the queue limits locked. This creates a potential ABBA\ndeadlock situation if a user attempts to modify a limit (thus freezing\nthe device queue) while the device driver starts a revalidation of the\ndevice queue limits.\n\nAvoid such deadlock by not freezing the queue before calling the\n-\u003estore_limit() method in struct queue_sysfs_entry and instead use the\nqueue_limits_commit_update_frozen helper to freeze the queue after taking\nthe limits lock.\n\nThis also removes taking the sysfs lock for the store_limit method as\nit doesn\u0027t protect anything here, but creates even more nesting.\nHopefully it will go away from the actual sysfs methods entirely soon.\n\n(commit log adapted from a similar patch from  Damien Le Moal)",
  "id": "GHSA-cp43-x3rr-gwcc",
  "modified": "2026-07-18T18:30:20Z",
  "published": "2025-02-27T21:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21807"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1645cd7fd42c236c952e9228badcac4fea1829ea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec"
    }
  ],
  "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"
    }
  ]
}