Advisory Database Sync

advisories/unreviewed/2023/02/GHSA-35p8-rgfh-rpw2/GHSA-35p8-rgfh-rpw2.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-35p8-rgfh-rpw2",
-  "modified": "2023-03-02T21:30:29Z",
+  "modified": "2025-03-13T21:30:57Z",
   "published": "2023-02-22T06:30:16Z",
   "aliases": [
     "CVE-2023-24107"
@@ -33,7 +33,9 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-94"
+    ],
     "severity": "CRITICAL",
     "github_reviewed": false,
     "github_reviewed_at": null,

advisories/unreviewed/2023/02/GHSA-jmvj-m3cp-jpmf/GHSA-jmvj-m3cp-jpmf.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-jmvj-m3cp-jpmf",
-  "modified": "2023-03-02T21:30:29Z",
+  "modified": "2025-03-13T21:30:57Z",
   "published": "2023-02-22T06:30:16Z",
   "aliases": [
     "CVE-2023-24108"
@@ -33,7 +33,9 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-912"
+    ],
     "severity": "CRITICAL",
     "github_reviewed": false,
     "github_reviewed_at": null,

advisories/unreviewed/2024/02/GHSA-c7q4-q2c5-57q3/GHSA-c7q4-q2c5-57q3.json

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

advisories/unreviewed/2024/02/GHSA-qxvg-pp92-xq57/GHSA-qxvg-pp92-xq57.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-qxvg-pp92-xq57",
-  "modified": "2024-02-21T00:31:31Z",
+  "modified": "2025-03-13T21:30:58Z",
   "published": "2024-02-21T00:31:31Z",
   "aliases": [
     "CVE-2024-25428"
   ],
   "details": "SQL Injection vulnerability in MRCMS v3.1.2 allows attackers to run arbitrary system commands via the status parameter.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -23,7 +28,7 @@
     "cwe_ids": [
       "CWE-89"
     ],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-02-20T22:15:08Z"

advisories/unreviewed/2024/03/GHSA-48qq-74v6-m9rv/GHSA-48qq-74v6-m9rv.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-48qq-74v6-m9rv",
-  "modified": "2024-03-15T21:30:44Z",
+  "modified": "2025-03-13T21:31:00Z",
   "published": "2024-03-15T21:30:44Z",
   "aliases": [
     "CVE-2021-47132"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix sk_forward_memory corruption on retransmission\n\nMPTCP sk_forward_memory handling is a bit special, as such field\nis protected by the msk socket spin_lock, instead of the plain\nsocket lock.\n\nCurrently we have a code path updating such field without handling\nthe relevant lock:\n\n__mptcp_retrans() -> __mptcp_clean_una_wakeup()\n\nSeveral helpers in __mptcp_clean_una_wakeup() will update\nsk_forward_alloc, possibly causing such field corruption, as reported\nby Matthieu.\n\nAddress the issue providing and using a new variant of blamed function\nwhich explicitly acquires the msk spin lock.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/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": "2024-03-15T21:15:07Z"

advisories/unreviewed/2024/03/GHSA-5c7w-v73j-6cr4/GHSA-5c7w-v73j-6cr4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5c7w-v73j-6cr4",
-  "modified": "2024-03-25T12:30:51Z",
+  "modified": "2025-03-13T21:31:01Z",
   "published": "2024-03-25T12:30:51Z",
   "aliases": [
     "CVE-2021-47159"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: fix a crash if ->get_sset_count() fails\n\nIf ds->ops->get_sset_count() fails then it \"count\" is a negative error\ncode such as -EOPNOTSUPP.  Because \"i\" is an unsigned int, the negative\nerror code is type promoted to a very high value and the loop will\ncorrupt memory until the system crashes.\n\nFix this by checking for error codes and changing the type of \"i\" to\njust int.",
-  "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": [
     {
@@ -36,8 +41,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-835"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-25T10:15:08Z"

advisories/unreviewed/2024/03/GHSA-63cm-3458-95cr/GHSA-63cm-3458-95cr.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-63cm-3458-95cr",
-  "modified": "2024-03-25T12:30:51Z",
+  "modified": "2025-03-13T21:31:02Z",
   "published": "2024-03-25T12:30:51Z",
   "aliases": [
     "CVE-2021-47163"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: wait and exit until all work queues are done\n\nOn some host, a crash could be triggered simply by repeating these\ncommands several times:\n\n  # modprobe tipc\n  # tipc bearer enable media udp name UDP1 localip 127.0.0.1\n  # rmmod tipc\n\n  [] BUG: unable to handle kernel paging request at ffffffffc096bb00\n  [] Workqueue: events 0xffffffffc096bb00\n  [] Call Trace:\n  []  ? process_one_work+0x1a7/0x360\n  []  ? worker_thread+0x30/0x390\n  []  ? create_worker+0x1a0/0x1a0\n  []  ? kthread+0x116/0x130\n  []  ? kthread_flush_work_fn+0x10/0x10\n  []  ? ret_from_fork+0x35/0x40\n\nWhen removing the TIPC module, the UDP tunnel sock will be delayed to\nrelease in a work queue as sock_release() can't be done in rtnl_lock().\nIf the work queue is schedule to run after the TIPC module is removed,\nkernel will crash as the work queue function cleanup_beareri() code no\nlonger exists when trying to invoke it.\n\nTo fix it, this patch introduce a member wq_count in tipc_net to track\nthe numbers of work queues in schedule, and  wait and exit until all\nwork queues are done in tipc_exit_net().",
-  "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": "2024-03-25T10:15:08Z"

advisories/unreviewed/2024/03/GHSA-78f3-c7qw-mjg4/GHSA-78f3-c7qw-mjg4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-78f3-c7qw-mjg4",
-  "modified": "2024-03-29T15:30:30Z",
+  "modified": "2025-03-13T21:31:03Z",
   "published": "2024-03-29T15:30:30Z",
   "aliases": [
     "CVE-2024-30628"
   ],
   "details": "Tenda FH1205 v2.0.0.7(775) has a stack overflow vulnerability in the page parameter from fromAddressNat function.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -23,7 +28,7 @@
     "cwe_ids": [
       "CWE-120"
     ],
-    "severity": null,
+    "severity": "CRITICAL",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-29T13:15:16Z"

advisories/unreviewed/2024/03/GHSA-79wp-fmwh-x929/GHSA-79wp-fmwh-x929.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-79wp-fmwh-x929",
-  "modified": "2024-06-27T12:30:44Z",
+  "modified": "2025-03-13T21:31:00Z",
   "published": "2024-03-21T12:31:56Z",
   "aliases": [
     "CVE-2024-26642"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: disallow anonymous set with timeout flag\n\nAnonymous sets are never used with timeout from userspace, reject this.\nException to this rule is NFT_SET_EVAL to ensure legacy meters still work.",
-  "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": [
     {
@@ -57,7 +62,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-21T11:15:28Z"

advisories/unreviewed/2024/03/GHSA-8h7v-x635-x447/GHSA-8h7v-x635-x447.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-8h7v-x635-x447",
-  "modified": "2024-03-13T18:31:34Z",
+  "modified": "2025-03-13T21:30:59Z",
   "published": "2024-03-13T18:31:34Z",
   "aliases": [
     "CVE-2024-26630"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: cachestat: fix folio read-after-free in cache walk\n\nIn cachestat, we access the folio from the page cache's xarray to compute\nits page offset, and check for its dirty and writeback flags.  However, we\ndo not hold a reference to the folio before performing these actions,\nwhich means the folio can concurrently be released and reused as another\nfolio/page/slab.\n\nGet around this altogether by just using xarray's existing machinery for\nthe folio page offsets and dirty/writeback states.\n\nThis changes behavior for tmpfs files to now always report zeroes in their\ndirty and writeback counters.  This is okay as tmpfs doesn't follow\nconventional writeback cache behavior: its pages get \"cleaned\" during\nswapout, after which they're no longer resident etc.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-416"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-13T16:15:30Z"

advisories/unreviewed/2024/03/GHSA-9r37-jj74-qvw9/GHSA-9r37-jj74-qvw9.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-9r37-jj74-qvw9",
-  "modified": "2024-03-25T12:30:51Z",
+  "modified": "2025-03-13T21:31:02Z",
   "published": "2024-03-25T12:30:51Z",
   "aliases": [
     "CVE-2021-47160"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mt7530: fix VLAN traffic leaks\n\nPCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but\nwas not reset when it is disabled, which may cause traffic leaks:\n\n\tip link add br0 type bridge vlan_filtering 1\n\tip link add br1 type bridge vlan_filtering 1\n\tip link set swp0 master br0\n\tip link set swp1 master br1\n\tip link set br0 type bridge vlan_filtering 0\n\tip link set br1 type bridge vlan_filtering 0\n\t# traffic in br0 and br1 will start leaking to each other\n\nAs port_bridge_{add,del} have set up PCR_MATRIX properly, remove the\nPCR_MATRIX write from mt7530_port_set_vlan_aware.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -37,7 +42,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-25T10:15:08Z"

advisories/unreviewed/2024/03/GHSA-9r82-f7g4-qf37/GHSA-9r82-f7g4-qf37.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-9r82-f7g4-qf37",
-  "modified": "2024-03-15T21:30:44Z",
+  "modified": "2025-03-13T21:31:00Z",
   "published": "2024-03-15T21:30:44Z",
   "aliases": [
     "CVE-2021-47124"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix link timeout refs\n\nWARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28\nRIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28\nCall Trace:\n __refcount_sub_and_test include/linux/refcount.h:283 [inline]\n __refcount_dec_and_test include/linux/refcount.h:315 [inline]\n refcount_dec_and_test include/linux/refcount.h:333 [inline]\n io_put_req fs/io_uring.c:2140 [inline]\n io_queue_linked_timeout fs/io_uring.c:6300 [inline]\n __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354\n io_submit_sqe fs/io_uring.c:6534 [inline]\n io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660\n __do_sys_io_uring_enter fs/io_uring.c:9240 [inline]\n __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182\n\nio_link_timeout_fn() should put only one reference of the linked timeout\nrequest, however in case of racing with the master request's completion\nfirst io_req_complete() puts one and then io_put_req_deferred() is\ncalled.",
-  "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": "2024-03-15T21:15:07Z"

advisories/unreviewed/2024/03/GHSA-ffg6-3wfr-47xc/GHSA-ffg6-3wfr-47xc.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-ffg6-3wfr-47xc",
-  "modified": "2024-03-25T09:32:35Z",
+  "modified": "2025-03-13T21:31:01Z",
   "published": "2024-03-25T09:32:35Z",
   "aliases": [
     "CVE-2021-47152"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix data stream corruption\n\nMaxim reported several issues when forcing a TCP transparent proxy\nto use the MPTCP protocol for the inbound connections. He also\nprovided a clean reproducer.\n\nThe problem boils down to 'mptcp_frag_can_collapse_to()' assuming\nthat only MPTCP will use the given page_frag.\n\nIf others - e.g. the plain TCP protocol - allocate page fragments,\nwe can end-up re-using already allocated memory for mptcp_data_frag.\n\nFix the issue ensuring that the to-be-expanded data fragment is\nlocated at the current page frag end.\n\nv1 -> v2:\n - added missing fixes tag (Mat)",
-  "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-787"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-25T09:15:09Z"

advisories/unreviewed/2024/03/GHSA-fq4q-x842-fmrh/GHSA-fq4q-x842-fmrh.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-fq4q-x842-fmrh",
-  "modified": "2024-03-15T21:30:43Z",
+  "modified": "2025-03-13T21:31:00Z",
   "published": "2024-03-15T21:30:43Z",
   "aliases": [
     "CVE-2021-47112"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kvm: Teardown PV features on boot CPU as well\n\nVarious PV features (Async PF, PV EOI, steal time) work through memory\nshared with hypervisor and when we restore from hibernation we must\nproperly teardown all these features to make sure hypervisor doesn't\nwrite to stale locations after we jump to the previously hibernated kernel\n(which can try to place anything there). For secondary CPUs the job is\nalready done by kvm_cpu_down_prepare(), register syscore ops to do\nthe same for boot 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": "2024-03-15T21:15:06Z"

advisories/unreviewed/2024/03/GHSA-fxx6-99pg-x743/GHSA-fxx6-99pg-x743.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-fxx6-99pg-x743",
-  "modified": "2024-03-25T09:32:35Z",
+  "modified": "2025-03-13T21:31:01Z",
   "published": "2024-03-25T09:32:35Z",
   "aliases": [
     "CVE-2021-47143"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: remove device from smcd_dev_list after failed device_add()\n\nIf the device_add() for a smcd_dev fails, there's no cleanup step that\nrolls back the earlier list_add(). The device subsequently gets freed,\nand we end up with a corrupted list.\n\nAdd some error handling that removes the device from the 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": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-459"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-25T09:15:08Z"

advisories/unreviewed/2024/03/GHSA-g4rp-89x9-87mq/GHSA-g4rp-89x9-87mq.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-g4rp-89x9-87mq",
-  "modified": "2024-03-15T21:30:43Z",
+  "modified": "2025-03-13T21:31:00Z",
   "published": "2024-03-15T21:30:43Z",
   "aliases": [
     "CVE-2021-47113"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: abort in rename_exchange if we fail to insert the second ref\n\nError injection stress uncovered a problem where we'd leave a dangling\ninode ref if we failed during a rename_exchange.  This happens because\nwe insert the inode ref for one side of the rename, and then for the\nother side.  If this second inode ref insert fails we'll leave the first\none dangling and leave a corrupt file system behind.  Fix this by\naborting if we did the insert for the first inode ref.",
-  "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-416"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2024-03-15T21:15:06Z"