Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/07/GHSA-fm6w-39g9-r4vh/GHSA-fm6w-39g9-r4vh.json

@@ -38,7 +38,8 @@
   ],
   "database_specific": {
     "cwe_ids": [
-      "CWE-311"
+      "CWE-311",
+      "CWE-326"
     ],
     "severity": "HIGH",
     "github_reviewed": false,

advisories/unreviewed/2025/07/GHSA-pcww-rhxj-j3mj/GHSA-pcww-rhxj-j3mj.json

@@ -38,7 +38,8 @@
   ],
   "database_specific": {
     "cwe_ids": [
-      "CWE-269"
+      "CWE-269",
+      "CWE-312"
     ],
     "severity": "MODERATE",
     "github_reviewed": false,

advisories/unreviewed/2025/09/GHSA-4cpm-89f2-8grm/GHSA-4cpm-89f2-8grm.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-4cpm-89f2-8grm",
-  "modified": "2025-10-10T18:31:18Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-15T15:31:21Z",
   "aliases": [
     "CVE-2022-50240"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF of alloc->vma in race with munmap()\n\nIn commit 720c24192404 (\"ANDROID: binder: change down_write to\ndown_read\") binder assumed the mmap read lock is sufficient to protect\nalloc->vma inside binder_update_page_range(). This used to be accurate\nuntil commit dd2283f2605e (\"mm: mmap: zap pages with read mmap_sem in\nmunmap\"), which now downgrades the mmap_lock after detaching the vma\nfrom the rbtree in munmap(). Then it proceeds to teardown and free the\nvma with only the read lock held.\n\nThis means that accesses to alloc->vma in binder_update_page_range() now\nwill race with vm_area_free() in munmap() and can cause a UAF as shown\nin the following KASAN trace:\n\n  ==================================================================\n  BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0\n  Read of size 8 at addr ffff16204ad00600 by task server/558\n\n  CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   dump_backtrace+0x0/0x2a0\n   show_stack+0x18/0x2c\n   dump_stack+0xf8/0x164\n   print_address_description.constprop.0+0x9c/0x538\n   kasan_report+0x120/0x200\n   __asan_load8+0xa0/0xc4\n   vm_insert_page+0x7c/0x1f0\n   binder_update_page_range+0x278/0x50c\n   binder_alloc_new_buf+0x3f0/0xba0\n   binder_transaction+0x64c/0x3040\n   binder_thread_write+0x924/0x2020\n   binder_ioctl+0x1610/0x2e5c\n   __arm64_sys_ioctl+0xd4/0x120\n   el0_svc_common.constprop.0+0xac/0x270\n   do_el0_svc+0x38/0xa0\n   el0_svc+0x1c/0x2c\n   el0_sync_handler+0xe8/0x114\n   el0_sync+0x180/0x1c0\n\n  Allocated by task 559:\n   kasan_save_stack+0x38/0x6c\n   __kasan_kmalloc.constprop.0+0xe4/0xf0\n   kasan_slab_alloc+0x18/0x2c\n   kmem_cache_alloc+0x1b0/0x2d0\n   vm_area_alloc+0x28/0x94\n   mmap_region+0x378/0x920\n   do_mmap+0x3f0/0x600\n   vm_mmap_pgoff+0x150/0x17c\n   ksys_mmap_pgoff+0x284/0x2dc\n   __arm64_sys_mmap+0x84/0xa4\n   el0_svc_common.constprop.0+0xac/0x270\n   do_el0_svc+0x38/0xa0\n   el0_svc+0x1c/0x2c\n   el0_sync_handler+0xe8/0x114\n   el0_sync+0x180/0x1c0\n\n  Freed by task 560:\n   kasan_save_stack+0x38/0x6c\n   kasan_set_track+0x28/0x40\n   kasan_set_free_info+0x24/0x4c\n   __kasan_slab_free+0x100/0x164\n   kasan_slab_free+0x14/0x20\n   kmem_cache_free+0xc4/0x34c\n   vm_area_free+0x1c/0x2c\n   remove_vma+0x7c/0x94\n   __do_munmap+0x358/0x710\n   __vm_munmap+0xbc/0x130\n   __arm64_sys_munmap+0x4c/0x64\n   el0_svc_common.constprop.0+0xac/0x270\n   do_el0_svc+0x38/0xa0\n   el0_svc+0x1c/0x2c\n   el0_sync_handler+0xe8/0x114\n   el0_sync+0x180/0x1c0\n\n  [...]\n  ==================================================================\n\nTo prevent the race above, revert back to taking the mmap write lock\ninside binder_update_page_range(). One might expect an increase of mmap\nlock contention. However, binder already serializes these calls via top\nlevel alloc->mutex. Also, there was no performance impact shown when\nrunning the binder benchmark tests.\n\nNote this patch is specific to stable branches 5.4 and 5.10. Since in\nnewer kernel releases binder no longer caches a pointer to the vma.\nInstead, it has been refactored to use vma_lookup() which avoids the\nissue described here. This switch was introduced in commit a43cfc87caaf\n(\"android: binder: stop saving a pointer to the VMA\").",
-  "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": [
     {
@@ -40,8 +45,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-416"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:34Z"

advisories/unreviewed/2025/09/GHSA-gvp8-gmj5-m6g2/GHSA-gvp8-gmj5-m6g2.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-gvp8-gmj5-m6g2",
-  "modified": "2025-09-15T15:31:21Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-15T15:31:21Z",
   "aliases": [
     "CVE-2022-50239"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: qcom: fix writes in read-only memory region\n\nThis commit fixes a kernel oops because of a write in some read-only memory:\n\n\t[    9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8\n\t..snip..\n\t[    9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP\n\t..snip..\n\t[    9.269161] Call trace:\n\t[    9.276271]  __memcpy+0x5c/0x230\n\t[    9.278531]  snprintf+0x58/0x80\n\t[    9.282002]  qcom_cpufreq_msm8939_name_version+0xb4/0x190\n\t[    9.284869]  qcom_cpufreq_probe+0xc8/0x39c\n\t..snip..\n\nThe following line defines a pointer that point to a char buffer stored\nin read-only memory:\n\n\tchar *pvs_name = \"speedXX-pvsXX-vXX\";\n\nThis pointer is meant to hold a template \"speedXX-pvsXX-vXX\" where the\nXX values get overridden by the qcom_cpufreq_krait_name_version function. Since\nthe template is actually stored in read-only memory, when the function\nexecutes the following call we get an oops:\n\n\tsnprintf(*pvs_name, sizeof(\"speedXX-pvsXX-vXX\"), \"speed%d-pvs%d-v%d\",\n\t\t speed, pvs, pvs_ver);\n\nTo fix this issue, we instead store the template name onto the stack by\nusing the following syntax:\n\n\tchar pvs_name_buffer[] = \"speedXX-pvsXX-vXX\";\n\nBecause the `pvs_name` needs to be able to be assigned to NULL, the\ntemplate buffer is stored in the pvs_name_buffer and not under the\npvs_name variable.",
-  "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": [
     {
@@ -32,8 +37,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-125"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:34Z"

advisories/unreviewed/2025/09/GHSA-hvpg-7hj3-vfp4/GHSA-hvpg-7hj3-vfp4.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-hvpg-7hj3-vfp4",
-  "modified": "2025-09-15T15:31:21Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-15T15:31:21Z",
   "aliases": [
     "CVE-2025-39804"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts\n\nRestore the SIMD usability check that was removed by commit a59e5468a921\n(\"crypto: arm64/poly1305 - Add block-only interface\").\n\nThis safety check is cheap and is well worth eliminating a footgun.\nWhile the Poly1305 functions should not be called when SIMD registers\nare unusable, if they are anyway, they should just do the right thing\ninstead of corrupting random tasks' registers and/or computing incorrect\nMACs.  Fixing this is also needed for poly1305_kunit to pass.\n\nJust use may_use_simd() instead of the original crypto_simd_usable(),\nsince poly1305_kunit won't rely on crypto_simd_disabled_for_test.",
-  "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": [
     {
@@ -25,7 +30,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T13:15:35Z"

advisories/unreviewed/2025/09/GHSA-m9fv-443w-2xhw/GHSA-m9fv-443w-2xhw.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-m9fv-443w-2xhw",
-  "modified": "2025-09-15T15:31:21Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-15T15:31:21Z",
   "aliases": [
     "CVE-2022-50235"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Protect against send buffer overflow in NFSv2 READDIR\n\nRestore the previous limit on the @count argument to prevent a\nbuffer overflow attack.",
-  "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-787"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:33Z"

advisories/unreviewed/2025/09/GHSA-mj99-x9w6-h3m8/GHSA-mj99-x9w6-h3m8.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-mj99-x9w6-h3m8",
-  "modified": "2025-09-15T15:31:21Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-15T15:31:21Z",
   "aliases": [
     "CVE-2022-50236"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: Fix crash on isr after kexec()\n\nIf the system is rebooted via isr(), the IRQ handler might\nbe triggered before the domain is initialized. Resulting on\nan invalid memory access error.\n\nFix:\n[    0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070\n[    0.501166] Call trace:\n[    0.501174]  report_iommu_fault+0x28/0xfc\n[    0.501180]  mtk_iommu_isr+0x10c/0x1c0\n\n[ joro: Fixed spelling in commit 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": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-908"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:34Z"

advisories/unreviewed/2025/09/GHSA-p94f-8hph-rvrp/GHSA-p94f-8hph-rvrp.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-p94f-8hph-rvrp",
-  "modified": "2025-09-12T18:31:10Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-12T18:31:10Z",
   "aliases": [
     "CVE-2025-39797"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Duplicate SPI Handling\n\nThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI\nNetlink message, which triggers the kernel function xfrm_alloc_spi().\nThis function is expected to ensure uniqueness of the Security Parameter\nIndex (SPI) for inbound Security Associations (SAs). However, it can\nreturn success even when the requested SPI is already in use, leading\nto duplicate SPIs assigned to multiple inbound SAs, differentiated\nonly by their destination addresses.\n\nThis behavior causes inconsistencies during SPI lookups for inbound packets.\nSince the lookup may return an arbitrary SA among those with the same SPI,\npacket processing can fail, resulting in packet drops.\n\nAccording to RFC 4301 section 4.4.2 , for inbound processing a unicast SA\nis uniquely identified by the SPI and optionally protocol.\n\nReproducing the Issue Reliably:\nTo consistently reproduce the problem, restrict the available SPI range in\ncharon.conf : spi_min = 0x10000000 spi_max = 0x10000002\nThis limits the system to only 2 usable SPI values.\nNext, create more than 2 Child SA. each using unique pair of src/dst address.\nAs soon as the 3rd Child SA is initiated, it will be assigned a duplicate\nSPI, since the SPI pool is already exhausted.\nWith a narrow SPI range, the issue is consistently reproducible.\nWith a broader/default range, it becomes rare and unpredictable.\n\nCurrent implementation:\nxfrm_spi_hash() lookup function computes hash using daddr, proto, and family.\nSo if two SAs have the same SPI but different destination addresses, then\nthey will:\na. Hash into different buckets\nb. Be stored in different linked lists (byspi + h)\nc. Not be seen in the same hlist_for_each_entry_rcu() iteration.\nAs a result, the lookup will result in NULL and kernel allows that Duplicate SPI\n\nProposed Change:\nxfrm_state_lookup_spi_proto() does a truly global search - across all states,\nregardless of hash bucket and matches SPI and proto.",
-  "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": [
     {
@@ -37,7 +42,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-12T16:15:34Z"

advisories/unreviewed/2025/09/GHSA-qhp4-v642-v3xp/GHSA-qhp4-v642-v3xp.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-qhp4-v642-v3xp",
-  "modified": "2025-09-15T15:31:21Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-15T15:31:21Z",
   "aliases": [
     "CVE-2022-50234"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/af_unix: defer registered files gc to io_uring release\n\nInstead of putting io_uring's registered files in unix_gc() we want it\nto be done by io_uring itself. The trick here is to consider io_uring\nregistered files for cycle detection but not actually putting them down.\nBecause io_uring can't register other ring instances, this will remove\nall refs to the ring file triggering the ->release path and clean up\nwith io_ring_ctx_free().\n\n[axboe: add kerneldoc comment to skb, fold in skb leak fix]",
-  "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": [
     {
@@ -41,7 +46,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-15T14:15:33Z"

advisories/unreviewed/2025/09/GHSA-w2mf-xqwh-rhg8/GHSA-w2mf-xqwh-rhg8.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-w2mf-xqwh-rhg8",
-  "modified": "2025-09-12T18:31:10Z",
+  "modified": "2025-11-24T18:31:08Z",
   "published": "2025-09-12T18:31:10Z",
   "aliases": [
     "CVE-2025-39796"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lapbether: ignore ops-locked netdevs\n\nSyzkaller managed to trigger lock dependency in xsk_notify via\nregister_netdevice. As discussed in [0], using register_netdevice\nin the notifiers is problematic so skip adding lapbeth for ops-locked\ndevices.\n\n       xsk_notifier+0xa4/0x280 net/xdp/xsk.c:1645\n       notifier_call_chain+0xbc/0x410 kernel/notifier.c:85\n       call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230\n       call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n       call_netdevice_notifiers net/core/dev.c:2282 [inline]\n       unregister_netdevice_many_notify+0xf9d/0x2700 net/core/dev.c:12077\n       unregister_netdevice_many net/core/dev.c:12140 [inline]\n       unregister_netdevice_queue+0x305/0x3f0 net/core/dev.c:11984\n       register_netdevice+0x18f1/0x2270 net/core/dev.c:11149\n       lapbeth_new_device drivers/net/wan/lapbether.c:420 [inline]\n       lapbeth_device_event+0x5b1/0xbe0 drivers/net/wan/lapbether.c:462\n       notifier_call_chain+0xbc/0x410 kernel/notifier.c:85\n       call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230\n       call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n       call_netdevice_notifiers net/core/dev.c:2282 [inline]\n       __dev_notify_flags+0x12c/0x2e0 net/core/dev.c:9497\n       netif_change_flags+0x108/0x160 net/core/dev.c:9526\n       dev_change_flags+0xba/0x250 net/core/dev_api.c:68\n       devinet_ioctl+0x11d5/0x1f50 net/ipv4/devinet.c:1200\n       inet_ioctl+0x3a7/0x3f0 net/ipv4/af_inet.c:1001\n\n0: https://lore.kernel.org/netdev/[email protected]/",
-  "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": [
     {
@@ -29,7 +34,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-09-12T16:15:33Z"