Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/12/GHSA-c46j-8p94-c85x/GHSA-c46j-8p94-c85x.json

@@ -54,6 +54,7 @@
   ],
   "database_specific": {
     "cwe_ids": [
+      "CWE-120",
       "CWE-787"
     ],
     "severity": "MODERATE",

advisories/unreviewed/2026/01/GHSA-5vr8-9cf6-r7px/GHSA-5vr8-9cf6-r7px.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5vr8-9cf6-r7px",
-  "modified": "2026-01-13T18:31:11Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-01-13T18:31:11Z",
   "aliases": [
     "CVE-2026-20963"
@@ -22,6 +22,10 @@
     {
       "type": "WEB",
       "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20963"
+    },
+    {
+      "type": "WEB",
+      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-20963"
     }
   ],
   "database_specific": {

advisories/unreviewed/2026/02/GHSA-692f-c3g3-7699/GHSA-692f-c3g3-7699.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-692f-c3g3-7699",
-  "modified": "2026-02-04T18:30:43Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-04T18:30:43Z",
   "aliases": [
     "CVE-2026-23070"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nOcteontx2-af: Add proper checks for fwdata\n\nfirmware populates MAC address, link modes (supported, advertised)\nand EEPROM data in shared firmware structure which kernel access\nvia MAC block(CGX/RPM).\n\nAccessing fwdata, on boards booted with out MAC block leading to\nkernel panics.\n\nInternal error: Oops: 0000000096000005 [#1]  SMP\n[   10.460721] Modules linked in:\n[   10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT\n[   10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)\n[   10.479793] Workqueue: events work_for_cpu_fn\n[   10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   10.491124] pc : rvu_sdp_init+0x18/0x114\n[   10.495051] lr : rvu_probe+0xe58/0x1d18",
-  "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-02-04T17:16:17Z"

advisories/unreviewed/2026/02/GHSA-6qxm-gr5m-j478/GHSA-6qxm-gr5m-j478.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6qxm-gr5m-j478",
-  "modified": "2026-02-06T18:30:31Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-04T18:30:44Z",
   "aliases": [
     "CVE-2026-23098"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: fix double-free in nr_route_frame()\n\nIn nr_route_frame(), old_skb is immediately freed without checking if\nnr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL,\nthe caller function will free old_skb again, causing a double-free bug.\n\nTherefore, to prevent this, we need to modify it to check whether\nnr_neigh->ax25 is NULL before freeing old_skb.",
-  "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-415"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-02-04T17:16:20Z"

advisories/unreviewed/2026/02/GHSA-7cwq-2xv8-7cqw/GHSA-7cwq-2xv8-7cqw.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-7cwq-2xv8-7cqw",
-  "modified": "2026-02-06T18:30:30Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-04T18:30:43Z",
   "aliases": [
     "CVE-2026-23074"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Enforce that teql can only be used as root qdisc\n\nDesign intent of teql is that it is only supposed to be used as root qdisc.\nWe need to check for that constraint.\n\nAlthough not important, I will describe the scenario that unearthed this\nissue for the curious.\n\nGangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows:\n\nROOT qdisc 1:0 (QFQ)\n  ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s\n  └── class 1:2 (weight=1, lmax=1514) teql\n\nGangMin sends a packet which is enqueued to 1:1 (netem).\nAny invocation of dequeue by QFQ from this class will not return a packet\nuntil after 6.4s. In the meantime, a second packet is sent and it lands on\n1:2. teql's enqueue will return success and this will activate class 1:2.\nMain issue is that teql only updates the parent visible qlen (sch->q.qlen)\nat dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's\npeek always returns NULL), dequeue will never be called and thus the qlen\nwill remain as 0. With that in mind, when GangMin updates 1:2's lmax value,\nthe qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's\nqlen was not incremented, qfq fails to deactivate the class, but still\nfrees its pointers from the aggregate. So when the first packet is\nrescheduled after 6.4 seconds (netem's delay), a dangling pointer is\naccessed causing GangMin's causing a UAF.",
-  "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-02-04T17:16:18Z"

advisories/unreviewed/2026/02/GHSA-89j4-f3cq-gm32/GHSA-89j4-f3cq-gm32.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-89j4-f3cq-gm32",
-  "modified": "2026-02-14T18:30:16Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-14T18:30:16Z",
   "aliases": [
     "CVE-2026-23209"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix error recovery in macvlan_common_newlink()\n\nvalis provided a nice repro to crash the kernel:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\n\nip link add mv0 link p2 type macvlan mode source\nip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20\n\nping -c1 -I p1 1.2.3.4\n\nHe also gave a very detailed analysis:\n\n<quote valis>\n\nThe issue is triggered when a new macvlan link is created  with\nMACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or\nMACVLAN_MACADDR_SET) parameter, lower device already has a macvlan\nport and register_netdevice() called from macvlan_common_newlink()\nfails (e.g. because of the invalid link name).\n\nIn this case macvlan_hash_add_source is called from\nmacvlan_change_sources() / macvlan_common_newlink():\n\nThis adds a reference to vlan to the port's vlan_source_hash using\nmacvlan_source_entry.\n\nvlan is a pointer to the priv data of the link that is being created.\n\nWhen register_netdevice() fails, the error is returned from\nmacvlan_newlink() to rtnl_newlink_create():\n\n        if (ops->newlink)\n                err = ops->newlink(dev, &params, extack);\n        else\n                err = register_netdevice(dev);\n        if (err < 0) {\n                free_netdev(dev);\n                goto out;\n        }\n\nand free_netdev() is called, causing a kvfree() on the struct\nnet_device that is still referenced in the source entry attached to\nthe lower device's macvlan port.\n\nNow all packets sent on the macvlan port with a matching source mac\naddress will trigger a use-after-free in macvlan_forward_source().\n\n</quote valis>\n\nWith all that, my fix is to make sure we call macvlan_flush_sources()\nregardless of @create value whenever \"goto destroy_macvlan_port;\"\npath is taken.\n\nMany thanks to valis for following up on this issue.",
-  "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-02-14T17:15:58Z"

advisories/unreviewed/2026/02/GHSA-c5gg-v573-hv7f/GHSA-c5gg-v573-hv7f.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-c5gg-v573-hv7f",
-  "modified": "2026-02-18T15:31:27Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-18T15:31:26Z",
   "aliases": [
     "CVE-2025-71227"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don't WARN for connections on invalid channels\n\nIt's not clear (to me) how exactly syzbot managed to hit this,\nbut it seems conceivable that e.g. regulatory changed and has\ndisabled a channel between scanning (channel is checked to be\nusable by cfg80211_get_ies_channel_number) and connecting on\nthe channel later.\n\nWith one scenario that isn't covered elsewhere described above,\nthe warning isn't good, replace it with a (more informative)\nerror message.",
-  "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-02-18T15:18:40Z"

advisories/unreviewed/2026/02/GHSA-cmv7-4284-j9gc/GHSA-cmv7-4284-j9gc.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-cmv7-4284-j9gc",
-  "modified": "2026-02-06T18:30:31Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-04T18:30:44Z",
   "aliases": [
     "CVE-2026-23099"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: limit BOND_MODE_8023AD to Ethernet devices\n\nBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.\n\nsyzbot reported:\n\n BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\nRead of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497\n\nCPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G             L      syzkaller #0 PREEMPT(full)\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n <TASK>\n  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0xca/0x240 mm/kasan/report.c:482\n  kasan_report+0x118/0x150 mm/kasan/report.c:595\n check_region_inline mm/kasan/generic.c:-1 [inline]\n  kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200\n  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n  __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n  __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\n  __dev_mc_add net/core/dev_addr_lists.c:868 [inline]\n  dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886\n  bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180\n  do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963\n  do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165\n  rtnl_changelink net/core/rtnetlink.c:3776 [inline]\n  __rtnl_newlink net/core/rtnetlink.c:3935 [inline]\n  rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072\n  rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958\n  netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550\n  netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n  netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344\n  netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894\n  sock_sendmsg_nosec net/socket.c:727 [inline]\n  __sock_sendmsg+0x21c/0x270 net/socket.c:742\n  ____sys_sendmsg+0x505/0x820 net/socket.c:2592\n  ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646\n  __sys_sendmsg+0x164/0x220 net/socket.c:2678\n  do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n  __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307\n  do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n </TASK>\n\nThe buggy address belongs to the variable:\n lacpdu_mcast_addr+0x0/0x40",
-  "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": [
     {
@@ -40,8 +45,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-125"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-02-04T17:16:20Z"

advisories/unreviewed/2026/02/GHSA-cw47-5xmh-qvq4/GHSA-cw47-5xmh-qvq4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-cw47-5xmh-qvq4",
-  "modified": "2026-02-06T18:30:30Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-04T18:30:43Z",
   "aliases": [
     "CVE-2026-23073"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rsi: Fix memory corruption due to not set vif driver data size\n\nThe struct ieee80211_vif contains trailing space for vif driver data,\nwhen struct ieee80211_vif is allocated, the total memory size that is\nallocated is sizeof(struct ieee80211_vif) + size of vif driver data.\nThe size of vif driver data is set by each WiFi driver as needed.\n\nThe RSI911x driver does not set vif driver data size, no trailing space\nfor vif driver data is therefore allocated past struct ieee80211_vif .\nThe RSI911x driver does however use the vif driver data to store its\nvif driver data structure \"struct vif_priv\". An access to vif->drv_priv\nleads to access out of struct ieee80211_vif bounds and corruption of\nsome memory.\n\nIn case of the failure observed locally, rsi_mac80211_add_interface()\nwould write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv;\nvif_info->vap_id = vap_idx. This write corrupts struct fq_tin member\nstruct list_head new_flows . The flow = list_first_entry(head, struct\nfq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus\naddress, which when accessed causes a crash.\n\nThe trigger is very simple, boot the machine with init=/bin/sh , mount\ndevtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\",\n\"ip link set wlan0 down\" and the crash occurs.\n\nFix this by setting the correct size of vif driver data, which is the\nsize of \"struct vif_priv\", so that memory is allocated and the driver\ncan store its driver data in it, instead of corrupting memory around\nit.",
-  "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-787"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2026-02-04T17:16:18Z"

advisories/unreviewed/2026/02/GHSA-g5pw-hppv-79r6/GHSA-g5pw-hppv-79r6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-g5pw-hppv-79r6",
-  "modified": "2026-02-18T15:31:27Z",
+  "modified": "2026-03-18T21:32:57Z",
   "published": "2026-02-18T15:31:27Z",
   "aliases": [
     "CVE-2026-23215"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmware: Fix hypercall clobbers\n\nFedora QA reported the following panic:\n\n  BUG: unable to handle page fault for address: 0000000040003e54\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025\n  RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90\n  ..\n  Call Trace:\n   vmmouse_report_events+0x13e/0x1b0\n   psmouse_handle_byte+0x15/0x60\n   ps2_interrupt+0x8a/0xd0\n   ...\n\nbecause the QEMU VMware mouse emulation is buggy, and clears the top 32\nbits of %rdi that the kernel kept a pointer in.\n\nThe QEMU vmmouse driver saves and restores the register state in a\n\"uint32_t data[6];\" and as a result restores the state with the high\nbits all cleared.\n\nRDI originally contained the value of a valid kernel stack address\n(0xff5eeb3240003e54).  After the vmware hypercall it now contains\n0x40003e54, and we get a page fault as a result when it is dereferenced.\n\nThe proper fix would be in QEMU, but this works around the issue in the\nkernel to keep old setups working, when old kernels had not happened to\nkeep any state in %rdi over the hypercall.\n\nIn theory this same issue exists for all the hypercalls in the vmmouse\ndriver; in practice it has only been seen with vmware_hypercall3() and\nvmware_hypercall4().  For now, just mark RDI/RSI as clobbered for those\ntwo calls.  This should have a minimal effect on code generation overall\nas it should be rare for the compiler to want to make RDI/RSI live\nacross hypercalls.",
-  "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-02-18T15:18:42Z"