Advisory Database Sync

Author: advisory-database[bot]

advisories/github-reviewed/2026/03/GHSA-8m2x-3m6q-6w8j/GHSA-8m2x-3m6q-6w8j.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-8m2x-3m6q-6w8j",
-  "modified": "2026-03-24T20:37:08Z",
+  "modified": "2026-03-25T21:31:40Z",
   "published": "2026-03-24T20:37:08Z",
   "aliases": [
     "CVE-2026-33249"
   ],
   "summary": "NATS: Message tracing can be redirected to arbitrary subject",
-  "details": "### Impact\nA valid client which uses message tracing headers can indicate that the trace messages can be sent to an arbitrary valid subject, including those to which the client does not have publish permission.  The payload is a valid trace message and not attacker chosen.\n\n### Patches\nFixed in nats-server 2.12.6 & 2.11.15\n\n### Workarounds\nNone safe to use.",
+  "details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nThe nats-server supports telemetry on messages, using the per-message NATS headers.\n\n### Problem Description\n\nA valid client which uses message tracing headers can indicate that the trace messages can be sent to an arbitrary valid subject, including those to which the client does not have publish permission.\n\nThe payload is a valid trace message and not chosen by the attacker.\n\n### Affected Versions\n\nAny version before v2.12.6 or v2.11.15\n\n### Workarounds\n\nNone.",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -59,6 +59,10 @@
       "type": "WEB",
       "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-8m2x-3m6q-6w8j"
     },
+    {
+      "type": "ADVISORY",
+      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33249"
+    },
     {
       "type": "WEB",
       "url": "https://advisories.nats.io/CVE/secnote-2026-15.txt"
@@ -75,6 +79,6 @@
     "severity": "MODERATE",
     "github_reviewed": true,
     "github_reviewed_at": "2026-03-24T20:37:08Z",
-    "nvd_published_at": null
+    "nvd_published_at": "2026-03-25T21:16:47Z"
   }
 }

advisories/unreviewed/2026/01/GHSA-22c9-2rqw-7g84/GHSA-22c9-2rqw-7g84.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-22c9-2rqw-7g84",
-  "modified": "2026-01-19T15:30:36Z",
+  "modified": "2026-03-25T21:30:21Z",
   "published": "2026-01-13T18:31:05Z",
   "aliases": [
     "CVE-2025-71075"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: aic94xx: fix use-after-free in device removal path\n\nThe asd_pci_remove() function fails to synchronize with pending tasklets\nbefore freeing the asd_ha structure, leading to a potential\nuse-after-free vulnerability.\n\nWhen a device removal is triggered (via hot-unplug or module unload),\nrace condition can occur.\n\nThe fix adds tasklet_kill() before freeing the asd_ha structure,\nensuring all scheduled tasklets complete before cleanup proceeds.",
-  "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": [
     {
@@ -44,8 +49,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-416"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-01-13T16:16:06Z"

advisories/unreviewed/2026/01/GHSA-266h-p8pw-28f4/GHSA-266h-p8pw-28f4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-266h-p8pw-28f4",
-  "modified": "2026-01-31T12:30:11Z",
+  "modified": "2026-03-25T21:30:24Z",
   "published": "2026-01-31T12:30:11Z",
   "aliases": [
     "CVE-2025-71182"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: make j1939_session_activate() fail if device is no longer registered\n\nsyzbot is still reporting\n\n  unregister_netdevice: waiting for vcan0 to become free. Usage count = 2\n\neven after commit 93a27b5891b8 (\"can: j1939: add missing calls in\nNETDEV_UNREGISTER notification handler\") was added. A debug printk() patch\nfound that j1939_session_activate() can succeed even after\nj1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER)\nhas completed.\n\nSince j1939_cancel_active_session() is processed with the session list lock\nheld, checking ndev->reg_state in j1939_session_activate() with the session\nlist lock held can reliably close the race window.",
-  "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": [
     {
@@ -45,7 +50,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-01-31T12:16:03Z"

advisories/unreviewed/2026/01/GHSA-29vw-w4vv-p6rr/GHSA-29vw-w4vv-p6rr.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-29vw-w4vv-p6rr",
-  "modified": "2026-01-19T15:30:36Z",
+  "modified": "2026-03-25T21:30:22Z",
   "published": "2026-01-14T15:33:02Z",
   "aliases": [
     "CVE-2025-71131"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Do not use req->iv after crypto_aead_encrypt\n\nAs soon as crypto_aead_encrypt is called, the underlying request\nmay be freed by an asynchronous completion.  Thus dereferencing\nreq->iv after it returns is invalid.\n\nInstead of checking req->iv against info, create a new variable\nunaligned_info and use it for that purpose 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": [
     {
@@ -45,7 +50,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-01-14T15:16:02Z"

advisories/unreviewed/2026/01/GHSA-2c5j-c82g-5hg6/GHSA-2c5j-c82g-5hg6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2c5j-c82g-5hg6",
-  "modified": "2026-01-14T15:33:02Z",
+  "modified": "2026-03-25T21:30:22Z",
   "published": "2026-01-14T15:33:02Z",
   "aliases": [
     "CVE-2025-71128"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerspan: Initialize options_len before referencing options.\n\nThe struct ip_tunnel_info has a flexible array member named\noptions that is protected by a counted_by(options_len)\nattribute.\n\nThe compiler will use this information to enforce runtime bounds\nchecking deployed by FORTIFY_SOURCE string helpers.\n\nAs laid out in the GCC documentation, the counter must be\ninitialized before the first reference to the flexible array\nmember.\n\nAfter scanning through the files that use struct ip_tunnel_info\nand also refer to options or options_len, it appears the normal\ncase is to use the ip_tunnel_info_opts_set() helper.\n\nSaid helper would initialize options_len properly before copying\ndata into options, however in the GRE ERSPAN code a partial\nupdate is done, preventing the use of the helper function.\n\nBefore this change the handling of ERSPAN traffic in GRE tunnels\nwould cause a kernel panic when the kernel is compiled with\nGCC 15+ and having FORTIFY_SOURCE configured:\n\nmemcpy: detected buffer overflow: 4 byte write of buffer size 0\n\nCall Trace:\n <IRQ>\n __fortify_panic+0xd/0xf\n erspan_rcv.cold+0x68/0x83\n ? ip_route_input_slow+0x816/0x9d0\n gre_rcv+0x1b2/0x1c0\n gre_rcv+0x8e/0x100\n ? raw_v4_input+0x2a0/0x2b0\n ip_protocol_deliver_rcu+0x1ea/0x210\n ip_local_deliver_finish+0x86/0x110\n ip_local_deliver+0x65/0x110\n ? ip_rcv_finish_core+0xd6/0x360\n ip_rcv+0x186/0x1a0\n\nReported-at: https://launchpad.net/bugs/2129580",
-  "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": "2026-01-14T15:16:02Z"

advisories/unreviewed/2026/01/GHSA-2j2j-fmxq-39xm/GHSA-2j2j-fmxq-39xm.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2j2j-fmxq-39xm",
-  "modified": "2026-01-13T18:31:05Z",
+  "modified": "2026-03-25T21:30:20Z",
   "published": "2026-01-13T18:31:05Z",
   "aliases": [
     "CVE-2025-71072"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nshmem: fix recovery on rename failures\n\nmaple_tree insertions can fail if we are seriously short on memory;\nsimple_offset_rename() does not recover well if it runs into that.\nThe same goes for simple_offset_rename_exchange().\n\nMoreover, shmem_whiteout() expects that if it succeeds, the caller will\nprogress to d_move(), i.e. that shmem_rename2() won't fail past the\nsuccessful call of shmem_whiteout().\n\nNot hard to fix, fortunately - mtree_store() can't fail if the index we\nare trying to store into is already present in the tree as a singleton.\n\nFor simple_offset_rename_exchange() that's enough - we just need to be\ncareful about the order of operations.\n\nFor simple_offset_rename() solution is to preinsert the target into the\ntree for new_dir; the rest can be done without any potentially failing\noperations.\n\nThat preinsertion has to be done in shmem_rename2() rather than in\nsimple_offset_rename() itself - otherwise we'd need to deal with the\npossibility of failure after successful shmem_whiteout().",
-  "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": "2026-01-13T16:16:06Z"

advisories/unreviewed/2026/01/GHSA-2mvm-xgm9-r324/GHSA-2mvm-xgm9-r324.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2mvm-xgm9-r324",
-  "modified": "2026-01-25T15:30:27Z",
+  "modified": "2026-03-25T21:30:23Z",
   "published": "2026-01-25T15:30:27Z",
   "aliases": [
     "CVE-2026-23007"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: zero non-PI portion of auto integrity buffer\n\nThe auto-generated integrity buffer for writes needs to be fully\ninitialized before being passed to the underlying block device,\notherwise the uninitialized memory can be read back by userspace or\nanyone with physical access to the storage device. If protection\ninformation is generated, that portion of the integrity buffer is\nalready initialized. The integrity data is also zeroed if PI generation\nis disabled via sysfs or the PI tuple size is 0. However, this misses\nthe case where PI is generated and the PI tuple size is nonzero, but the\nmetadata size is larger than the PI tuple. In this case, the remainder\n(\"opaque\") of the metadata is left uninitialized.\nGeneralize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the\nmetadata is larger than just the PI tuple.",
-  "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-908"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-01-25T15:15:55Z"

advisories/unreviewed/2026/01/GHSA-326g-5c6q-7782/GHSA-326g-5c6q-7782.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-326g-5c6q-7782",
-  "modified": "2026-02-06T18:30:28Z",
+  "modified": "2026-03-25T21:30:23Z",
   "published": "2026-01-25T15:30:27Z",
   "aliases": [
     "CVE-2026-23005"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1\n\nWhen loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in\nresponse to a guest WRMSR, clear XFD-disabled features in the saved (or to\nbe restored) XSTATE_BV to ensure KVM doesn't attempt to load state for\nfeatures that are disabled via the guest's XFD.  Because the kernel\nexecutes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1\nwill cause XRSTOR to #NM and panic the kernel.\n\nE.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   <TASK>\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   switch_fpu_return+0x4a/0xb0\n   kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nThis can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,\nand a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's\ncall to fpu_update_guest_xfd().\n\nand if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:\n\n  ------------[ cut here ]------------\n  WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867\n  Modules linked in: kvm_intel kvm irqbypass\n  CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:exc_device_not_available+0x101/0x110\n  Call Trace:\n   <TASK>\n   asm_exc_device_not_available+0x1a/0x20\n  RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90\n   fpu_swap_kvm_fpstate+0x6b/0x120\n   kvm_load_guest_fpu+0x30/0x80 [kvm]\n   kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]\n   kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]\n   __x64_sys_ioctl+0x8f/0xd0\n   do_syscall_64+0x62/0x940\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n\nThe new behavior is consistent with the AMX architecture.  Per Intel's SDM,\nXSAVE saves XSTATE_BV as '0' for components that are disabled via XFD\n(and non-compacted XSAVE saves the initial configuration of the state\ncomponent):\n\n  If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,\n  the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;\n  instead, it operates as if XINUSE[i] = 0 (and the state component was\n  in its initial state): it saves bit i of XSTATE_BV field of the XSAVE\n  header as 0; in addition, XSAVE saves the initial configuration of the\n  state component (the other instructions do not save state component i).\n\nAlternatively, KVM could always do XRSTOR with XFD=0, e.g. by using\na constant XFD based on the set of enabled features when XSAVEing for\na struct fpu_guest.  However, having XSTATE_BV[i]=1 for XFD-disabled\nfeatures can only happen in the above interrupt case, or in similar\nscenarios involving preemption on preemptible kernels, because\nfpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the\noutgoing FPU state with the current XFD; and that is (on all but the\nfirst WRMSR to XFD) the guest XFD.\n\nTherefore, XFD can only go out of sync with XSTATE_BV in the above\ninterrupt case, or in similar scenarios involving preemption on\npreemptible kernels, and it we can consider it (de facto) part of KVM\nABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.\n\n[Move clea\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": [
     {
@@ -37,7 +42,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-01-25T15:15:55Z"

advisories/unreviewed/2026/01/GHSA-3772-x29g-83r5/GHSA-3772-x29g-83r5.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3772-x29g-83r5",
-  "modified": "2026-01-19T15:30:36Z",
+  "modified": "2026-03-25T21:30:21Z",
   "published": "2026-01-13T18:31:06Z",
   "aliases": [
     "CVE-2025-71083"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: Avoid NULL pointer deref for evicted BOs\n\nIt is possible for a BO to exist that is not currently associated with a\nresource, e.g. because it has been evicted.\n\nWhen devcoredump tries to read the contents of all BOs for dumping, we need\nto expect this as well -- in this case, ENODATA is recorded instead of the\nbuffer contents.",
-  "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": [
     {
@@ -40,8 +45,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-476"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-01-13T16:16:07Z"