Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/01/GHSA-f4x6-mr29-4g4q/GHSA-f4x6-mr29-4g4q.json

@@ -25,7 +25,9 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-79"
+    ],
     "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,

advisories/unreviewed/2025/03/GHSA-3r92-3wmq-rmm2/GHSA-3r92-3wmq-rmm2.json

@@ -26,7 +26,8 @@
   ],
   "database_specific": {
     "cwe_ids": [
-      "CWE-352"
+      "CWE-352",
+      "CWE-79"
     ],
     "severity": "MODERATE",
     "github_reviewed": false,

advisories/unreviewed/2025/06/GHSA-p473-xrh6-2cx4/GHSA-p473-xrh6-2cx4.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-p473-xrh6-2cx4",
-  "modified": "2025-06-20T15:30:36Z",
+  "modified": "2026-01-09T21:31:32Z",
   "published": "2025-06-18T18:30:32Z",
   "aliases": [
     "CVE-2025-44951"
@@ -23,6 +23,10 @@
       "type": "WEB",
       "url": "https://github.com/open5gs/open5gs/issues/3775"
     },
+    {
+      "type": "WEB",
+      "url": "https://github.com/open5gs/open5gs/commit/e3dd98cd291fba233a46adb2881213fc6e38b924"
+    },
     {
       "type": "WEB",
       "url": "https://gist.github.com/scemodicecosa/6d878d6074f0e2f4a8fb69e9864068b7"

advisories/unreviewed/2025/08/GHSA-fpx7-665w-c5c9/GHSA-fpx7-665w-c5c9.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-fpx7-665w-c5c9",
-  "modified": "2025-11-03T18:31:36Z",
+  "modified": "2026-01-09T21:31:32Z",
   "published": "2025-08-28T15:30:39Z",
   "aliases": [
     "CVE-2024-58240"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntls: separate no-async decryption request handling from async\n\nIf we're not doing async, the handling is much simpler. There's no\nreference counting, we just need to wait for the completion to wake us\nup and return its result.\n\nWe should preferably also use a separate crypto_wait. I'm not seeing a\nUAF as I did in the past, I think aec7961916f3 (\"tls: fix race between\nasync notify and socket close\") took care of it.\n\nThis will make the next fix easier.",
-  "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": [
     {
@@ -36,8 +41,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-416"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-08-28T10:15:31Z"

advisories/unreviewed/2025/08/GHSA-hgm5-99r7-2g2c/GHSA-hgm5-99r7-2g2c.json

@@ -25,7 +25,9 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-352"
+    ],
     "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,

advisories/unreviewed/2025/08/GHSA-vfpq-j5vq-3476/GHSA-vfpq-j5vq-3476.json

@@ -25,7 +25,9 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-79"
+    ],
     "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,

advisories/unreviewed/2025/09/GHSA-3xq3-w9mf-92jr/GHSA-3xq3-w9mf-92jr.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3xq3-w9mf-92jr",
-  "modified": "2025-11-03T18:31:40Z",
+  "modified": "2026-01-09T21:31:32Z",
   "published": "2025-09-11T18:35:51Z",
   "aliases": [
     "CVE-2025-39742"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()\n\nThe function divides number of online CPUs by num_core_siblings, and\nlater checks the divider by zero. This implies a possibility to get\nand divide-by-zero runtime error. Fix it by moving the check prior to\ndivision. This also helps to save one indentation level.",
-  "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": [
     {
@@ -60,8 +65,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-369"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-11T17:15:36Z"

advisories/unreviewed/2025/09/GHSA-5h3j-3mgh-9rr3/GHSA-5h3j-3mgh-9rr3.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5h3j-3mgh-9rr3",
-  "modified": "2025-11-03T18:31:40Z",
+  "modified": "2026-01-09T21:31:32Z",
   "published": "2025-09-11T18:35:51Z",
   "aliases": [
     "CVE-2025-39749"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect ->defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won't happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure's ->defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special().  This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last  enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70\nsoftirqs last  enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [<0000000000000000>] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special().  In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe ->defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending\nfield.  This suffices because this handler is not a fast path.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -61,7 +66,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-11T17:15:38Z"

advisories/unreviewed/2025/09/GHSA-8x83-vv5w-vmh3/GHSA-8x83-vv5w-vmh3.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-8x83-vv5w-vmh3",
-  "modified": "2025-11-03T18:31:40Z",
+  "modified": "2026-01-09T21:31:32Z",
   "published": "2025-09-11T18:35:50Z",
   "aliases": [
     "CVE-2025-39738"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not allow relocation of partially dropped subvolumes\n\n[BUG]\nThere is an internal report that balance triggered transaction abort,\nwith the following call trace:\n\n  item 85 key (594509824 169 0) itemoff 12599 itemsize 33\n          extent refs 1 gen 197740 flags 2\n          ref#0: tree block backref root 7\n  item 86 key (594558976 169 0) itemoff 12566 itemsize 33\n          extent refs 1 gen 197522 flags 2\n          ref#0: tree block backref root 7\n ...\n BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0\n BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117\n ------------[ cut here ]------------\n BTRFS: Transaction aborted (error -117)\n WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]\n\nAnd btrfs check doesn't report anything wrong related to the extent\ntree.\n\n[CAUSE]\nThe cause is a little complex, firstly the extent tree indeed doesn't\nhave the backref for 594526208.\n\nThe extent tree only have the following two backrefs around that bytenr\non-disk:\n\n        item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33\n                refs 1 gen 197740 flags TREE_BLOCK\n                tree block skinny level 0\n                (176 0x7) tree block backref root CSUM_TREE\n        item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33\n                refs 1 gen 197522 flags TREE_BLOCK\n                tree block skinny level 0\n                (176 0x7) tree block backref root CSUM_TREE\n\nBut the such missing backref item is not an corruption on disk, as the\noffending delayed ref belongs to subvolume 934, and that subvolume is\nbeing dropped:\n\n        item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439\n                generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328\n                last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0\n                drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2\n                level 2 generation_v2 198229\n\nAnd that offending tree block 594526208 is inside the dropped range of\nthat subvolume.  That explains why there is no backref item for that\nbytenr and why btrfs check is not reporting anything wrong.\n\nBut this also shows another problem, as btrfs will do all the orphan\nsubvolume cleanup at a read-write mount.\n\nSo half-dropped subvolume should not exist after an RW mount, and\nbalance itself is also exclusive to subvolume cleanup, meaning we\nshouldn't hit a subvolume half-dropped during relocation.\n\nThe root cause is, there is no orphan item for this subvolume.\nIn fact there are 5 subvolumes from around 2021 that have the same\nproblem.\n\nIt looks like the original report has some older kernels running, and\ncaused those zombie subvolumes.\n\nThankfully upstream commit 8d488a8c7ba2 (\"btrfs: fix subvolume/snapshot\ndeletion not triggered on mount\") has long fixed the bug.\n\n[ENHANCEMENT]\nFor repairing such old fs, btrfs-progs will be enhanced.\n\nConsidering how delayed the problem will show up (at run delayed ref\ntime) and at that time we have to abort transaction already, it is too\nlate.\n\nInstead here we reject any half-dropped subvolume for reloc tree at the\nearliest time, preventing confusion and extra time wasted on debugging\nsimilar bugs.",
-  "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": [
     {
@@ -49,7 +54,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-11T17:15:35Z"

advisories/unreviewed/2025/09/GHSA-94hx-q75x-2q84/GHSA-94hx-q75x-2q84.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-94hx-q75x-2q84",
-  "modified": "2025-11-03T18:31:37Z",
+  "modified": "2026-01-09T21:31:32Z",
   "published": "2025-09-05T18:31:15Z",
   "aliases": [
     "CVE-2025-38691"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npNFS: Fix uninited ptr deref in block/scsi layout\n\nThe error occurs on the third attempt to encode extents. When function\next_tree_prepare_commit() reallocates a larger buffer to retry encoding\nextents, the \"layoutupdate_pages\" page array is initialized only after the\nretry loop. But ext_tree_free_commitdata() is called on every iteration\nand tries to put pages in the array, thus dereferencing uninitialized\npointers.\n\nAn additional problem is that there is no limit on the maximum possible\nbuffer_size. When there are too many extents, the client may create a\nlayoutcommit that is larger than the maximum possible RPC size accepted\nby the server.\n\nDuring testing, we observed two typical scenarios. First, one memory page\nfor extents is enough when we work with small files, append data to the\nend of the file, or preallocate extents before writing. But when we fill\na new large file without preallocating, the number of extents can be huge,\nand counting the number of written extents in ext_tree_encode_commit()\ndoes not help much. Since this number increases even more between\nunlocking and locking of ext_tree, the reallocated buffer may not be\nlarge enough again and again.",
-  "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": [
     {
@@ -60,8 +65,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-908"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-04T16:15:37Z"