Advisory Database Sync

2026-05-22 18:04:22 -07:00 · 2024-12-10 00:32:35 +00:00
parent 6616557514
commit 72fa2ea274
34 changed files with 561 additions and 47 deletions
@@ -30,7 +30,8 @@
  ],
  "database_specific": {
    "cwe_ids": [
-      "CWE-122"
+      "CWE-122",
+      "CWE-787"
    ],
    "severity": "CRITICAL",
    "github_reviewed": false,
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-rmqc-8468-5wx2",
-  "modified": "2024-02-15T06:31:35Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-02-15T06:31:35Z",
  "aliases": [
    "CVE-2022-23087"
  ],
  "details": "The e1000 network adapters permit a variety of modifications to an Ethernet packet when it is being transmitted.  These include the insertion of IP and TCP checksums, insertion of an Ethernet VLAN header, and TCP segmentation offload (\"TSO\").  The e1000 device model uses an on-stack buffer to generate the modified packet header when simulating these modifications on transmitted packets.\n\nWhen checksum offload is requested for a transmitted packet, the e1000 device model used a guest-provided value to specify the checksum offset in the on-stack buffer.  The offset was not validated for certain packet types.\n\nA misbehaving bhyve guest could overwrite memory in the bhyve process on the host, possibly leading to code execution in the host context.\n\nThe bhyve process runs in a Capsicum sandbox, which (depending on the FreeBSD version and bhyve configuration) limits the impact of exploiting this issue.",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
+    }
+  ],
  "affected": [],
  "references": [
    {
@@ -17,11 +22,17 @@
    {
      "type": "WEB",
      "url": "https://security.freebsd.org/advisories/FreeBSD-SA-22:05.bhyve.asc"
+    },
+    {
+      "type": "WEB",
+      "url": "https://security.netapp.com/advisory/ntap-20240415-0005"
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-787"
+    ],
+    "severity": "HIGH",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-15T05:15:09Z"
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-774r-q974-38m9",
-  "modified": "2024-05-16T06:30:49Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T06:30:49Z",
  "aliases": [
    "CVE-2024-4929"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-8pwq-h6xq-q459",
-  "modified": "2024-05-16T06:30:50Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T06:30:50Z",
  "aliases": [
    "CVE-2024-4933"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-fcgh-hm5r-m53h",
-  "modified": "2024-05-16T03:30:45Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T03:30:45Z",
  "aliases": [
    "CVE-2024-4927"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-fwm3-jv2w-cqfq",
-  "modified": "2024-05-16T06:30:50Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T06:30:50Z",
  "aliases": [
    "CVE-2024-4931"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-h6hw-6pc7-77rf",
-  "modified": "2024-05-16T03:30:45Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T03:30:45Z",
  "aliases": [
    "CVE-2024-4928"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-vfqm-877m-9vwv",
-  "modified": "2024-05-16T06:30:50Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T06:30:50Z",
  "aliases": [
    "CVE-2024-4932"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-vgwr-cx5h-w5c3",
-  "modified": "2024-05-16T06:30:50Z",
+  "modified": "2024-12-10T00:31:25Z",
  "published": "2024-05-16T06:30:49Z",
  "aliases": [
    "CVE-2024-4930"
@@ -11,6 +11,10 @@
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
+    },
+    {
+      "type": "CVSS_V4",
+      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
    }
  ],
  "affected": [],
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-8h4c-r25h-3p7f",
-  "modified": "2024-07-30T09:32:03Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-07-30T09:32:03Z",
  "aliases": [
    "CVE-2024-42151"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable\n\nTest case dummy_st_ops/dummy_init_ret_value passes NULL as the first\nparameter of the test_1() function. Mark this parameter as nullable to\nmake verifier aware of such possibility.\nOtherwise, NULL check in the test_1() code:\n\n      SEC(\"struct_ops/test_1\")\n      int BPF_PROG(test_1, struct bpf_dummy_ops_state *state)\n      {\n            if (!state)\n                    return ...;\n\n            ... access state ...\n      }\n\nMight be removed by verifier, thus triggering NULL pointer dereference\nunder certain conditions.",
-  "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-476"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-30T08:15:06Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-hpc7-8m94-wf37",
-  "modified": "2024-07-30T09:32:03Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-07-30T09:32:02Z",
  "aliases": [
    "CVE-2024-42150"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: txgbe: remove separate irq request for MSI and INTx\n\nWhen using MSI or INTx interrupts, request_irq() for pdev->irq will\nconflict with request_threaded_irq() for txgbe->misc.irq, to cause\nsystem crash. So remove txgbe_request_irq() for MSI/INTx case, and\nrename txgbe_request_msix_irqs() since it only request for queue irqs.\n\nAdd wx->misc_irq_domain to determine whether the driver creates an IRQ\ndomain and threaded request the IRQs.",
-  "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": "2024-07-30T08:15:06Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-xggq-vrr8-pfwp",
-  "modified": "2024-07-30T09:32:03Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-07-30T09:32:02Z",
  "aliases": [
    "CVE-2024-42149"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: don't misleadingly warn during thaw operations\n\nThe block device may have been frozen before it was claimed by a\nfilesystem. Concurrently another process might try to mount that\nfrozen block device and has temporarily claimed the block device for\nthat purpose causing a concurrent fs_bdev_thaw() to end up here. The\nmounter is already about to abort mounting because they still saw an\nelevanted bdev->bd_fsfreeze_count so get_bdev_super() will return\nNULL in that case.\n\nFor example, P1 calls dm_suspend() which calls into bdev_freeze() before\nthe block device has been claimed by the filesystem. This brings\nbdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is\nrequired.\n\nNow P2 tries to mount that frozen block device. It claims it and checks\nbdev->bd_fsfreeze_count. As it's elevated it aborts mounting.\n\nIn the meantime P3 called dm_resume(). P3 sees that the block device is\nalready claimed by a filesystem and calls into fs_bdev_thaw().\n\nP3 takes a passive reference and realizes that the filesystem isn't\nready yet. P3 puts itself to sleep to wait for the filesystem to become\nready.\n\nP2 now puts the last active reference to the filesystem and marks it as\ndying. P3 gets woken, sees that the filesystem is dying and\nget_bdev_super() fails.",
-  "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-476"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-30T08:15:06Z"
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-5mmf-rjpr-m4cj",
-  "modified": "2024-11-14T18:30:34Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-11-11T15:31:02Z",
  "aliases": [
    "CVE-2024-50263"
@@ -26,6 +26,10 @@
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/985da552a98e27096444508ce5d853244019111f"
+    },
+    {
+      "type": "WEB",
+      "url": "https://project-zero.issues.chromium.org/issues/373391951"
    }
  ],
  "database_specific": {
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-68xx-p949-f9wp",
-  "modified": "2024-11-08T06:30:48Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-11-08T06:30:48Z",
  "aliases": [
    "CVE-2024-50186"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: explicitly clear the sk pointer, when pf->create fails\n\nWe have recently noticed the exact same KASAN splat as in commit\n6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket\ncreation fails\"). The problem is that commit did not fully address the\nproblem, as some pf->create implementations do not use sk_common_release\nin their error paths.\n\nFor example, we can use the same reproducer as in the above commit, but\nchanging ping to arping. arping uses AF_PACKET socket and if packet_create\nfails, it will just sk_free the allocated sk object.\n\nWhile we could chase all the pf->create implementations and make sure they\nNULL the freed sk object on error from the socket, we can't guarantee\nfuture protocols will not make the same mistake.\n\nSo it is easier to just explicitly NULL the sk pointer upon return from\npf->create in __sock_create. We do know that pf->create always releases the\nallocated sk object on error, so if the pointer is not NULL, it is\ndefinitely dangling.",
-  "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": "2024-11-08T06:15:15Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-c9qp-272q-mvf9",
-  "modified": "2024-11-08T18:30:50Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-11-08T06:30:48Z",
  "aliases": [
    "CVE-2024-50184"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_pmem: Check device status before requesting flush\n\nIf a pmem device is in a bad status, the driver side could wait for\nhost ack forever in virtio_pmem_flush(), causing the system to hang.\n\nSo add a status check in the beginning of virtio_pmem_flush() to return\nearly if the device is not activated.",
-  "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": [
    {
@@ -44,8 +49,10 @@
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-754"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-08T06:15:15Z"
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-cx44-8c8j-5rr2",
-  "modified": "2024-11-09T12:30:47Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-11-09T12:30:47Z",
  "aliases": [
    "CVE-2024-50220"
@@ -21,6 +21,10 @@
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b"
+    },
+    {
+      "type": "WEB",
+      "url": "https://project-zero.issues.chromium.org/issues/373391951"
    }
  ],
  "database_specific": {
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-jhcx-6vfx-gpqr",
-  "modified": "2024-11-08T06:30:48Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-11-08T06:30:48Z",
  "aliases": [
    "CVE-2024-50183"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance\n\nDeleting an NPIV instance requires all fabric ndlps to be released before\nan NPIV's resources can be torn down.  Failure to release fabric ndlps\nbeforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID\nto complete synchronously with usage of wait_queue.",
-  "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": [
    {
@@ -32,8 +37,10 @@
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-08T06:15:15Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-q7m5-gh3m-8v66",
-  "modified": "2024-11-08T06:30:48Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-11-08T06:30:48Z",
  "aliases": [
    "CVE-2024-50185"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: handle consistently DSS corruption\n\nBugged peer implementation can send corrupted DSS options, consistently\nhitting a few warning in the data path. Use DEBUG_NET assertions, to\navoid the splat on some builds and handle consistently the error, dumping\nrelated MIBs and performing fallback and/or reset according to the\nsubflow type.",
-  "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": "2024-11-08T06:15:15Z"
@@ -1,13 +1,17 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-39rf-q9wg-hfr6",
-  "modified": "2024-12-05T18:31:03Z",
+  "modified": "2024-12-10T00:31:26Z",
  "published": "2024-12-05T18:31:03Z",
  "aliases": [
    "CVE-2024-12130"
  ],
  "details": "An “out of bounds read” code execution vulnerability exists in the Rockwell Automation Arena®\n\n that could allow a threat actor to craft a DOE file and force the software to read beyond the boundaries of an allocated memory. If exploited, a threat actor could leverage this vulnerability to execute arbitrary code. To exploit this vulnerability, a legitimate user must execute the malicious code crafted by the threat actor.",
  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
+    },
    {
      "type": "CVSS_V4",
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"
--- a/Show More
+++ b/Show More