Advisory Database Sync

2026-05-22 18:04:22 -07:00 · 2025-03-17 18:33:16 +00:00
parent 6b212f717c
commit 6b8f1cf249
154 changed files with 4441 additions and 221 deletions
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-3gxg-hfhr-6g9x",
-  "modified": "2023-03-02T18:30:30Z",
+  "modified": "2025-03-17T18:31:33Z",
  "published": "2023-02-21T18:30:25Z",
  "aliases": [
    "CVE-2023-23009"
@@ -23,6 +23,14 @@
      "type": "WEB",
      "url": "https://github.com/libreswan/libreswan/issues/954"
    },
+    {
+      "type": "WEB",
+      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2MFOIQX2LRL43P3GJT33DE7G7COHNXDN"
+    },
+    {
+      "type": "WEB",
+      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CSMYJH7MC2FZGCY5NH5AXULO3ISXIHOF"
+    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2MFOIQX2LRL43P3GJT33DE7G7COHNXDN"
@@ -1,7 +1,7 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-x83f-9m8f-428q",
-  "modified": "2024-01-29T15:30:24Z",
+  "modified": "2025-03-17T18:31:36Z",
  "published": "2024-01-24T00:30:32Z",
  "aliases": [
    "CVE-2024-0808"
@@ -1,12 +1,12 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-ggv6-7vfj-r2fw",
-  "modified": "2024-10-22T18:32:04Z",
+  "modified": "2025-03-17T18:31:37Z",
  "published": "2024-02-13T21:30:30Z",
  "aliases": [
    "CVE-2023-31347"
  ],
-  "details": "Due to a code bug in\nSecure_TSC, SEV firmware may allow an attacker with high privileges to cause a\nguest to observe an incorrect TSC when Secure TSC is enabled potentially\nresulting in a loss of guest integrity.  \n\n\n\n\n",
+  "details": "Due to a code bug in\nSecure_TSC, SEV firmware may allow an attacker with high privileges to cause a\nguest to observe an incorrect TSC when Secure TSC is enabled potentially\nresulting in a loss of guest integrity.  ",
  "severity": [
    {
      "type": "CVSS_V3",
@@ -25,7 +25,9 @@
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-682"
+    ],
    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
@@ -25,7 +25,9 @@
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-400"
+    ],
    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
@@ -26,7 +26,8 @@
  ],
  "database_specific": {
    "cwe_ids": [
-      "CWE-395"
+      "CWE-395",
+      "CWE-755"
    ],
    "severity": "MODERATE",
    "github_reviewed": false,
@@ -49,7 +49,9 @@
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
+    "cwe_ids": [
+      "CWE-284"
+    ],
    "severity": "HIGH",
    "github_reviewed": false,
    "github_reviewed_at": null,
@@ -26,6 +26,7 @@
  ],
  "database_specific": {
    "cwe_ids": [
+      "CWE-79",
      "CWE-94"
    ],
    "severity": "MODERATE",
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-2vp9-gjfg-fmgw",
-  "modified": "2024-04-04T15:30:33Z",
+  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-03T15:30:43Z",
  "aliases": [
    "CVE-2024-26710"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kasan: Limit KASAN thread size increase to 32KB\n\nKASAN is seen to increase stack usage, to the point that it was reported\nto lead to stack overflow on some 32-bit machines (see link).\n\nTo avoid overflows the stack size was doubled for KASAN builds in\ncommit 3e8635fb2e07 (\"powerpc/kasan: Force thread size increase with\nKASAN\").\n\nHowever with a 32KB stack size to begin with, the doubling leads to a\n64KB stack, which causes build errors:\n  arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff)\n\nAlthough the asm could be reworked, in practice a 32KB stack seems\nsufficient even for KASAN builds - the additional usage seems to be in\nthe 2-3KB range for a 64-bit KASAN build.\n\nSo only increase the stack for KASAN if the stack size is < 32KB.",
-  "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-770"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T15:15:53Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-2vqj-rxh7-chjw",
-  "modified": "2024-06-27T12:30:44Z",
+  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-02T09:30:41Z",
  "aliases": [
    "CVE-2024-26679"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet: read sk->sk_family once in inet_recv_error()\n\ninet_recv_error() is called without holding the socket lock.\n\nIPv6 socket could mutate to IPv4 with IPV6_ADDRFORM\nsocket option and trigger a KCSAN warning.",
-  "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": [
    {
@@ -56,8 +61,10 @@
    }
  ],
  "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-667"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-02T07:15:44Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-37h8-63p8-qhhg",
-  "modified": "2024-04-03T18:30:42Z",
+  "modified": "2025-03-17T18:31:40Z",
  "published": "2024-04-03T18:30:42Z",
  "aliases": [
    "CVE-2024-26740"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_mirred: use the backlog for mirred ingress\n\nThe test Davide added in commit ca22da2fbd69 (\"act_mirred: use the backlog\nfor nested calls to mirred ingress\") hangs our testing VMs every 10 or so\nruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by\nlockdep.\n\nThe problem as previously described by Davide (see Link) is that\nif we reverse flow of traffic with the redirect (egress -> ingress)\nwe may reach the same socket which generated the packet. And we may\nstill be holding its socket lock. The common solution to such deadlocks\nis to put the packet in the Rx backlog, rather than run the Rx path\ninline. Do that for all egress -> ingress reversals, not just once\nwe started to nest mirred calls.\n\nIn the past there was a concern that the backlog indirection will\nlead to loss of error reporting / less accurate stats. But the current\nworkaround does not seem to address the issue.",
-  "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": "2024-04-03T17:15:51Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-3w39-v724-v74w",
-  "modified": "2024-04-03T15:30:42Z",
+  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-03T15:30:42Z",
  "aliases": [
    "CVE-2024-26693"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: fix a crash when we run out of stations\n\nA DoS tool that injects loads of authentication frames made our AP\ncrash. The iwl_mvm_is_dup() function couldn't find the per-queue\ndup_data which was not allocated.\n\nThe root cause for that is that we ran out of stations in the firmware\nand we didn't really add the station to the firmware, yet we didn't\nreturn an error to mac80211.\nMac80211 was thinking that we have the station and because of that,\nsta_info::uploaded was set to 1. This allowed\nieee80211_find_sta_by_ifaddr() to return a valid station object, but\nthat ieee80211_sta didn't have any iwl_mvm_sta object initialized and\nthat caused the crash mentioned earlier when we got Rx on that station.",
-  "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-04-03T15:15:52Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-4fj7-85cf-9m8p",
-  "modified": "2024-04-03T15:30:43Z",
+  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-03T15:30:43Z",
  "aliases": [
    "CVE-2024-26706"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix random data corruption from exception handler\n\nThe current exception handler implementation, which assists when accessing\nuser space memory, may exhibit random data corruption if the compiler decides\nto use a different register than the specified register %r29 (defined in\nASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another\nregister, the fault handler will nevertheless store -EFAULT into %r29 and thus\ntrash whatever this register is used for.\nLooking at the assembly I found that this happens sometimes in emulate_ldd().\n\nTo solve the issue, the easiest solution would be if it somehow is\npossible to tell the fault handler which register is used to hold the error\ncode. Using %0 or %1 in the inline assembly is not posssible as it will show\nup as e.g. %r29 (with the \"%r\" prefix), which the GNU assembler can not\nconvert to an integer.\n\nThis patch takes another, better and more flexible approach:\nWe extend the __ex_table (which is out of the execution path) by one 32-word.\nIn this word we tell the compiler to insert the assembler instruction\n\"or %r0,%r0,%reg\", where %reg references the register which the compiler\nchoosed for the error return code.\nIn case of an access failure, the fault handler finds the __ex_table entry and\ncan examine the opcode. The used register is encoded in the lowest 5 bits, and\nthe fault handler can then store -EFAULT into this register.\n\nSince we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT\nconfig option any longer.",
-  "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-787"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T15:15:53Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-5g26-fc68-x9f2",
-  "modified": "2024-04-28T12:30:27Z",
+  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-02T09:30:41Z",
  "aliases": [
    "CVE-2024-26678"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section\n\nThe .compat section is a dummy PE section that contains the address of\nthe 32-bit entrypoint of the 64-bit kernel image if it is bootable from\n32-bit firmware (i.e., CONFIG_EFI_MIXED=y)\n\nThis section is only 8 bytes in size and is only referenced from the\nloader, and so it is placed at the end of the memory view of the image,\nto avoid the need for padding it to 4k, which is required for sections\nappearing in the middle of the image.\n\nUnfortunately, this violates the PE/COFF spec, and even if most EFI\nloaders will work correctly (including the Tianocore reference\nimplementation), PE loaders do exist that reject such images, on the\nbasis that both the file and memory views of the file contents should be\ndescribed by the section headers in a monotonically increasing manner\nwithout leaving any gaps.\n\nSo reorganize the sections to avoid this issue. This results in a slight\npadding overhead (< 4k) which can be avoided if desired by disabling\nCONFIG_EFI_MIXED (which is only needed in rare cases these days)",
-  "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-787"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-02T07:15:44Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-5qvv-jjxx-82r8",
-  "modified": "2024-10-22T18:32:04Z",
+  "modified": "2025-03-17T18:31:39Z",
  "published": "2024-04-03T15:30:43Z",
  "aliases": [
    "CVE-2024-26718"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-crypt, dm-verity: disable tasklets\n\nTasklets have an inherent problem with memory corruption. The function\ntasklet_action_common calls tasklet_trylock, then it calls the tasklet\ncallback and then it calls tasklet_unlock. If the tasklet callback frees\nthe structure that contains the tasklet or if it calls some code that may\nfree it, tasklet_unlock will write into free memory.\n\nThe commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but\nit is not a sufficient fix and the data corruption can still happen [1].\nThere is no fix for dm-verity and dm-verity will write into free memory\nwith every tasklet-processed bio.\n\nThere will be atomic workqueues implemented in the kernel 6.9 [2]. They\nwill have better interface and they will not suffer from the memory\ncorruption problem.\n\nBut we need something that stops the memory corruption now and that can be\nbackported to the stable kernels. So, I'm proposing this commit that\ndisables tasklets in both dm-crypt and dm-verity. This commit doesn't\nremove the tasklet support, because the tasklet code will be reused when\natomic workqueues will be implemented.\n\n[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/\n[2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/",
-  "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-787"
+    ],
+    "severity": "MODERATE",
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T15:15:53Z"
@@ -1,13 +1,18 @@
 {
  "schema_version": "1.4.0",
  "id": "GHSA-82mq-c3x3-cpp9",
-  "modified": "2024-04-03T15:30:42Z",
+  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-03T15:30:42Z",
  "aliases": [
    "CVE-2023-52639"
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: vsie: fix race during shadow creation\n\nRight now it is possible to see gmap->private being zero in\nkvm_s390_vsie_gmap_notifier resulting in a crash.  This is due to the\nfact that we add gmap->private == kvm after creation:\n\nstatic int acquire_gmap_shadow(struct kvm_vcpu *vcpu,\n                               struct vsie_page *vsie_page)\n{\n[...]\n        gmap = gmap_shadow(vcpu->arch.gmap, asce, edat);\n        if (IS_ERR(gmap))\n                return PTR_ERR(gmap);\n        gmap->private = vcpu->kvm;\n\nLet children inherit the private field of the parent.",
-  "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-04-03T15:15:51Z"
--- a/Show More
+++ b/Show More