Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/03/GHSA-3cvm-96rv-2mw4/GHSA-3cvm-96rv-2mw4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3cvm-96rv-2mw4",
-  "modified": "2025-03-27T18:31:26Z",
+  "modified": "2025-10-28T18:30:24Z",
   "published": "2025-03-27T18:31:26Z",
   "aliases": [
     "CVE-2023-52982"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Use wait_on_bit() to wait for the freeing of relinquished volume\n\nThe freeing of relinquished volume will wake up the pending volume\nacquisition by using wake_up_bit(), however it is mismatched with\nwait_var_event() used in fscache_wait_on_volume_collision() and it will\nnever wake up the waiter in the wait-queue because these two functions\noperate on different wait-queues.\n\nAccording to the implementation in fscache_wait_on_volume_collision(),\nif the wake-up of pending acquisition is delayed longer than 20 seconds\n(e.g., due to the delay of on-demand fd closing), the first\nwait_var_event_timeout() will timeout and the following wait_var_event()\nwill hang forever as shown below:\n\n FS-Cache: Potential volume collision new=00000024 old=00000022\n ......\n INFO: task mount:1148 blocked for more than 122 seconds.\n       Not tainted 6.1.0-rc6+ #1\n task:mount           state:D stack:0     pid:1148  ppid:1\n Call Trace:\n  <TASK>\n  __schedule+0x2f6/0xb80\n  schedule+0x67/0xe0\n  fscache_wait_on_volume_collision.cold+0x80/0x82\n  __fscache_acquire_volume+0x40d/0x4e0\n  erofs_fscache_register_volume+0x51/0xe0 [erofs]\n  erofs_fscache_register_fs+0x19c/0x240 [erofs]\n  erofs_fc_fill_super+0x746/0xaf0 [erofs]\n  vfs_get_super+0x7d/0x100\n  get_tree_nodev+0x16/0x20\n  erofs_fc_get_tree+0x20/0x30 [erofs]\n  vfs_get_tree+0x24/0xb0\n  path_mount+0x2fa/0xa90\n  do_mount+0x7c/0xa0\n  __x64_sys_mount+0x8b/0xe0\n  do_syscall_64+0x30/0x60\n  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nConsidering that wake_up_bit() is more selective, so fix it by using\nwait_on_bit() instead of wait_var_event() to wait for the freeing of\nrelinquished volume. In addition because waitqueue_active() is used in\nwake_up_bit() and clear_bit() doesn't imply any memory barrier, use\nclear_and_wake_up_bit() to add the missing memory barrier between\ncursor->flags and waitqueue_active().",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -25,7 +30,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:45Z"

advisories/unreviewed/2025/03/GHSA-54mv-r6h5-c8vf/GHSA-54mv-r6h5-c8vf.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-54mv-r6h5-c8vf",
-  "modified": "2025-03-27T18:31:23Z",
+  "modified": "2025-10-28T18:30:23Z",
   "published": "2025-03-27T18:31:23Z",
   "aliases": [
     "CVE-2021-4454"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate\n\nThe conclusion \"j1939_session_deactivate() should be called with a\nsession ref-count of at least 2\" is incorrect. In some concurrent\nscenarios, j1939_session_deactivate can be called with the session\nref-count less than 2. But there is not any problem because it\nwill check the session active state before session putting in\nj1939_session_deactivate_locked().\n\nHere is the concurrent scenario of the problem reported by syzbot\nand my reproduction log.\n\n        cpu0                            cpu1\n                                j1939_xtp_rx_eoma\nj1939_xtp_rx_abort_one\n                                j1939_session_get_by_addr [kref == 2]\nj1939_session_get_by_addr [kref == 3]\nj1939_session_deactivate [kref == 2]\nj1939_session_put [kref == 1]\n\t\t\t\tj1939_session_completed\n\t\t\t\tj1939_session_deactivate\n\t\t\t\tWARN_ON_ONCE(kref < 2)\n\n=====================================================\nWARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939_session_deactivate+0x5f/0x70\nCPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014\nRIP: 0010:j1939_session_deactivate+0x5f/0x70\nCall Trace:\n j1939_session_deactivate_activate_next+0x11/0x28\n j1939_xtp_rx_eoma+0x12a/0x180\n j1939_tp_recv+0x4a2/0x510\n j1939_can_recv+0x226/0x380\n can_rcv_filter+0xf8/0x220\n can_receive+0x102/0x220\n ? process_backlog+0xf0/0x2c0\n can_rcv+0x53/0xf0\n __netif_receive_skb_one_core+0x67/0x90\n ? process_backlog+0x97/0x2c0\n __netif_receive_skb+0x22/0x80",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -37,7 +42,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:35Z"

advisories/unreviewed/2025/03/GHSA-5w7q-3v7j-8q5q/GHSA-5w7q-3v7j-8q5q.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5w7q-3v7j-8q5q",
-  "modified": "2025-03-27T18:31:26Z",
+  "modified": "2025-10-28T18:30:23Z",
   "published": "2025-03-27T18:31:26Z",
   "aliases": [
     "CVE-2023-52942"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask()\n\nIt was found that the check to see if a partition could use up all\nthe cpus from the parent cpuset in update_parent_subparts_cpumask()\nwas incorrect. As a result, it is possible to leave parent with no\neffective cpu left even if there are tasks in the parent cpuset. This\ncan lead to system panic as reported in [1].\n\nFix this probem by updating the check to fail the enabling the partition\nif parent's effective_cpus is a subset of the child's cpus_allowed.\n\nAlso record the error code when an error happens in update_prstate()\nand add a test case where parent partition and child have the same cpu\nlist and parent has task. Enabling partition in the child will fail in\nthis case.\n\n[1] https://www.spinics.net/lists/cgroups/msg36254.html",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -25,7 +30,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:44Z"

advisories/unreviewed/2025/03/GHSA-6rc5-mh5g-63wm/GHSA-6rc5-mh5g-63wm.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6rc5-mh5g-63wm",
-  "modified": "2025-03-27T18:31:25Z",
+  "modified": "2025-10-28T18:30:23Z",
   "published": "2025-03-27T18:31:25Z",
   "aliases": [
     "CVE-2023-52934"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups\n\nIn commit 34488399fa08 (\"mm/madvise: add file and shmem support to\nMADV_COLLAPSE\") we make the following change to find_pmd_or_thp_or_none():\n\n\t-       if (!pmd_present(pmde))\n\t-               return SCAN_PMD_NULL;\n\t+       if (pmd_none(pmde))\n\t+               return SCAN_PMD_NONE;\n\nThis was for-use by MADV_COLLAPSE file/shmem codepaths, where\nMADV_COLLAPSE might identify a pte-mapped hugepage, only to have\nkhugepaged race-in, free the pte table, and clear the pmd.  Such codepaths\ninclude:\n\nA) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER\n   already in the pagecache.\nB) In retract_page_tables(), if we fail to grab mmap_lock for the target\n   mm/address.\n\nIn these cases, collapse_pte_mapped_thp() really does expect a none (not\njust !present) pmd, and we want to suitably identify that case separate\nfrom the case where no pmd is found, or it's a bad-pmd (of course, many\nthings could happen once we drop mmap_lock, and the pmd could plausibly\nundergo multiple transitions due to intervening fault, split, etc). \nRegardless, the code is prepared install a huge-pmd only when the existing\npmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.\n\nHowever, the commit introduces a logical hole; namely, that we've allowed\n!none- && !huge- && !bad-pmds to be classified as genuine\npte-table-mapping-pmds.  One such example that could leak through are swap\nentries.  The pmd values aren't checked again before use in\npte_offset_map_lock(), which is expecting nothing less than a genuine\npte-table-mapping-pmd.\n\nWe want to put back the !pmd_present() check (below the pmd_none() check),\nbut need to be careful to deal with subtleties in pmd transitions and\ntreatments by various arch.\n\nThe issue is that __split_huge_pmd_locked() temporarily clears the present\nbit (or otherwise marks the entry as invalid), but pmd_present() and\npmd_trans_huge() still need to return true while the pmd is in this\ntransitory state.  For example, x86's pmd_present() also checks the\n_PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also\nchecks a PMD_PRESENT_INVALID bit.\n\nCovering all 4 cases for x86 (all checks done on the same pmd value):\n\n1) pmd_present() && pmd_trans_huge()\n   All we actually know here is that the PSE bit is set. Either:\n   a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE\n      is set.\n      => huge-pmd\n   b) We are currently racing with __split_huge_page().  The danger here\n      is that we proceed as-if we have a huge-pmd, but really we are\n      looking at a pte-mapping-pmd.  So, what is the risk of this\n      danger?\n\n      The only relevant path is:\n\n\tmadvise_collapse() -> collapse_pte_mapped_thp()\n\n      Where we might just incorrectly report back \"success\", when really\n      the memory isn't pmd-backed.  This is fine, since split could\n      happen immediately after (actually) successful madvise_collapse().\n      So, it should be safe to just assume huge-pmd here.\n\n2) pmd_present() && !pmd_trans_huge()\n   Either:\n   a) PSE not set and either PRESENT or PROTNONE is.\n      => pte-table-mapping pmd (or PROT_NONE)\n   b) devmap.  This routine can be called immediately after\n      unlocking/locking mmap_lock -- or called with no locks held (see\n      khugepaged_scan_mm_slot()), so previous VMA checks have since been\n      invalidated.\n\n3) !pmd_present() && pmd_trans_huge()\n  Not possible.\n\n4) !pmd_present() && !pmd_trans_huge()\n  Neither PRESENT nor PROTNONE set\n  => not present\n\nI've checked all archs that implement pmd_trans_huge() (arm64, riscv,\npowerpc, longarch, x86, mips, s390) and this logic roughly translates\n(though devmap treatment is unique to x86 and powerpc, and (3) doesn't\nnecessarily hold in general -- but that doesn't matter since\n!pmd_present() always takes failure path).\n\nAlso, add a comment above find_pmd_or_thp_or_none()\n---truncated---",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -24,8 +29,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:43Z"

advisories/unreviewed/2025/03/GHSA-73pj-2jcm-q7xj/GHSA-73pj-2jcm-q7xj.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-73pj-2jcm-q7xj",
-  "modified": "2025-03-27T18:31:26Z",
+  "modified": "2025-10-28T18:30:24Z",
   "published": "2025-03-27T18:31:26Z",
   "aliases": [
     "CVE-2023-52981"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix request ref counting during error capture & debugfs dump\n\nWhen GuC support was added to error capture, the reference counting\naround the request object was broken. Fix it up.\n\nThe context based search manages the spinlocking around the search\ninternally. So it needs to grab the reference count internally as\nwell. The execlist only request based search relies on external\nlocking, so it needs an external reference count but within the\nspinlock not outside it.\n\nThe only other caller of the context based search is the code for\ndumping engine state to debugfs. That code wasn't previously getting\nan explicit reference at all as it does everything while holding the\nexeclist specific spinlock. So, that needs updaing as well as that\nspinlock doesn't help when using GuC submission. Rather than trying to\nconditionally get/put depending on submission model, just change it to\nalways do the get/put.\n\nv2: Explicitly document adding an extra blank line in some dense code\n(Andy Shevchenko). Fix multiple potential null pointer derefs in case\nof no request found (some spotted by Tvrtko, but there was more!).\nAlso fix a leaked request in case of !started and another in\n__guc_reset_context now that intel_context_find_active_request is\nactually reference counting the returned request.\nv3: Add a _get suffix to intel_context_find_active_request now that it\ngrabs a reference (Daniele).\nv4: Split the intel_guc_find_hung_context change to a separate patch\nand rename intel_context_find_active_request_get to\nintel_context_get_active_request (Tvrtko).\nv5: s/locking/reference counting/ in commit message (Tvrtko)\n\n(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -25,7 +30,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:45Z"

advisories/unreviewed/2025/03/GHSA-c2p3-c9fp-43mx/GHSA-c2p3-c9fp-43mx.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-c2p3-c9fp-43mx",
-  "modified": "2025-03-27T18:31:26Z",
+  "modified": "2025-10-28T18:30:23Z",
   "published": "2025-03-27T18:31:25Z",
   "aliases": [
     "CVE-2023-52940"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: multi-gen LRU: fix crash during cgroup migration\n\nlru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself.  This\nisn't true for the following scenario:\n\n    CPU 1                         CPU 2\n\n  clone()\n    cgroup_can_fork()\n                                cgroup_procs_write()\n    cgroup_post_fork()\n                                  task_lock()\n                                  lru_gen_migrate_mm()\n                                  task_unlock()\n    task_lock()\n    lru_gen_add_mm()\n    task_unlock()\n\nAnd when the above happens, kernel crashes because of linked list\ncorruption (mm_struct->lru_gen.list).",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -25,7 +30,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:43Z"

advisories/unreviewed/2025/03/GHSA-cq6c-crmc-xmvp/GHSA-cq6c-crmc-xmvp.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-cq6c-crmc-xmvp",
-  "modified": "2025-03-27T18:31:26Z",
+  "modified": "2025-10-28T18:30:24Z",
   "published": "2025-03-27T18:31:26Z",
   "aliases": [
     "CVE-2023-52980"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: ublk: extending queue_size to fix overflow\n\nWhen validating drafted SPDK ublk target, in a case that\nassigning large queue depth to multiqueue ublk device,\nublk target would run into a weird incorrect state. During\nrounds of review and debug, An overflow bug was found\nin ublk driver.\n\nIn ublk_cmd.h, UBLK_MAX_QUEUE_DEPTH is 4096 which means\neach ublk queue depth can be set as large as 4096. But\nwhen setting qd for a ublk device,\nsizeof(struct ublk_queue) + depth * sizeof(struct ublk_io)\nwill be larger than 65535 if qd is larger than 2728.\nThen queue_size is overflowed, and ublk_get_queue()\nreferences a wrong pointer position. The wrong content of\nublk_queue elements will lead to out-of-bounds memory\naccess.\n\nExtend queue_size in ublk_device as \"unsigned int\".",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -24,8 +29,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-787"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T17:15:45Z"