Advisory Database Sync

Author: advisory-database[bot]

advisories/unreviewed/2025/05/GHSA-h6cg-6m9j-xj9g/GHSA-h6cg-6m9j-xj9g.json

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

advisories/unreviewed/2025/12/GHSA-2m44-r2x5-4q79/GHSA-2m44-r2x5-4q79.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2m44-r2x5-4q79",
-  "modified": "2026-02-19T18:31:42Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-24T12:30:29Z",
   "aliases": [
     "CVE-2025-68358"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix racy bitfield write in btrfs_clear_space_info_full()\n\nFrom the memory-barriers.txt document regarding memory barrier ordering\nguarantees:\n\n (*) These guarantees do not apply to bitfields, because compilers often\n     generate code to modify these using non-atomic read-modify-write\n     sequences.  Do not attempt to use bitfields to synchronize parallel\n     algorithms.\n\n (*) Even in cases where bitfields are protected by locks, all fields\n     in a given bitfield must be protected by one lock.  If two fields\n     in a given bitfield are protected by different locks, the compiler's\n     non-atomic read-modify-write sequences can cause an update to one\n     field to corrupt the value of an adjacent field.\n\nbtrfs_space_info has a bitfield sharing an underlying word consisting of\nthe fields full, chunk_alloc, and flush:\n\nstruct btrfs_space_info {\n        struct btrfs_fs_info *     fs_info;              /*     0     8 */\n        struct btrfs_space_info *  parent;               /*     8     8 */\n        ...\n        int                        clamp;                /*   172     4 */\n        unsigned int               full:1;               /*   176: 0  4 */\n        unsigned int               chunk_alloc:1;        /*   176: 1  4 */\n        unsigned int               flush:1;              /*   176: 2  4 */\n        ...\n\nTherefore, to be safe from parallel read-modify-writes losing a write to\none of the bitfield members protected by a lock, all writes to all the\nbitfields must use the lock. They almost universally do, except for\nbtrfs_clear_space_info_full() which iterates over the space_infos and\nwrites out found->full = 0 without a lock.\n\nImagine that we have one thread completing a transaction in which we\nfinished deleting a block_group and are thus calling\nbtrfs_clear_space_info_full() while simultaneously the data reclaim\nticket infrastructure is running do_async_reclaim_data_space():\n\n          T1                                             T2\nbtrfs_commit_transaction\n  btrfs_clear_space_info_full\n  data_sinfo->full = 0\n  READ: full:0, chunk_alloc:0, flush:1\n                                              do_async_reclaim_data_space(data_sinfo)\n                                              spin_lock(&space_info->lock);\n                                              if(list_empty(tickets))\n                                                space_info->flush = 0;\n                                                READ: full: 0, chunk_alloc:0, flush:1\n                                                MOD/WRITE: full: 0, chunk_alloc:0, flush:0\n                                                spin_unlock(&space_info->lock);\n                                                return;\n  MOD/WRITE: full:0, chunk_alloc:0, flush:1\n\nand now data_sinfo->flush is 1 but the reclaim worker has exited. This\nbreaks the invariant that flush is 0 iff there is no work queued or\nrunning. Once this invariant is violated, future allocations that go\ninto __reserve_bytes() will add tickets to space_info->tickets but will\nsee space_info->flush is set to 1 and not queue the work. After this,\nthey will block forever on the resulting ticket, as it is now impossible\nto kick the worker again.\n\nI also confirmed by looking at the assembly of the affected kernel that\nit is doing RMW operations. For example, to set the flush (3rd) bit to 0,\nthe assembly is:\n  andb    $0xfb,0x60(%rbx)\nand similarly for setting the full (1st) bit to 0:\n  andb    $0xfe,-0x20(%rax)\n\nSo I think this is really a bug on practical systems.  I have observed\na number of systems in this exact state, but am currently unable to\nreproduce it.\n\nRather than leaving this footgun lying around for the future, take\nadvantage of the fact that there is room in the struct anyway, and that\nit is already quite large and simply change the three bitfield members to\nbools. This avoids writes to space_info->full having any effect on\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": [
     {
@@ -45,7 +50,7 @@
   ],
   "database_specific": {
     "cwe_ids": [],
-    "severity": null,
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-12-24T11:15:59Z"

advisories/unreviewed/2025/12/GHSA-696c-x544-xmc9/GHSA-696c-x544-xmc9.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-696c-x544-xmc9",
-  "modified": "2026-02-06T18:30:28Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-24T12:30:30Z",
   "aliases": [
     "CVE-2025-68725"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do not let BPF test infra emit invalid GSO types to stack\n\nYinhao et al. reported that their fuzzer tool was able to trigger a\nskb_warn_bad_offload() from netif_skb_features() -> gso_features_check().\nWhen a BPF program - triggered via BPF test infra - pushes the packet\nto the loopback device via bpf_clone_redirect() then mentioned offload\nwarning can be seen. GSO-related features are then rightfully disabled.\n\nWe get into this situation due to convert___skb_to_skb() setting\ngso_segs and gso_size but not gso_type. Technically, it makes sense\nthat this warning triggers since the GSO properties are malformed due\nto the gso_type. Potentially, the gso_type could be marked non-trustworthy\nthrough setting it at least to SKB_GSO_DODGY without any other specific\nassumptions, but that also feels wrong given we should not go further\ninto the GSO engine in the first place.\n\nThe checks were added in 121d57af308d (\"gso: validate gso_type in GSO\nhandlers\") because there were malicious (syzbot) senders that combine\na protocol with a non-matching gso_type. If we would want to drop such\npackets, gso_features_check() currently only returns feature flags via\nnetif_skb_features(), so one location for potentially dropping such skbs\ncould be validate_xmit_unreadable_skb(), but then otoh it would be\nan additional check in the fast-path for a very corner case. Given\nbpf_clone_redirect() is the only place where BPF test infra could emit\nsuch packets, lets reject them right there.",
-  "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": "2025-12-24T11:16:01Z"

advisories/unreviewed/2025/12/GHSA-8phj-p75x-7gv8/GHSA-8phj-p75x-7gv8.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-8phj-p75x-7gv8",
-  "modified": "2026-01-30T12:31:20Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-24T15:30:44Z",
   "aliases": [
     "CVE-2025-68749"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix race condition when unbinding BOs\n\nFix 'Memory manager not clean during takedown' warning that occurs\nwhen ivpu_gem_bo_free() removes the BO from the BOs list before it\ngets unmapped. Then file_priv_unbind() triggers a warning in\ndrm_mm_takedown() during context teardown.\n\nProtect the unmapping sequence with bo_list_lock to ensure the BO is\nalways fully unmapped when removed from the list. This ensures the BO\nis either fully unmapped at context teardown time or present on the\nlist and unmapped by file_priv_unbind().",
-  "severity": [],
+  "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"
+    }
+  ],
   "affected": [],
   "references": [
     {
@@ -32,8 +37,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-362"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-12-24T13:16:29Z"

advisories/unreviewed/2025/12/GHSA-g737-8242-62f7/GHSA-g737-8242-62f7.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-g737-8242-62f7",
-  "modified": "2026-02-06T18:30:28Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-24T12:30:29Z",
   "aliases": [
     "CVE-2025-68365"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Initialize allocated memory before use\n\nKMSAN reports: Multiple uninitialized values detected:\n\n- KMSAN: uninit-value in ntfs_read_hdr (3)\n- KMSAN: uninit-value in bcmp (3)\n\nMemory is allocated by __getname(), which is a wrapper for\nkmem_cache_alloc(). This memory is used before being properly\ncleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to\nproperly allocate and clear memory before use.",
-  "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-908"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-12-24T11:16:00Z"

advisories/unreviewed/2025/12/GHSA-hrv6-wqc3-mmr3/GHSA-hrv6-wqc3-mmr3.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-hrv6-wqc3-mmr3",
-  "modified": "2026-02-06T18:30:28Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-30T15:30:31Z",
   "aliases": [
     "CVE-2023-54207"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Correct devm device reference for hidinput input_dev name\n\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\n\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.",
-  "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-12-30T13:16:08Z"

advisories/unreviewed/2025/12/GHSA-vfgj-f4g9-xh2h/GHSA-vfgj-f4g9-xh2h.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-vfgj-f4g9-xh2h",
-  "modified": "2026-02-06T18:30:28Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-30T15:30:36Z",
   "aliases": [
     "CVE-2023-54321"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G    B   W        N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n <TASK>\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n  // The dev->driver is set to w1_master_driver.\n  memcpy(&dev->dev, device, sizeof(struct device));\n  device_add()\n    bus_add_device()\n    dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n    // error path\n    bus_remove_device()\n      // The dev->driver is not null, but driver is not bound.\n      __device_release_driver()\n        klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.\n\n    // normal path\n    bus_probe_device() // It's not called yet.\n      device_bind_driver()\n\nIf dev->driver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the 'knode_driver'. To fix this, set\ndev->driver to null in the error path before calling bus_remove_device().",
-  "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-476"
+    ],
+    "severity": "MODERATE",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-12-30T13:16:21Z"

advisories/unreviewed/2025/12/GHSA-wfvh-f2f6-f56w/GHSA-wfvh-f2f6-f56w.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-wfvh-f2f6-f56w",
-  "modified": "2026-02-06T18:30:28Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2025-12-30T15:30:34Z",
   "aliases": [
     "CVE-2023-54285"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niomap: Fix possible overflow condition in iomap_write_delalloc_scan\n\nfolio_next_index() returns an unsigned long value which left shifted\nby PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead\nuse folio_pos(folio) + folio_size(folio), which does this correctly.",
-  "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": [
     {
@@ -28,8 +33,10 @@
     }
   ],
   "database_specific": {
-    "cwe_ids": [],
-    "severity": null,
+    "cwe_ids": [
+      "CWE-787"
+    ],
+    "severity": "HIGH",
     "github_reviewed": false,
     "github_reviewed_at": null,
     "nvd_published_at": "2025-12-30T13:16:17Z"

advisories/unreviewed/2026/01/GHSA-2hrm-3727-3mc5/GHSA-2hrm-3727-3mc5.json

@@ -1,13 +1,17 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2hrm-3727-3mc5",
-  "modified": "2026-01-03T00:31:26Z",
+  "modified": "2026-02-26T21:31:25Z",
   "published": "2026-01-03T00:31:26Z",
   "aliases": [
     "CVE-2025-64122"
   ],
   "details": "Insufficiently Protected Credentials vulnerability in Nuvation Energy Multi-Stack Controller (MSC) allows Signature Spoofing by Key Theft.This issue affects Multi-Stack Controller (MSC): through 2.5.1.",
   "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N"
+    },
     {
       "type": "CVSS_V4",
       "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X"

advisories/unreviewed/2026/01/GHSA-334x-45wh-5m94/GHSA-334x-45wh-5m94.json

@@ -1,13 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-334x-45wh-5m94",
-  "modified": "2026-01-23T18:31:28Z",
+  "modified": "2026-02-26T21:31:27Z",
   "published": "2026-01-23T18:31:28Z",
   "aliases": [
     "CVE-2026-22980"
   ],
   "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: provide locking for v4_end_grace\n\nWriting to v4_end_grace can race with server shutdown and result in\nmemory being accessed after it was freed - reclaim_str_hashtbl in\nparticularly.\n\nWe cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is\nheld while client_tracking_op->init() is called and that can wait for\nan upcall to nfsdcltrack which can write to v4_end_grace, resulting in a\ndeadlock.\n\nnfsd4_end_grace() is also called by the landromat work queue and this\ndoesn't require locking as server shutdown will stop the work and wait\nfor it before freeing anything that nfsd4_end_grace() might access.\n\nHowever, we must be sure that writing to v4_end_grace doesn't restart\nthe work item after shutdown has already waited for it.  For this we\nadd a new flag protected with nn->client_lock.  It is set only while it\nis safe to make client tracking calls, and v4_end_grace only schedules\nwork while the flag is set with the spinlock held.\n\nSo this patch adds a nfsd_net field \"client_tracking_active\" which is\nset as described.  Another field \"grace_end_forced\", is set when\nv4_end_grace is written.  After this is set, and providing\nclient_tracking_active is set, the laundromat is scheduled.\nThis \"grace_end_forced\" field bypasses other checks for whether the\ngrace period has finished.\n\nThis resolves a race which can result in use-after-free.",
-  "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-23T16:15:54Z"