Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/05/GHSA-69hw-3r8x-9jf6/GHSA-69hw-3r8x-9jf6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-69hw-3r8x-9jf6",
-  "modified": "2025-11-03T21:33:55Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-05-20T18:30:55Z",
   "aliases": [
     "CVE-2025-37940"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Add cond_resched() to ftrace_graph_set_hash()\n\nWhen the kernel contains a large number of functions that can be traced,\nthe loop in ftrace_graph_set_hash() may take a lot of time to execute.\nThis may trigger the softlockup watchdog.\n\nAdd cond_resched() within the loop to allow the kernel to remain\nresponsive even when processing a large number of functions.\n\nThis matches the cond_resched() that is used in other locations of the\ncode that iterates over all functions that can be traced.",
-  "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": "2025-05-20T16:15:31Z"

advisories/unreviewed/2025/05/GHSA-7qvj-8m4h-6v7j/GHSA-7qvj-8m4h-6v7j.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-7qvj-8m4h-6v7j",
-  "modified": "2025-11-03T21:33:55Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-05-20T18:30:55Z",
   "aliases": [
     "CVE-2025-37936"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.\n\nWhen generating the MSR_IA32_PEBS_ENABLE value that will be loaded on\nVM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE\nvalue.  Consulting only the host kernel's host vs. guest masks results in\nrunning the guest with PEBS enabled even when the guest doesn't want to use\nPEBS.  Because KVM uses perf events to proxy the guest virtual PMU, simply\nlooking at exclude_host can't differentiate between events created by host\nuserspace, and events created by KVM on behalf of the guest.\n\nRunning the guest with PEBS unexpectedly enabled typically manifests as\ncrashes due to a near-infinite stream of #PFs.  E.g. if the guest hasn't\nwritten MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when\ntrying to record PEBS events.\n\nThe issue is most easily reproduced by running `perf kvm top` from before\ncommit 7b100989b4f6 (\"perf evlist: Remove __evlist__add_default\") (after\nwhich, `perf kvm top` effectively stopped using PEBS).\tThe userspace side\nof perf creates a guest-only PEBS event, which intel_guest_get_msrs()\nmisconstrues a guest-*owned* PEBS event.\n\nArguably, this is a userspace bug, as enabling PEBS on guest-only events\nsimply cannot work, and userspace can kill VMs in many other ways (there\nis no danger to the host).  However, even if this is considered to be bad\nuserspace behavior, there's zero downside to perf/KVM restricting PEBS to\nguest-owned events.\n\nNote, commit 854250329c02 (\"KVM: x86/pmu: Disable guest PEBS temporarily\nin two rare situations\") fixed the case where host userspace is profiling\nKVM *and* userspace, but missed the case where userspace is profiling only\nKVM.",
-  "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": "2025-05-20T16:15:30Z"

advisories/unreviewed/2025/05/GHSA-fm29-2487-rchf/GHSA-fm29-2487-rchf.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-fm29-2487-rchf",
-  "modified": "2025-11-03T21:33:55Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-05-20T18:30:55Z",
   "aliases": [
     "CVE-2025-37937"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()'s call to dib8000_read32() returns zero, the result\nis a divide-by-zero.  Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()",
-  "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-369"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-20T16:15:30Z"

advisories/unreviewed/2025/05/GHSA-h35m-jp6f-245x/GHSA-h35m-jp6f-245x.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-h35m-jp6f-245x",
-  "modified": "2025-11-03T21:33:55Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-05-20T18:30:55Z",
   "aliases": [
     "CVE-2025-37932"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet's make it idempotent to ease qdisc_tree_reduce_backlog() callers'\nlife.",
-  "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": [
     {
@@ -57,7 +62,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-20T16:15:29Z"

advisories/unreviewed/2025/05/GHSA-r878-fwjf-3cg7/GHSA-r878-fwjf-3cg7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-r878-fwjf-3cg7",
-  "modified": "2025-11-03T21:33:55Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-05-20T18:30:55Z",
   "aliases": [
     "CVE-2025-37938"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Verify event formats that have \"%*p..\"\n\nThe trace event verifier checks the formats of trace events to make sure\nthat they do not point at memory that is not in the trace event itself or\nin data that will never be freed. If an event references data that was\nallocated when the event triggered and that same data is freed before the\nevent is read, then the kernel can crash by reading freed memory.\n\nThe verifier runs at boot up (or module load) and scans the print formats\nof the events and checks their arguments to make sure that dereferenced\npointers are safe. If the format uses \"%*p..\" the verifier will ignore it,\nand that could be dangerous. Cover this case as well.\n\nAlso add to the sample code a use case of \"%*pbl\".",
-  "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-476"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-20T16:15:31Z"

advisories/unreviewed/2025/05/GHSA-v9hh-vwqw-fc9h/GHSA-v9hh-vwqw-fc9h.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-v9hh-vwqw-fc9h",
-  "modified": "2025-11-03T18:31:16Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-05-20T18:30:55Z",
   "aliases": [
     "CVE-2025-37931"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: adjust subpage bit start based on sectorsize\n\nWhen running machines with 64k page size and a 16k nodesize we started\nseeing tree log corruption in production.  This turned out to be because\nwe were not writing out dirty blocks sometimes, so this in fact affects\nall metadata writes.\n\nWhen writing out a subpage EB we scan the subpage bitmap for a dirty\nrange.  If the range isn't dirty we do\n\n\tbit_start++;\n\nto move onto the next bit.  The problem is the bitmap is based on the\nnumber of sectors that an EB has.  So in this case, we have a 64k\npagesize, 16k nodesize, but a 4k sectorsize.  This means our bitmap is 4\nbits for every node.  With a 64k page size we end up with 4 nodes per\npage.\n\nTo make this easier this is how everything looks\n\n[0         16k       32k       48k     ] logical address\n[0         4         8         12      ] radix tree offset\n[               64k page               ] folio\n[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers\n[ | | | |  | | | |   | | | |   | | | | ] bitmap\n\nNow we use all of our addressing based on fs_info->sectorsize_bits, so\nas you can see the above our 16k eb->start turns into radix entry 4.\n\nWhen we find a dirty range for our eb, we correctly do bit_start +=\nsectors_per_node, because if we start at bit 0, the next bit for the\nnext eb is 4, to correspond to eb->start 16k.\n\nHowever if our range is clean, we will do bit_start++, which will now\nput us offset from our radix tree entries.\n\nIn our case, assume that the first time we check the bitmap the block is\nnot dirty, we increment bit_start so now it == 1, and then we loop\naround and check again.  This time it is dirty, and we go to find that\nstart using the following equation\n\n\tstart = folio_start + bit_start * fs_info->sectorsize;\n\nso in the case above, eb->start 0 is now dirty, and we calculate start\nas\n\n\t0 + 1 * fs_info->sectorsize = 4096\n\t4096 >> 12 = 1\n\nNow we're looking up the radix tree for 1, and we won't find an eb.\nWhat's worse is now we're using bit_start == 1, so we do bit_start +=\nsectors_per_node, which is now 5.  If that eb is dirty we will run into\nthe same thing, we will look at an offset that is not populated in the\nradix tree, and now we're skipping the writeout of dirty extent buffers.\n\nThe best fix for this is to not use sectorsize_bits to address nodes,\nbut that's a larger change.  Since this is a fs corruption problem fix\nit simply by always using sectors_per_node to increment the start bit.",
-  "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": "2025-05-20T16:15:29Z"

advisories/unreviewed/2025/07/GHSA-43x8-vph3-w4wc/GHSA-43x8-vph3-w4wc.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-43x8-vph3-w4wc",
-  "modified": "2025-11-03T18:31:24Z",
+  "modified": "2025-12-19T18:31:06Z",
   "published": "2025-07-10T09:32:30Z",
   "aliases": [
     "CVE-2025-38322"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Fix crash in icl_update_topdown_event()\n\nThe perf_fuzzer found a hard-lockup crash on a RaptorLake machine:\n\n  Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000\n  CPU: 23 UID: 0 PID: 0 Comm: swapper/23\n  Tainted: [W]=WARN\n  Hardware name: Dell Inc. Precision 9660/0VJ762\n  RIP: 0010:native_read_pmc+0x7/0x40\n  Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ...\n  RSP: 000:fffb03100273de8 EFLAGS: 00010046\n  ....\n  Call Trace:\n    <TASK>\n    icl_update_topdown_event+0x165/0x190\n    ? ktime_get+0x38/0xd0\n    intel_pmu_read_event+0xf9/0x210\n    __perf_event_read+0xf9/0x210\n\nCPUs 16-23 are E-core CPUs that don't support the perf metrics feature.\nThe icl_update_topdown_event() should not be invoked on these CPUs.\n\nIt's a regression of commit:\n\n  f9bdf1f95339 (\"perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read\")\n\nThe bug introduced by that commit is that the is_topdown_event() function\nis mistakenly used to replace the is_topdown_count() call to check if the\ntopdown functions for the perf metrics feature should be invoked.\n\nFix it.",
-  "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": "2025-07-10T09:15:26Z"

advisories/unreviewed/2025/07/GHSA-4p78-ch7c-j3pv/GHSA-4p78-ch7c-j3pv.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-4p78-ch7c-j3pv",
-  "modified": "2025-11-03T18:31:25Z",
+  "modified": "2025-12-19T18:31:06Z",
   "published": "2025-07-10T09:32:31Z",
   "aliases": [
     "CVE-2025-38326"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naoe: clean device rq_list in aoedev_downdev()\n\nAn aoe device's rq_list contains accepted block requests that are\nwaiting to be transmitted to the aoe target. This queue was added as\npart of the conversion to blk_mq. However, the queue was not cleaned out\nwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleep\nindefinitely waiting for those requests to complete, causing a hang. This\nfix cleans out the queue before calling blk_mq_freeze_queue().",
-  "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": [
     {
@@ -57,7 +62,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-10T09:15:26Z"

advisories/unreviewed/2025/07/GHSA-6cqx-88r9-52g7/GHSA-6cqx-88r9-52g7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6cqx-88r9-52g7",
-  "modified": "2025-11-03T18:31:24Z",
+  "modified": "2025-12-19T18:31:05Z",
   "published": "2025-07-10T09:32:29Z",
   "aliases": [
     "CVE-2025-38300"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()\n\nFix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():\n\n1] If dma_map_sg() fails for areq->dst, the device driver would try to free\n   DMA memory it has not allocated in the first place. To fix this, on the\n   \"theend_sgs\" error path, call dma unmap only if the corresponding dma\n   map was successful.\n\n2] If the dma_map_single() call for the IV fails, the device driver would\n   try to free an invalid DMA memory address on the \"theend_iv\" path:\n   ------------[ cut here ]------------\n   DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address\n   WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90\n   Modules linked in: skcipher_example(O+)\n   CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G           O        6.15.0-rc3+ #24 PREEMPT\n   Tainted: [O]=OOT_MODULE\n   Hardware name: OrangePi Zero2 (DT)\n   pc : check_unmap+0x123c/0x1b90\n   lr : check_unmap+0x123c/0x1b90\n   ...\n   Call trace:\n    check_unmap+0x123c/0x1b90 (P)\n    debug_dma_unmap_page+0xac/0xc0\n    dma_unmap_page_attrs+0x1f4/0x5fc\n    sun8i_ce_cipher_do_one+0x1bd4/0x1f40\n    crypto_pump_work+0x334/0x6e0\n    kthread_worker_fn+0x21c/0x438\n    kthread+0x374/0x664\n    ret_from_fork+0x10/0x20\n   ---[ end trace 0000000000000000 ]---\n\nTo fix this, check for !dma_mapping_error() before calling\ndma_unmap_single() on the \"theend_iv\" path.",
-  "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-401"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-07-10T08:15:28Z"