Common Weakness Enumeration

CWE-459

Allowed

Incomplete Cleanup

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not properly "clean up" and remove temporary or supporting resources after they have been used.

223 vulnerabilities reference this CWE, most recent first.

GHSA-7G3V-G92M-87WQ

Vulnerability from github – Published: 2025-02-27 03:33 – Updated: 2025-10-23 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

btrfs: do proper folio cleanup when cow_file_range() failed

[BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path.

This BUG_ON() happens just after a failed btrfs_run_delalloc_range():

BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]---

[CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC.

Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling.

For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size:

0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################|

Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag.

  • Enter extent_writepage() for page 0

  • Enter btrfs_run_delalloc_range() for range [0, 64K)

  • Enter cow_file_range() for range [0, 64K)

  • Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K)

0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################|

And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty.

  • Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges:

0 16K 32K 48K 64K |////////| | | | |

Note that range [0, 16K) still has its pages dirty.

  • Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags.

  • btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag.

  • extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON().

Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel.

[FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished.

When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases) ---truncated---

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-57976"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T02:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do proper folio cleanup when cow_file_range() failed\n\n[BUG]\nWhen testing with COW fixup marked as BUG_ON() (this is involved with the\nnew pin_user_pages*() change, which should not result new out-of-band\ndirty pages), I hit a crash triggered by the BUG_ON() from hitting COW\nfixup path.\n\nThis BUG_ON() happens just after a failed btrfs_run_delalloc_range():\n\n  BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/extent_io.c:1444!\n  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n  CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G           OE      6.12.0-rc7-custom+ #86\n  Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022\n  Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]\n  pc : extent_writepage_io+0x2d4/0x308 [btrfs]\n  lr : extent_writepage_io+0x2d4/0x308 [btrfs]\n  Call trace:\n   extent_writepage_io+0x2d4/0x308 [btrfs]\n   extent_writepage+0x218/0x330 [btrfs]\n   extent_write_cache_pages+0x1d4/0x4b0 [btrfs]\n   btrfs_writepages+0x94/0x150 [btrfs]\n   do_writepages+0x74/0x190\n   filemap_fdatawrite_wbc+0x88/0xc8\n   start_delalloc_inodes+0x180/0x3b0 [btrfs]\n   btrfs_start_delalloc_roots+0x174/0x280 [btrfs]\n   shrink_delalloc+0x114/0x280 [btrfs]\n   flush_space+0x250/0x2f8 [btrfs]\n   btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]\n   process_one_work+0x164/0x408\n   worker_thread+0x25c/0x388\n   kthread+0x100/0x118\n   ret_from_fork+0x10/0x20\n  Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000)\n  ---[ end trace 0000000000000000 ]---\n\n[CAUSE]\nThat failure is mostly from cow_file_range(), where we can hit -ENOSPC.\n\nAlthough the -ENOSPC is already a bug related to our space reservation\ncode, let\u0027s just focus on the error handling.\n\nFor example, we have the following dirty range [0, 64K) of an inode,\nwith 4K sector size and 4K page size:\n\n   0        16K        32K       48K       64K\n   |///////////////////////////////////////|\n   |#######################################|\n\nWhere |///| means page are still dirty, and |###| means the extent io\ntree has EXTENT_DELALLOC flag.\n\n- Enter extent_writepage() for page 0\n\n- Enter btrfs_run_delalloc_range() for range [0, 64K)\n\n- Enter cow_file_range() for range [0, 64K)\n\n- Function btrfs_reserve_extent() only reserved one 16K extent\n  So we created extent map and ordered extent for range [0, 16K)\n\n   0        16K        32K       48K       64K\n   |////////|//////////////////////////////|\n   |\u003c- OE -\u003e|##############################|\n\n   And range [0, 16K) has its delalloc flag cleared.\n   But since we haven\u0027t yet submit any bio, involved 4 pages are still\n   dirty.\n\n- Function btrfs_reserve_extent() returns with -ENOSPC\n  Now we have to run error cleanup, which will clear all\n  EXTENT_DELALLOC* flags and clear the dirty flags for the remaining\n  ranges:\n\n   0        16K        32K       48K       64K\n   |////////|                              |\n   |        |                              |\n\n  Note that range [0, 16K) still has its pages dirty.\n\n- Some time later, writeback is triggered again for the range [0, 16K)\n  since the page range still has dirty flags.\n\n- btrfs_run_delalloc_range() will do nothing because there is no\n  EXTENT_DELALLOC flag.\n\n- extent_writepage_io() finds page 0 has no ordered flag\n  Which falls into the COW fixup path, triggering the BUG_ON().\n\nUnfortunately this error handling bug dates back to the introduction of\nbtrfs.  Thankfully with the abuse of COW fixup, at least it won\u0027t crash\nthe kernel.\n\n[FIX]\nInstead of immediately unlocking the extent and folios, we keep the extent\nand folios locked until either erroring out or the whole delalloc range\nfinished.\n\nWhen the whole delalloc range finished without error, we just unlock the\nwhole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked\ncases)\n---truncated---",
  "id": "GHSA-7g3v-g92m-87wq",
  "modified": "2025-10-23T18:31:05Z",
  "published": "2025-02-27T03:33:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57976"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/06f364284794f149d2abc167c11d556cf20c954b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/10b3772292bf1be45604ba83fd9650eb94382e78"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/692cf71173bb41395c855acbbbe197d3aedfa5d4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7PHW-GFJ7-V79Q

Vulnerability from github – Published: 2025-04-02 15:31 – Updated: 2025-11-03 21:33
VLAI
Details

A denial of service vulnerability exists in the NetX Component HTTP server functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.This vulnerability affects X-CUBE-AZRTOS-F7 NetX Duo Web Component HTTP server v 1.1.0. This HTTP server implementation is contained in this file - x-cube-azrtos-f7\Middlewares\ST\netxduo\addons\web\nx_web_http_server.c

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-50384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-02T14:15:43Z",
    "severity": "MODERATE"
  },
  "details": "A denial of service vulnerability exists in the NetX Component HTTP server functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.This vulnerability affects X-CUBE-AZRTOS-F7 NetX Duo Web Component HTTP server v 1.1.0. This HTTP server implementation is contained in this file - x-cube-azrtos-f7\\Middlewares\\ST\\netxduo\\addons\\web\\nx_web_http_server.c",
  "id": "GHSA-7phw-gfj7-v79q",
  "modified": "2025-11-03T21:33:28Z",
  "published": "2025-04-02T15:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50384"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2024-2097"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2024-2097"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7XQ6-JM62-WW8G

Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-03-17 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

xen/events: close evtchn after mapping cleanup

shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock.

This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel:

CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } }

Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1).

  • __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq.

The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup.

On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel.

------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated---

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T15:15:52Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen/events: close evtchn after mapping cleanup\n\nshutdown_pirq and startup_pirq are not taking the\nirq_mapping_update_lock because they can\u0027t due to lock inversion. Both\nare called with the irq_desc-\u003elock being taking. The lock order,\nhowever, is first irq_mapping_update_lock and then irq_desc-\u003elock.\n\nThis opens multiple races:\n- shutdown_pirq can be interrupted by a function that allocates an event\n  channel:\n\n  CPU0                        CPU1\n  shutdown_pirq {\n    xen_evtchn_close(e)\n                              __startup_pirq {\n                                EVTCHNOP_bind_pirq\n                                  -\u003e returns just freed evtchn e\n                                set_evtchn_to_irq(e, irq)\n                              }\n    xen_irq_info_cleanup() {\n      set_evtchn_to_irq(e, -1)\n    }\n  }\n\n  Assume here event channel e refers here to the same event channel\n  number.\n  After this race the evtchn_to_irq mapping for e is invalid (-1).\n\n- __startup_pirq races with __unbind_from_irq in a similar way. Because\n  __startup_pirq doesn\u0027t take irq_mapping_update_lock it can grab the\n  evtchn that __unbind_from_irq is currently freeing and cleaning up. In\n  this case even though the event channel is allocated, its mapping can\n  be unset in evtchn_to_irq.\n\nThe fix is to first cleanup the mappings and then close the event\nchannel. In this way, when an event channel gets allocated it\u0027s\npotential previous evtchn_to_irq mappings are guaranteed to be unset already.\nThis is also the reverse order of the allocation where first the event\nchannel is allocated and then the mappings are setup.\n\nOn a 5.10 kernel prior to commit 3fcdaf3d7634 (\"xen/events: modify internal\n[un]bind interfaces\"), we hit a BUG like the following during probing of NVMe\ndevices. The issue is that during nvme_setup_io_queues, pci_free_irq\nis called for every device which results in a call to shutdown_pirq.\nWith many nvme devices it\u0027s therefore likely to hit this race during\nboot because there will be multiple calls to shutdown_pirq and\nstartup_pirq are running potentially in parallel.\n\n  ------------[ cut here ]------------\n  blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled\n  kernel BUG at drivers/xen/events/events_base.c:499!\n  invalid opcode: 0000 [#1] SMP PTI\n  CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1\n  Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006\n  Workqueue: nvme-reset-wq nvme_reset_work\n  RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0\n  Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff \u003c0f\u003e 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00\n  RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046\n  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006\n  RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff\n  RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00\n  R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed\n  R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002\n  FS:  0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   ? show_trace_log_lvl+0x1c1/0x2d9\n   ? show_trace_log_lvl+0x1c1/0x2d9\n   ? set_affinity_irq+0xdc/0x1c0\n   ? __die_body.cold+0x8/0xd\n   ? die+0x2b/0x50\n   ? do_trap+0x90/0x110\n   ? bind_evtchn_to_cpu+0xdf/0xf0\n   ? do_error_trap+0x65/0x80\n   ? bind_evtchn_to_cpu+0xdf/0xf0\n   ? exc_invalid_op+0x4e/0x70\n   ? bind_evtchn_to_cpu+0xdf/0xf0\n   ? asm_exc_invalid_op+0x12/0x20\n   ? bind_evtchn_to_cpu+0xdf/0x\n---truncated---",
  "id": "GHSA-7xq6-jm62-ww8g",
  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-03T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26687"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-85G7-5359-R834

Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-03-17 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

md: Don't register sync_thread for reshape directly

Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared.

Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally:

[root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN

Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26756"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T17:15:52Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t register sync_thread for reshape directly\n\nCurrently, if reshape is interrupted, then reassemble the array will\nregister sync_thread directly from pers-\u003erun(), in this case\n\u0027MD_RECOVERY_RUNNING\u0027 is set directly, however, there is no guarantee\nthat md_do_sync() will be executed, hence stop_sync_thread() will hang\nbecause \u0027MD_RECOVERY_RUNNING\u0027 can\u0027t be cleared.\n\nLast patch make sure that md_do_sync() will set MD_RECOVERY_DONE,\nhowever, following hang can still be triggered by dm-raid test\nshell/lvconvert-raid-reshape.sh occasionally:\n\n[root@fedora ~]# cat /proc/1982/stack\n[\u003c0\u003e] stop_sync_thread+0x1ab/0x270 [md_mod]\n[\u003c0\u003e] md_frozen_sync_thread+0x5c/0xa0 [md_mod]\n[\u003c0\u003e] raid_presuspend+0x1e/0x70 [dm_raid]\n[\u003c0\u003e] dm_table_presuspend_targets+0x40/0xb0 [dm_mod]\n[\u003c0\u003e] __dm_destroy+0x2a5/0x310 [dm_mod]\n[\u003c0\u003e] dm_destroy+0x16/0x30 [dm_mod]\n[\u003c0\u003e] dev_remove+0x165/0x290 [dm_mod]\n[\u003c0\u003e] ctl_ioctl+0x4bb/0x7b0 [dm_mod]\n[\u003c0\u003e] dm_ctl_ioctl+0x11/0x20 [dm_mod]\n[\u003c0\u003e] vfs_ioctl+0x21/0x60\n[\u003c0\u003e] __x64_sys_ioctl+0xb9/0xe0\n[\u003c0\u003e] do_syscall_64+0xc6/0x230\n[\u003c0\u003e] entry_SYSCALL_64_after_hwframe+0x6c/0x74\n\nMeanwhile mddev-\u003erecovery is:\nMD_RECOVERY_RUNNING |\nMD_RECOVERY_INTR |\nMD_RECOVERY_RESHAPE |\nMD_RECOVERY_FROZEN\n\nFix this problem by remove the code to register sync_thread directly\nfrom raid10 and raid5. And let md_check_recovery() to register\nsync_thread.",
  "id": "GHSA-85g7-5359-r834",
  "modified": "2025-03-17T18:31:41Z",
  "published": "2024-04-03T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26756"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-866J-MV4H-26JH

Vulnerability from github – Published: 2024-04-04 09:30 – Updated: 2025-04-01 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net: veth: clear GRO when clearing XDP even when down

veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery.

The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features.

Unfortunately, this means that clearing is also skipped when XDP is disabled while the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances.

We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer.

Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-04T09:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: veth: clear GRO when clearing XDP even when down\n\nveth sets NETIF_F_GRO automatically when XDP is enabled,\nbecause both features use the same NAPI machinery.\n\nThe logic to clear NETIF_F_GRO sits in veth_disable_xdp() which\nis called both on ndo_stop and when XDP is turned off.\nTo avoid the flag from being cleared when the device is brought\ndown, the clearing is skipped when IFF_UP is not set.\nBringing the device down should indeed not modify its features.\n\nUnfortunately, this means that clearing is also skipped when\nXDP is disabled _while_ the device is down. And there\u0027s nothing\non the open path to bring the device features back into sync.\nIOW if user enables XDP, disables it and then brings the device\nup we\u0027ll end up with a stray GRO flag set but no NAPI instances.\n\nWe don\u0027t depend on the GRO flag on the datapath, so the datapath\nwon\u0027t crash. We will crash (or hang), however, next time features\nare sync\u0027ed (either by user via ethtool or peer changing its config).\nThe GRO flag will go away, and veth will try to disable the NAPIs.\nBut the open path never created them since XDP was off, the GRO flag\nwas a stray. If NAPI was initialized before we\u0027ll hang in napi_disable().\nIf it never was we\u0027ll crash trying to stop uninitialized hrtimer.\n\nMove the GRO flag updates to the XDP enable / disable paths,\ninstead of mixing them with the ndo_open / ndo_close paths.",
  "id": "GHSA-866j-mv4h-26jh",
  "modified": "2025-04-01T21:30:29Z",
  "published": "2024-04-04T09:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26803"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-875X-X5Q8-G85F

Vulnerability from github – Published: 2022-04-30 18:22 – Updated: 2025-04-03 03:51
VLAI
Details

BestCrypt BCWipe 1.0.7 and 2.0 through 2.35.1 does not clear Windows alternate data streams that are attached to files on NTFS file systems, which allows attackers to recover sensitive information that was supposed to be deleted.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2002-2066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2002-12-31T05:00:00Z",
    "severity": "MODERATE"
  },
  "details": "BestCrypt BCWipe 1.0.7 and 2.0 through 2.35.1 does not clear Windows alternate data streams that are attached to files on NTFS file systems, which allows attackers to recover sensitive information that was supposed to be deleted.",
  "id": "GHSA-875x-x5q8-g85f",
  "modified": "2025-04-03T03:51:10Z",
  "published": "2022-04-30T18:22:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2002-2066"
    },
    {
      "type": "WEB",
      "url": "http://www.bcwipe.com"
    },
    {
      "type": "WEB",
      "url": "http://www.ciac.org/ciac/bulletins/m-034.shtml"
    },
    {
      "type": "WEB",
      "url": "http://www.iss.net/security_center/static/7953.php"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/251565"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/3912"
    },
    {
      "type": "WEB",
      "url": "http://www.seifried.org/security/advisories/kssa-003.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89WC-V8X9-WRV5

Vulnerability from github – Published: 2022-01-22 00:00 – Updated: 2022-01-29 00:01
VLAI
Details

A vulnerability was found in the Linux kernel's KVM subsystem in arch/x86/kvm/lapic.c kvm_free_lapic when a failure allocation was detected. In this flaw the KVM subsystem may crash the kernel due to mishandling of memory errors that happens during VCPU construction, which allows an attacker with special user privilege to cause a denial of service. This flaw affects kernel versions prior to 5.15 rc7.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-4032"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-21T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in the Linux kernel\u0027s KVM subsystem in arch/x86/kvm/lapic.c kvm_free_lapic when a failure allocation was detected. In this flaw the KVM subsystem may crash the kernel due to mishandling of memory errors that happens during VCPU construction, which allows an attacker with special user privilege to cause a denial of service. This flaw affects kernel versions prior to 5.15 rc7.",
  "id": "GHSA-89wc-v8x9-wrv5",
  "modified": "2022-01-29T00:01:10Z",
  "published": "2022-01-22T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4032"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2027403"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7d8a19f9a056a05c5c509fa65af472a322abfee"
    },
    {
      "type": "WEB",
      "url": "https://lkml.org/lkml/2021/9/8/587"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8FR5-RQ46-Q395

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-09 09:31
VLAI
Details

Missing MinIO policy cleanup on bucket deletion via Apache CloudStack allows users to retain access to buckets which they previously owned. If another user creates a new bucket with the same name, the previous owners can gain unauthorized read and write access to it by using the previously generated access and secret keys.

Users are recommended to upgrade to Apache CloudStack versions 4.20.3.0 or 4.22.0.1, or later, which fixes this issue.

Severity
8.0 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-66467"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T13:16:35Z",
    "severity": "HIGH"
  },
  "details": "Missing MinIO policy cleanup on bucket deletion via Apache CloudStack allows users to retain access to buckets which they previously owned. If another user creates a new bucket with the same name, the previous owners can gain unauthorized read and write access to it by using the previously generated access and secret keys.\n\nUsers are recommended to upgrade to Apache CloudStack versions 4.20.3.0 or 4.22.0.1, or later, which fixes this issue.",
  "id": "GHSA-8fr5-rq46-q395",
  "modified": "2026-05-09T09:31:44Z",
  "published": "2026-05-08T15:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66467"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/n8mt5b7wkpysstb8w7rr9f02kc5cq2xm"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/09/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8FWW-64CX-X8P5

Vulnerability from github – Published: 2023-03-26 21:30 – Updated: 2024-10-25 21:45
VLAI
Summary
redis-py Race Condition due to incomplete fix
Details

redis-py through 4.5.3 and 4.4.3 leaves a connection open after canceling an async Redis command at an inopportune time (in the case of a non-pipeline operation), and can send response data to the client of an unrelated request. NOTE: this issue exists because of an incomplete fix for CVE-2023-28858.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "redis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.0"
            },
            {
              "fixed": "4.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "redis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28859"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-27T21:31:52Z",
    "nvd_published_at": "2023-03-26T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "redis-py through 4.5.3 and 4.4.3 leaves a connection open after canceling an async Redis command at an inopportune time (in the case of a non-pipeline operation), and can send response data to the client of an unrelated request. NOTE: this issue exists because of an incomplete fix for CVE-2023-28858.",
  "id": "GHSA-8fww-64cx-x8p5",
  "modified": "2024-10-25T21:45:05Z",
  "published": "2023-03-26T21:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28859"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/issues/2665"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/pull/1899"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/pull/2641"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/pull/2666"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/pull/2671"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/commit/66a4d6b2a493dd3a20cc299ab5fef3c14baad965"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/commit/b3c89acd0ffe8303649ad8207bc911b1d6a033eb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/redis/PYSEC-2023-46.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/redis/redis-py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/releases/tag/v4.4.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/redis/redis-py/releases/tag/v4.5.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "redis-py Race Condition due to incomplete fix"
}

GHSA-8FX8-PFFW-W498

Vulnerability from github – Published: 2025-01-03 16:24 – Updated: 2025-01-03 19:26
VLAI
Summary
SiYuan has an arbitrary file deletion vulnerability
Details

Summary

A arbitrary file deletion vulnerability has been identified in the latest version of Siyuan Note. The vulnerability exists in the POST /api/history/getDocHistoryContent endpoint.An attacker can craft a payload to exploit this vulnerability, resulting in the deletion of arbitrary files on the server.

Details

The vulnerability can be reproduced by sending a crafted request to the /api/history/getDocHistoryContent endpoint.

Sending a request to the /api/history/getDocHistoryContent like:

curl "http://127.0.0.1:6806/api/history/getDocHistoryContent" -X POST -H "Content-Type: application/json" -d '{"historyPath":"<abs_filepath_of_a_file>"}'

Replace <abs_filepath_of_a_file> with the absolute file path of the target file you wish to delete.

The historyPath parameter in the payload is processed by the func getDocHistoryContent in api/history.go:133.

In turn, historyPath is passed to the func GetDocHistoryContent located in model/history.go:150 , which is the slink of the vulnerability.

if historyPath exists and does not satisfy the filesys.ParseJSONWithoutFix, then it will be deleted by os.RemoveAll

func GetDocHistoryContent(historyPath, keyword string, highlight bool) (id, rootID, content string, isLargeDoc bool, err error) {
    if !gulu.File.IsExist(historyPath) {
        logging.LogWarnf("doc history [%s] not exist", historyPath)
        return
    }

    data, err := filelock.ReadFile(historyPath)
    if err != nil {
        logging.LogErrorf("read file [%s] failed: %s", historyPath, err)
        return
    }
    isLargeDoc = 1024*1024*1 <= len(data)

    luteEngine := NewLute()
    historyTree, err := filesys.ParseJSONWithoutFix(data, luteEngine.ParseOptions)
    if err != nil {
        logging.LogErrorf("parse tree from file [%s] failed, remove it", historyPath)
        os.RemoveAll(historyPath)
        return
    }
    ...
}

PoC

curl "http://127.0.0.1:6806/api/history/getDocHistoryContent" -X POST -H "Content-Type: application/json" -d '{"historyPath":"<abs_filepath_of_a_file>"}'

Impact

arbitrary file deletion vulnerability

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 0.0.0-20250103014808-d9887aeec1b2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siyuan-note/siyuan/kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-21609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459",
      "CWE-552"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-03T16:24:34Z",
    "nvd_published_at": "2025-01-03T17:15:09Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA **arbitrary file deletion vulnerability** has been identified in the latest version of Siyuan Note. The vulnerability exists in the `POST /api/history/getDocHistoryContent` endpoint.An attacker can craft a payload to exploit this vulnerability, resulting in the deletion of arbitrary files on the server.\n\n### Details\nThe vulnerability can be reproduced by sending a crafted request to the `/api/history/getDocHistoryContent` endpoint.\n\nSending a request  to the `/api/history/getDocHistoryContent` like:\n\n```\ncurl \"http://127.0.0.1:6806/api/history/getDocHistoryContent\" -X POST -H \"Content-Type: application/json\" -d \u0027{\"historyPath\":\"\u003cabs_filepath_of_a_file\u003e\"}\u0027\n```\n\nReplace `\u003cabs_filepath_of_a_file\u003e` with the absolute file path of the target file you wish to delete.\n\n\n\nThe `historyPath` parameter in the payload is processed by the `func getDocHistoryContent` in `api/history.go:133`.\n\nIn turn, `historyPath` is passed to the `func GetDocHistoryContent`  located in `model/history.go:150` , which is the slink of the vulnerability.\n\nif `historyPath` exists and does not satisfy the `filesys.ParseJSONWithoutFix`, then it will be deleted by `os.RemoveAll`\n\n```go\nfunc GetDocHistoryContent(historyPath, keyword string, highlight bool) (id, rootID, content string, isLargeDoc bool, err error) {\n\tif !gulu.File.IsExist(historyPath) {\n\t\tlogging.LogWarnf(\"doc history [%s] not exist\", historyPath)\n\t\treturn\n\t}\n\n\tdata, err := filelock.ReadFile(historyPath)\n\tif err != nil {\n\t\tlogging.LogErrorf(\"read file [%s] failed: %s\", historyPath, err)\n\t\treturn\n\t}\n\tisLargeDoc = 1024*1024*1 \u003c= len(data)\n\n\tluteEngine := NewLute()\n\thistoryTree, err := filesys.ParseJSONWithoutFix(data, luteEngine.ParseOptions)\n\tif err != nil {\n\t\tlogging.LogErrorf(\"parse tree from file [%s] failed, remove it\", historyPath)\n\t\tos.RemoveAll(historyPath)\n\t\treturn\n\t}\n\t...\n}\n```\n\n\n\n### PoC\n```\ncurl \"http://127.0.0.1:6806/api/history/getDocHistoryContent\" -X POST -H \"Content-Type: application/json\" -d \u0027{\"historyPath\":\"\u003cabs_filepath_of_a_file\u003e\"}\u0027\n```\n\n### Impact\narbitrary file deletion vulnerability\n",
  "id": "GHSA-8fx8-pffw-w498",
  "modified": "2025-01-03T19:26:05Z",
  "published": "2025-01-03T16:24:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-8fx8-pffw-w498"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21609"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/commit/d9887aeec1b27073bec66299a9a4181dc42969f3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siyuan-note/siyuan"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SiYuan has an arbitrary file deletion vulnerability"
}
Mitigation
Architecture and Design Implementation

Temporary files and other supporting resources should be deleted/released immediately after they are no longer needed.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list