Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2022/05/GHSA-f3c4-4h69-w2fp/GHSA-f3c4-4h69-w2fp.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-f3c4-4h69-w2fp",
-  "modified": "2025-11-05T03:30:23Z",
+  "modified": "2025-11-05T17:48:21Z",
   "published": "2022-05-24T17:12:02Z",
   "aliases": [
     "CVE-2019-18860"
@@ -50,6 +50,10 @@
     {
       "type": "WEB",
       "url": "http://www.openwall.com/lists/oss-security/2025/11/05/1"
+    },
+    {
+      "type": "WEB",
+      "url": "http://www.openwall.com/lists/oss-security/2025/11/05/7"
     }
   ],
   "database_specific": {

advisories/unreviewed/2025/05/GHSA-g7p4-4259-746x/GHSA-g7p4-4259-746x.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-g7p4-4259-746x",
-  "modified": "2025-05-01T15:31:42Z",
+  "modified": "2025-11-05T17:48:22Z",
   "published": "2025-05-01T15:31:42Z",
   "aliases": [
     "CVE-2025-37747"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix hang while freeing sigtrap event\n\nPerf can hang while freeing a sigtrap event if a related deferred\nsignal hadn't managed to be sent before the file got closed:\n\nperf_event_overflow()\n   task_work_add(perf_pending_task)\n\nfput()\n   task_work_add(____fput())\n\ntask_work_run()\n    ____fput()\n        perf_release()\n            perf_event_release_kernel()\n                _free_event()\n                    perf_pending_task_sync()\n                        task_work_cancel() -> FAILED\n                        rcuwait_wait_event()\n\nOnce task_work_run() is running, the list of pending callbacks is\nremoved from the task_struct and from this point on task_work_cancel()\ncan't remove any pending and not yet started work items, hence the\ntask_work_cancel() failure and the hang on rcuwait_wait_event().\n\nTask work could be changed to remove one work at a time, so a work\nrunning on the current task can always cancel a pending one, however\nthe wait / wake design is still subject to inverted dependencies when\nremote targets are involved, as pictured by Oleg:\n\nT1                                                      T2\n\nfd = perf_event_open(pid => T2->pid);                  fd = perf_event_open(pid => T1->pid);\nclose(fd)                                              close(fd)\n    <IRQ>                                                  <IRQ>\n    perf_event_overflow()                                  perf_event_overflow()\n       task_work_add(perf_pending_task)                        task_work_add(perf_pending_task)\n    </IRQ>                                                 </IRQ>\n    fput()                                                 fput()\n        task_work_add(____fput())                              task_work_add(____fput())\n\n    task_work_run()                                        task_work_run()\n        ____fput()                                             ____fput()\n            perf_release()                                         perf_release()\n                perf_event_release_kernel()                            perf_event_release_kernel()\n                    _free_event()                                          _free_event()\n                        perf_pending_task_sync()                               perf_pending_task_sync()\n                            rcuwait_wait_event()                                   rcuwait_wait_event()\n\nTherefore the only option left is to acquire the event reference count\nupon queueing the perf task work and release it from the task work, just\nlike it was done before 3a5465418f5f (\"perf: Fix event leak upon exec and file release\")\nbut without the leaks it fixed.\n\nSome adjustments are necessary to make it work:\n\n* A child event might dereference its parent upon freeing. Care must be\n  taken to release the parent last.\n\n* Some places assuming the event doesn't have any reference held and\n  therefore can be freed right away must instead put the reference and\n  let the reference counting to its job.",
-  "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": [
     {
@@ -33,7 +38,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:53Z"

advisories/unreviewed/2025/05/GHSA-rg5g-h6w9-p8cj/GHSA-rg5g-h6w9-p8cj.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-rg5g-h6w9-p8cj",
-  "modified": "2025-05-01T15:31:42Z",
+  "modified": "2025-11-05T17:48:22Z",
   "published": "2025-05-01T15:31:42Z",
   "aliases": [
     "CVE-2025-37746"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/dwc_pcie: fix duplicate pci_dev devices\n\nDuring platform_device_register, wrongly using struct device\npci_dev as platform_data caused a kmemdup copy of pci_dev. Worse\nstill, accessing the duplicated device leads to list corruption as its\nmutex content (e.g., list, magic) remains the same as the original.",
-  "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": [
     {
@@ -24,8 +29,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-704"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:53Z"

advisories/unreviewed/2025/05/GHSA-rvcv-v2wq-wg64/GHSA-rvcv-v2wq-wg64.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-rvcv-v2wq-wg64",
-  "modified": "2025-05-01T15:31:41Z",
+  "modified": "2025-11-05T17:48:22Z",
   "published": "2025-05-01T15:31:41Z",
   "aliases": [
     "CVE-2025-23162"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/vf: Don't try to trigger a full GT reset if VF\n\nVFs don't have access to the GDRST(0x941c) register that driver\nuses to reset a GT. Attempt to trigger a reset using debugfs:\n\n $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset\n\nor due to a hang condition detected by the driver leads to:\n\n [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]\n [ ] xe 0000:00:02.1: [drm] GT0: reset queued\n [ ] xe 0000:00:02.1: [drm] GT0: reset started\n [ ] ------------[ cut here ]------------\n [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0\n [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] Call Trace:\n [ ]  <TASK>\n [ ]  ? show_regs+0x6c/0x80\n [ ]  ? __warn+0x93/0x1c0\n [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ]  ? report_bug+0x182/0x1b0\n [ ]  ? handle_bug+0x6e/0xb0\n [ ]  ? exc_invalid_op+0x18/0x80\n [ ]  ? asm_exc_invalid_op+0x1b/0x20\n [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ]  ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ]  ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]\n [ ]  ? __mutex_unlock_slowpath+0x41/0x2e0\n [ ]  xe_mmio_write32+0x64/0x150 [xe]\n [ ]  do_gt_reset+0x2f/0xa0 [xe]\n [ ]  gt_reset_worker+0x14e/0x1e0 [xe]\n [ ]  process_one_work+0x21c/0x740\n [ ]  worker_thread+0x1db/0x3c0\n\nFix that by sending H2G VF_RESET(0x5507) action instead.",
-  "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": [
     {
@@ -33,7 +38,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:52Z"

advisories/unreviewed/2025/05/GHSA-v99v-6wp3-34rf/GHSA-v99v-6wp3-34rf.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-v99v-6wp3-34rf",
-  "modified": "2025-05-01T15:31:42Z",
+  "modified": "2025-11-05T17:48:22Z",
   "published": "2025-05-01T15:31:42Z",
   "aliases": [
     "CVE-2025-37743"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: Avoid memory leak while enabling statistics\n\nDriver uses monitor destination rings for extended statistics mode and\nstandalone monitor mode. In extended statistics mode, TLVs are parsed from\nthe buffer received from the monitor destination ring and assigned to the\nppdu_info structure to update per-packet statistics. In standalone monitor\nmode, along with per-packet statistics, the packet data (payload) is\ncaptured, and the driver updates per MSDU to mac80211.\n\nWhen the AP interface is enabled, only extended statistics mode is\nactivated. As part of enabling monitor rings for collecting statistics,\nthe driver subscribes to HAL_RX_MPDU_START TLV in the filter\nconfiguration. This TLV is received from the monitor destination ring, and\nkzalloc for the mon_mpdu object occurs, which is not freed, leading to a\nmemory leak. The kzalloc for the mon_mpdu object is only required while\nenabling the standalone monitor interface. This causes a memory leak while\nenabling extended statistics mode in the driver.\n\nFix this memory leak by removing the kzalloc for the mon_mpdu object in\nthe HAL_RX_MPDU_START TLV handling. Additionally, remove the standalone\nmonitor mode handlings in the HAL_MON_BUF_ADDR and HAL_RX_MSDU_END TLVs.\nThese TLV tags will be handled properly when enabling standalone monitor\nmode in the future.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3",
-  "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": [
     {
@@ -24,8 +29,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-401"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:53Z"

advisories/unreviewed/2025/05/GHSA-w4x2-878r-xjgp/GHSA-w4x2-878r-xjgp.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-w4x2-878r-xjgp",
-  "modified": "2025-07-06T12:30:25Z",
+  "modified": "2025-11-05T17:48:21Z",
   "published": "2025-05-01T15:31:41Z",
   "aliases": [
     "CVE-2025-23155"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Fix accessing freed irq affinity_hint\n\nThe cpumask should not be a local variable, since its pointer is saved\nto irq_desc and may be accessed from procfs.\nTo fix it, use the persistent mask cpumask_of(cpu#).",
-  "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": [
     {
@@ -33,7 +38,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:51Z"

advisories/unreviewed/2025/05/GHSA-x3xp-7x67-4cx9/GHSA-x3xp-7x67-4cx9.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-x3xp-7x67-4cx9",
-  "modified": "2025-05-01T15:31:42Z",
+  "modified": "2025-11-05T17:48:22Z",
   "published": "2025-05-01T15:31:42Z",
   "aliases": [
     "CVE-2025-37745"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPM: hibernate: Avoid deadlock in hibernate_compressor_param_set()\n\nsyzbot reported a deadlock in lock_system_sleep() (see below).\n\nThe write operation to \"/sys/module/hibernate/parameters/compressor\"\nconflicts with the registration of ieee80211 device, resulting in a deadlock\nwhen attempting to acquire system_transition_mutex under param_lock.\n\nTo avoid this deadlock, change hibernate_compressor_param_set() to use\nmutex_trylock() for attempting to acquire system_transition_mutex and\nreturn -EBUSY when it fails.\n\nTask flags need not be saved or adjusted before calling\nmutex_trylock(&system_transition_mutex) because the caller is not going\nto end up waiting for this mutex and if it runs concurrently with system\nsuspend in progress, it will be frozen properly when it returns to user\nspace.\n\nsyzbot report:\n\nsyz-executor895/5833 is trying to acquire lock:\nffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56\n\nbut task is already holding lock:\nffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline]\nffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #3 (param_lock){+.+.}-{4:4}:\n       __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n       __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730\n       ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline]\n       rate_control_alloc net/mac80211/rate.c:266 [inline]\n       ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015\n       ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531\n       mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558\n       init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910\n       do_one_initcall+0x128/0x700 init/main.c:1257\n       do_initcall_level init/main.c:1319 [inline]\n       do_initcalls init/main.c:1335 [inline]\n       do_basic_setup init/main.c:1354 [inline]\n       kernel_init_freeable+0x5c7/0x900 init/main.c:1568\n       kernel_init+0x1c/0x2b0 init/main.c:1457\n       ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148\n       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n-> #2 (rtnl_mutex){+.+.}-{4:4}:\n       __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n       __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730\n       wg_pm_notification drivers/net/wireguard/device.c:80 [inline]\n       wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64\n       notifier_call_chain+0xb7/0x410 kernel/notifier.c:85\n       notifier_call_chain_robust kernel/notifier.c:120 [inline]\n       blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline]\n       blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333\n       pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102\n       snapshot_open+0x189/0x2b0 kernel/power/user.c:77\n       misc_open+0x35a/0x420 drivers/char/misc.c:179\n       chrdev_open+0x237/0x6a0 fs/char_dev.c:414\n       do_dentry_open+0x735/0x1c40 fs/open.c:956\n       vfs_open+0x82/0x3f0 fs/open.c:1086\n       do_open fs/namei.c:3830 [inline]\n       path_openat+0x1e88/0x2d80 fs/namei.c:3989\n       do_filp_open+0x20c/0x470 fs/namei.c:4016\n       do_sys_openat2+0x17a/0x1e0 fs/open.c:1428\n       do_sys_open fs/open.c:1443 [inline]\n       __do_sys_openat fs/open.c:1459 [inline]\n       __se_sys_openat fs/open.c:1454 [inline]\n       __x64_sys_openat+0x175/0x210 fs/open.c:1454\n       do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n       do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n-> #1 ((pm_chain_head).rwsem){++++}-{4:4}:\n       down_read+0x9a/0x330 kernel/locking/rwsem.c:1524\n       blocking_notifier_call_chain_robust kerne\n---truncated---",
-  "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": [
     {
@@ -32,8 +37,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-667"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:53Z"

advisories/unreviewed/2025/05/GHSA-xffq-295c-gmg5/GHSA-xffq-295c-gmg5.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-xffq-295c-gmg5",
-  "modified": "2025-05-01T15:31:42Z",
+  "modified": "2025-11-05T17:48:22Z",
   "published": "2025-05-01T15:31:42Z",
   "aliases": [
     "CVE-2025-37744"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix memory leak in ath12k_pci_remove()\n\nKmemleak reported this error:\n\n  unreferenced object 0xffff1c165cec3060 (size 32):\n    comm \"insmod\", pid 560, jiffies 4296964570 (age 235.596s)\n    backtrace:\n      [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0\n      [<000000001203b155>] kmalloc_trace+0x40/0x88\n      [<0000000028adc9c8>] _request_firmware+0xb8/0x608\n      [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80\n      [<000000005011a682>] local_pci_probe+0x48/0xd0\n      [<00000000077cd295>] pci_device_probe+0xb4/0x200\n      [<0000000087184c94>] really_probe+0x150/0x2c0\n\nThe firmware memory was allocated in ath12k_pci_probe(), but not\nfreed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is\nset. So call ath12k_fw_unmap() to free the memory.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1",
-  "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": [
     {
@@ -32,8 +37,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-401"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T13:15:53Z"

advisories/unreviewed/2025/11/GHSA-24q7-hvmv-5rmp/GHSA-24q7-hvmv-5rmp.json

@@ -46,7 +46,8 @@
   ],
   "database_specific": {
     "cwe_ids": [
-      "CWE-74"
+      "CWE-74",
+      "CWE-89"
     ],
     "severity": "MODERATE",
     "github_reviewed": false,

advisories/unreviewed/2025/11/GHSA-2vvf-4m7q-pvpx/GHSA-2vvf-4m7q-pvpx.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2vvf-4m7q-pvpx",
-  "modified": "2025-11-05T15:31:06Z",
+  "modified": "2025-11-05T17:48:28Z",
   "published": "2025-11-05T15:31:05Z",
   "aliases": [
     "CVE-2025-46404"
@@ -22,6 +22,10 @@
     {
       "type": "WEB",
       "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2194"
+    },
+    {
+      "type": "WEB",
+      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2194"
     }
   ],
   "database_specific": {