Advisory Database Sync

Author: advisory-database[bot]

advisories/github-reviewed/2025/08/GHSA-856v-8qm2-9wjv/GHSA-856v-8qm2-9wjv.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-856v-8qm2-9wjv",
-  "modified": "2025-10-30T15:32:20Z",
+  "modified": "2025-11-07T00:30:27Z",
   "published": "2025-08-07T21:31:08Z",
   "aliases": [
     "CVE-2025-7195"
@@ -40,6 +40,10 @@
       "type": "ADVISORY",
       "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7195"
     },
+    {
+      "type": "WEB",
+      "url": "https://access.redhat.com/errata/RHSA-2025:19332"
+    },
     {
       "type": "WEB",
       "url": "https://access.redhat.com/errata/RHSA-2025:19335"

advisories/unreviewed/2025/04/GHSA-53x5-v4j3-g5xm/GHSA-53x5-v4j3-g5xm.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-53x5-v4j3-g5xm",
-  "modified": "2025-04-18T15:31:38Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-04-18T15:31:38Z",
   "aliases": [
     "CVE-2025-39688"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid()\n\nThe pynfs DELEG8 test fails when run against nfsd. It acquires a\ndelegation and then lets the lease time out. It then tries to use the\ndeleg stateid and expects to see NFS4ERR_DELEG_REVOKED, but it gets\nbad NFS4ERR_BAD_STATEID instead.\n\nWhen a delegation is revoked, it's initially marked with\nSC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked\nwith the SC_STATUS_FREEABLE flag, which denotes that it is waiting for\ns FREE_STATEID call.\n\nnfs4_lookup_stateid() accepts a statusmask that includes the status\nflags that a found stateid is allowed to have. Currently, that mask\nnever includes SC_STATUS_FREEABLE, which means that revoked delegations\nare (almost) never found.\n\nAdd SC_STATUS_FREEABLE to the always-allowed status flags, and remove it\nfrom nfsd4_delegreturn() since it's now always implied.",
-  "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": [
     {
@@ -33,7 +38,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-04-18T07:15:43Z"

advisories/unreviewed/2025/04/GHSA-9ghj-mrhr-8wxx/GHSA-9ghj-mrhr-8wxx.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-9ghj-mrhr-8wxx",
-  "modified": "2025-11-03T21:33:41Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-04-18T15:31:38Z",
   "aliases": [
     "CVE-2025-38637"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: skbprio: Remove overly strict queue assertions\n\nIn the current implementation, skbprio enqueue/dequeue contains an assertion\nthat fails under certain conditions when SKBPRIO is used as a child qdisc under\nTBF with specific parameters. The failure occurs because TBF sometimes peeks at\npackets in the child qdisc without actually dequeuing them when tokens are\nunavailable.\n\nThis peek operation creates a discrepancy between the parent and child qdisc\nqueue length counters. When TBF later receives a high-priority packet,\nSKBPRIO's queue length may show a different value than what's reflected in its\ninternal priority queue tracking, triggering the assertion.\n\nThe fix removes this overly strict assertions in SKBPRIO, they are not\nnecessary at all.",
-  "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": [
     {
@@ -60,8 +65,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-617"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-04-18T07:15:43Z"

advisories/unreviewed/2025/04/GHSA-9q9v-qmg6-ffwc/GHSA-9q9v-qmg6-ffwc.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-9q9v-qmg6-ffwc",
-  "modified": "2025-04-18T15:31:38Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-04-18T15:31:38Z",
   "aliases": [
     "CVE-2025-39930"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai()\n\ncommit 419d1918105e (\"ASoC: simple-card-utils: use __free(device_node) for\ndevice node\") uses __free(device_node) for dlc->of_node, but we need to\nkeep it while driver is in use.\n\nDon't use __free(device_node) in graph_util_parse_dai().",
-  "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": "2025-04-18T07:15:44Z"

advisories/unreviewed/2025/04/GHSA-vf7h-45fw-j88p/GHSA-vf7h-45fw-j88p.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-vf7h-45fw-j88p",
-  "modified": "2025-04-18T15:31:38Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-04-18T15:31:38Z",
   "aliases": [
     "CVE-2025-40325"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: wait barrier before returning discard request with REQ_NOWAIT\n\nraid10_handle_discard should wait barrier before returning a discard bio\nwhich has REQ_NOWAIT. And there is no need to print warning calltrace\nif a discard bio has REQ_NOWAIT flag. Quality engineer usually checks\ndmesg and reports error if dmesg has warning/error calltrace.",
-  "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": "2025-04-18T07:15:44Z"

advisories/unreviewed/2025/04/GHSA-vwg7-hhf5-ff3g/GHSA-vwg7-hhf5-ff3g.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-vwg7-hhf5-ff3g",
-  "modified": "2025-05-02T09:30:30Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-04-18T15:31:38Z",
   "aliases": [
     "CVE-2025-39989"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series \"mm/hwpoison: Fix regressions in memory failure handling\",\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n    - copyin case: poison found in user page while kernel copying from user space\n    - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing.  More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered.  When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible.  User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a (\"x86/futex: Remove .fixup usage\") introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG.  It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n  and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank.  This was overkill because\nit's not an urgent problem that no core is on the verge of consuming that\nbad data.  It's also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI.  Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n    Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too.  But the memory controller is\nexecuting asynchronously from the core, and can't tell the difference\nbetween a \"real\" read and a speculative read.  So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n   speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n   request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n   core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af (\"mm/hwpoison: fix error page recovered but reported\n\"not\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": [
     {
@@ -36,8 +41,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-401"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-04-18T07:15:44Z"

advisories/unreviewed/2025/05/GHSA-22ff-fvm7-6wj7/GHSA-22ff-fvm7-6wj7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-22ff-fvm7-6wj7",
-  "modified": "2025-05-01T15:31:46Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-05-01T15:31:45Z",
   "aliases": [
     "CVE-2022-49769"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Check sb_bsize_shift after reading superblock\n\nFuzzers like to scribble over sb_bsize_shift but in reality it's very\nunlikely that this field would be corrupted on its own. Nevertheless it\nshould be checked to avoid the possibility of messy mount errors due to\nbad calculations. It's always a fixed value based on the block size so\nwe can just check that it's the expected value.\n\nTested with:\n\n    mkfs.gfs2 -O -p lock_nolock /dev/vdb\n    for i in 0 -1 64 65 32 33; do\n        gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb\n        mount /dev/vdb /mnt/test && umount /mnt/test\n    done\n\nBefore this patch we get a withdraw after\n\n[   76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block\n[   76.413681]   bh = 19 (type: exp=5, found=4)\n[   76.413681]   function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492\n\nand with UBSAN configured we also get complaints like\n\n[   76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19\n[   76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'\n\nAfter the patch, these complaints don't appear, mount fails immediately\nand we get an explanation in dmesg.",
-  "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": [
     {
@@ -49,7 +54,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T15:15:59Z"

advisories/unreviewed/2025/05/GHSA-43gf-2x57-fwxf/GHSA-43gf-2x57-fwxf.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-43gf-2x57-fwxf",
-  "modified": "2025-05-01T15:31:43Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-05-01T15:31:43Z",
   "aliases": [
     "CVE-2025-37762"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb()\n\nCorrect error handling in prepare_fb() to fix leaking resources when\nerror happens.",
-  "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": "2025-05-01T14:15:38Z"

advisories/unreviewed/2025/05/GHSA-5573-9qmv-c9ph/GHSA-5573-9qmv-c9ph.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5573-9qmv-c9ph",
-  "modified": "2025-05-01T15:31:45Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-05-01T15:31:45Z",
   "aliases": [
     "CVE-2022-49762"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: check overflow when iterating ATTR_RECORDs\n\nKernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). \nBecause the ATTR_RECORDs are next to each other, kernel can get the next\nATTR_RECORD from end address of current ATTR_RECORD, through current\nATTR_RECORD length field.\n\nThe problem is that during iteration, when kernel calculates the end\naddress of current ATTR_RECORD, kernel may trigger an integer overflow bug\nin executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`.  This\nmay wrap, leading to a forever iteration on 32bit systems.\n\nThis patch solves it by adding some checks on calculating end address\nof current ATTR_RECORD during iteration.",
-  "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": [
     {
@@ -49,7 +54,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-05-01T15:15:58Z"

advisories/unreviewed/2025/05/GHSA-5rmr-vqfv-62q6/GHSA-5rmr-vqfv-62q6.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5rmr-vqfv-62q6",
-  "modified": "2025-05-01T15:31:45Z",
+  "modified": "2025-11-07T00:30:26Z",
   "published": "2025-05-01T15:31:45Z",
   "aliases": [
     "CVE-2022-49765"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: use a dedicated spinlock for trans_fd\n\nShamelessly copying the explanation from Tetsuo Handa's suggested\npatch[1] (slightly reworded):\nsyzbot is reporting inconsistent lock state in p9_req_put()[2],\nfor p9_tag_remove() from p9_req_put() from IRQ context is using\nspin_lock_irqsave() on \"struct p9_client\"->lock but trans_fd\n(not from IRQ context) is using spin_lock().\n\nSince the locks actually protect different things in client.c and in\ntrans_fd.c, just replace trans_fd.c's lock by a new one specific to the\ntransport (client.c's protect the idr for fid/tag allocations,\nwhile trans_fd.c's protects its own req list and request status field\nthat acts as the transport's state machine)",
-  "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": "2025-05-01T15:15:59Z"