Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2024/06/GHSA-7pc8-p9cr-qx9p/GHSA-7pc8-p9cr-qx9p.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-7pc8-p9cr-qx9p",
-  "modified": "2024-06-19T15:30:54Z",
+  "modified": "2025-10-31T18:31:09Z",
   "published": "2024-06-19T15:30:54Z",
   "aliases": [
     "CVE-2024-38595"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix peer devlink set for SF representor devlink port\n\nThe cited patch change register devlink flow, and neglect to reflect\nthe changes for peer devlink set logic. Peer devlink set is\ntriggering a call trace if done after devl_register.[1]\n\nHence, align peer devlink set logic with register devlink flow.\n\n[1]\nWARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180\nCPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_08 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nWorkqueue: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core]\nRIP: 0010:devlink_rel_nested_in_add+0x177/0x180\nCall Trace:\n <TASK>\n ? __warn+0x78/0x120\n ? devlink_rel_nested_in_add+0x177/0x180\n ? report_bug+0x16d/0x180\n ? handle_bug+0x3c/0x60\n ? exc_invalid_op+0x14/0x70\n ? asm_exc_invalid_op+0x16/0x20\n ? devlink_port_init+0x30/0x30\n ? devlink_port_type_clear+0x50/0x50\n ? devlink_rel_nested_in_add+0x177/0x180\n ? devlink_rel_nested_in_add+0xdd/0x180\n mlx5_sf_mdev_event+0x74/0xb0 [mlx5_core]\n notifier_call_chain+0x35/0xb0\n blocking_notifier_call_chain+0x3d/0x60\n mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]\n mlx5_sf_dev_probe+0x185/0x3e0 [mlx5_core]\n auxiliary_bus_probe+0x38/0x80\n ? driver_sysfs_add+0x51/0x80\n really_probe+0xc5/0x3a0\n ? driver_probe_device+0x90/0x90\n __driver_probe_device+0x80/0x160\n driver_probe_device+0x1e/0x90\n __device_attach_driver+0x7d/0x100\n bus_for_each_drv+0x80/0xd0\n __device_attach+0xbc/0x1f0\n bus_probe_device+0x86/0xa0\n device_add+0x64f/0x860\n __auxiliary_device_add+0x3b/0xa0\n mlx5_sf_dev_add+0x139/0x330 [mlx5_core]\n mlx5_sf_dev_state_change_handler+0x1e4/0x250 [mlx5_core]\n notifier_call_chain+0x35/0xb0\n blocking_notifier_call_chain+0x3d/0x60\n mlx5_vhca_state_work_handler+0x151/0x200 [mlx5_core]\n process_one_work+0x13f/0x2e0\n worker_thread+0x2bd/0x3c0\n ? rescuer_thread+0x410/0x410\n kthread+0xc4/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x50\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n </TASK>",
-  "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": [
     {
@@ -29,7 +34,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-06-19T14:15:19Z"

advisories/unreviewed/2024/06/GHSA-x5q7-5ch5-5m3v/GHSA-x5q7-5ch5-5m3v.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-x5q7-5ch5-5m3v",
-  "modified": "2024-10-10T12:31:11Z",
+  "modified": "2025-10-31T18:31:09Z",
   "published": "2024-06-19T15:30:54Z",
   "aliases": [
     "CVE-2024-38594"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: move the EST lock to struct stmmac_priv\n\nReinitialize the whole EST structure would also reset the mutex\nlock which is embedded in the EST structure, and then trigger\nthe following warning. To address this, move the lock to struct\nstmmac_priv. We also need to reacquire the mutex lock when doing\nthis initialization.\n\nDEBUG_LOCKS_WARN_ON(lock->magic != lock)\nWARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068\n Modules linked in:\n CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29\n Hardware name: NXP i.MX8MPlus EVK board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __mutex_lock+0xd84/0x1068\n lr : __mutex_lock+0xd84/0x1068\n sp : ffffffc0864e3570\n x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003\n x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac\n x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000\n x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff\n x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000\n x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8\n x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698\n x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001\n x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027\n x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n  __mutex_lock+0xd84/0x1068\n  mutex_lock_nested+0x28/0x34\n  tc_setup_taprio+0x118/0x68c\n  stmmac_setup_tc+0x50/0xf0\n  taprio_change+0x868/0xc9c",
-  "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": "2024-06-19T14:15:19Z"

advisories/unreviewed/2025/03/GHSA-23x3-fcgm-qf4c/GHSA-23x3-fcgm-qf4c.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-23x3-fcgm-qf4c",
-  "modified": "2025-03-06T18:31:11Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:11Z",
   "aliases": [
     "CVE-2024-58077"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback\n\ncommit 1f5664351410 (\"ASoC: lower \"no backend DAIs enabled for ... Port\"\nlog severity\") ignores -EINVAL error message on common soc_pcm_ret().\nIt is used from many functions, ignoring -EINVAL is over-kill.\n\nThe reason why -EINVAL was ignored was it really should only be used\nupon invalid parameters coming from userspace and in that case we don't\nwant to log an error since we do not want to give userspace a way to do\na denial-of-service attack on the syslog / diskspace.\n\nSo don't use soc_pcm_ret() on .prepare callback is better idea.",
-  "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-06T17:15:21Z"

advisories/unreviewed/2025/03/GHSA-448g-f6xx-9xfw/GHSA-448g-f6xx-9xfw.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-448g-f6xx-9xfw",
-  "modified": "2025-03-06T18:31:10Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:10Z",
   "aliases": [
     "CVE-2025-21827"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\n\nThe documentation for usb_driver_claim_interface() says that \"the\ndevice lock\" is needed when the function is called from places other\nthan probe(). This appears to be the lock for the USB interface\ndevice. The Mediatek btusb code gets called via this path:\n\n  Workqueue: hci0 hci_power_on [bluetooth]\n  Call trace:\n   usb_driver_claim_interface\n   btusb_mtk_claim_iso_intf\n   btusb_mtk_setup\n   hci_dev_open_sync\n   hci_power_on\n   process_scheduled_works\n   worker_thread\n   kthread\n\nWith the above call trace the device lock hasn't been claimed. Claim\nit.\n\nWithout this fix, we'd sometimes see the error \"Failed to claim iso\ninterface\". Sometimes we'd even see worse errors, like a NULL pointer\ndereference (where `intf->dev.driver` was NULL) with a trace like:\n\n  Call trace:\n   usb_suspend_both\n   usb_runtime_suspend\n   __rpm_callback\n   rpm_suspend\n   pm_runtime_work\n   process_scheduled_works\n\nBoth errors appear to be fixed with the proper locking.",
-  "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": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-667"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-06T16:15:54Z"

advisories/unreviewed/2025/03/GHSA-cchg-5m9c-jwh9/GHSA-cchg-5m9c-jwh9.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-cchg-5m9c-jwh9",
-  "modified": "2025-07-06T12:30:24Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-27T15:31:10Z",
   "aliases": [
     "CVE-2024-58091"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/fbdev-dma: Add shadow buffering for deferred I/O\n\nDMA areas are not necessarily backed by struct page, so we cannot\nrely on it for deferred I/O. Allocate a shadow buffer for drivers\nthat require deferred I/O and use it as framebuffer memory.\n\nFixes driver errors about being \"Unable to handle kernel NULL pointer\ndereference at virtual address\" or \"Unable to handle kernel paging\nrequest at virtual address\".\n\nThe patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial\nallocation, which creates the DMA-backed buffer object, and a tail\nthat sets up the fbdev data structures. There is a tail function for\ndirect memory mappings and a tail function for deferred I/O with\nthe shadow buffer.\n\nIt is no longer possible to use deferred I/O without shadow buffer.\nIt can be re-added if there exists a reliably test for usable struct\npage in the allocated DMA-backed buffer object.",
-  "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": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-476"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-27T15:15:54Z"

advisories/unreviewed/2025/03/GHSA-f23x-vp93-47jp/GHSA-f23x-vp93-47jp.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-f23x-vp93-47jp",
-  "modified": "2025-03-06T18:31:11Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:11Z",
   "aliases": [
     "CVE-2025-21828"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don't flush non-uploaded STAs\n\nIf STA state is pre-moved to AUTHORIZED (such as in IBSS\nscenarios) and insertion fails, the station is freed.\nIn this case, the driver never knew about the station,\nso trying to flush it is unexpected and may crash.\n\nCheck if the sta was uploaded to the driver before and\nfix this.",
-  "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-03-06T16:15:55Z"

advisories/unreviewed/2025/03/GHSA-f696-7994-47fc/GHSA-f696-7994-47fc.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-f696-7994-47fc",
-  "modified": "2025-03-06T18:31:10Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:10Z",
   "aliases": [
     "CVE-2024-58075"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: tegra - do not transfer req when tegra init fails\n\nThe tegra_cmac_init or tegra_sha_init function may return an error when\nmemory is exhausted. It should not transfer the request when they return\nan error.",
-  "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": [
     {
@@ -29,7 +34,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-06T16:15:54Z"

advisories/unreviewed/2025/03/GHSA-fgjx-56hm-4qrp/GHSA-fgjx-56hm-4qrp.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-fgjx-56hm-4qrp",
-  "modified": "2025-03-13T15:32:54Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:11Z",
   "aliases": [
     "CVE-2024-58079"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix crash during unbind if gpio unit is in use\n\nWe used the wrong device for the device managed functions. We used the\nusb device, when we should be using the interface device.\n\nIf we unbind the driver from the usb interface, the cleanup functions\nare never called. In our case, the IRQ is never disabled.\n\nIf an IRQ is triggered, it will try to access memory sections that are\nalready free, causing an OOPS.\n\nWe cannot use the function devm_request_threaded_irq here. The devm_*\nclean functions may be called after the main structure is released by\nuvc_delete.\n\nLuckily this bug has small impact, as it is only affected by devices\nwith gpio units and the user has to unbind the device, a disconnect will\nnot trigger this error.",
-  "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": [
     {
@@ -41,7 +46,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-06T17:15:21Z"

advisories/unreviewed/2025/03/GHSA-hr43-3hq8-ggg4/GHSA-hr43-3hq8-ggg4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-hr43-3hq8-ggg4",
-  "modified": "2025-03-13T15:32:54Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:12Z",
   "aliases": [
     "CVE-2024-58085"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntomoyo: don't emit warning in tomoyo_write_control()\n\nsyzbot is reporting too large allocation warning at tomoyo_write_control(),\nfor one can write a very very long line without new line character. To fix\nthis warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,\nfor practically a valid line should be always shorter than 32KB where the\n\"too small to fail\" memory-allocation rule applies.\n\nOne might try to write a valid line that is longer than 32KB, but such\nrequest will likely fail with -ENOMEM. Therefore, I feel that separately\nreturning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.\nThere is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.",
-  "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": [
     {
@@ -49,7 +54,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-06T17:15:21Z"

advisories/unreviewed/2025/03/GHSA-p7x2-rhr6-gw9m/GHSA-p7x2-rhr6-gw9m.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-p7x2-rhr6-gw9m",
-  "modified": "2025-03-06T18:31:11Z",
+  "modified": "2025-10-31T18:31:10Z",
   "published": "2025-03-06T18:31:11Z",
   "aliases": [
     "CVE-2024-58082"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: nuvoton: Fix an error check in npcm_video_ece_init()\n\nWhen function of_find_device_by_node() fails, it returns NULL instead of\nan error code. So the corresponding error check logic should be modified\nto check whether the return value is NULL and set the error code to be\nreturned as -ENODEV.",
-  "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": [
     {
@@ -29,7 +34,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-03-06T17:15:21Z"