Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-22120 State: PUBLISHED Published: 2025-04-16T14:13:05.289Z Last Updated: 2025-05-26T05:18:54.234Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: goto right label 'out_mmap_sem' in ext4_setattr() Otherwise, if ext4_inode_attach_jinode() fails, a hung task will happen because filemap_invalidate_unlock() isn't called to unlock mapping->invalidate_lock. Like this: EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory INFO: task fsstress:374 blocked for more than 122 seconds. Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this messa
nted 6.14.0-rc1-next-20250206-xfstests-dirty #726 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:fsstress state:D stack:0 pid:374 tgid:374 ppid:373 task_flags:0x440140 flags:0x00000000 Call Trace: <TASK> __schedule+0x2c9/0x7f0 schedule+0x27/0xa0 schedule_preempt_disabled+0x15/0x30 rwsem_down_read_slowpath+0x278/0x4c0 down_read+0x59/0xb0 page_cache_ra_unbounded+0x65/0x1b0 filemap_get_pages+0x124/0x3e0 filemap_read+0x114/0x3d0 vfs_read+0x297/0x360 ksys_read+0x6c/0xe0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e References: - https://git.kernel.org/stable/c/551667f99bcf04fa58594d7d19aef73c861a1200 - https://git.kernel.org/stable/c/45314999f95
- https://git.kernel.org/stable/c/551667f99bcf04fa58594d7d19aef73c861a1200 - https://git.kernel.org/stable/c/45314999f950321a341033ae8f9ac12dce40669b - https://git.kernel.org/stable/c/32d872e3905746ff1048078256cb00f946b97d8a - https://git.kernel.org/stable/c/7e91ae31e2d264155dfd102101afc2de7bd74a64
CVE ID: CVE-2025-22121 State: PUBLISHED Published: 2025-04-16T14:13:05.894Z Last Updated: 2025-11-24T09:49:43.810Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/
ack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c
mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff
00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification. References: - https://git.kernel.org/stable/c/098927a13fd918bd7c64c2de905350a1ad7b4a3a - https://git.kernel.org/stable/c/0c8fbb6ffb3c8f5164572ca88e4ccb6cd6a41ca8 - https://git.kernel.org/sta
905350a1ad7b4a3a - https://git.kernel.org/stable/c/0c8fbb6ffb3c8f5164572ca88e4ccb6cd6a41ca8 - https://git.kernel.org/stable/c/5701875f9609b000d91351eaa6bfd97fe2f157f4
CVE ID: CVE-2025-22122 State: PUBLISHED Published: 2025-04-16T14:13:06.509Z Last Updated: 2025-06-10T11:33:22.714Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: fix adding folio to bio >4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage is supported, then 'offset' of folio can't be held in 'unsigned int', cause warning in bio_add_folio_nofail() and IO failure. Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't be overflow, and folio can be added to bio successfully. References: - https://git.kernel.org/stable/c/0c60158ff14df04c92792dd9b1809372b095040f - https://git.kernel.org/sta
lly. References: - https://git.kernel.org/stable/c/0c60158ff14df04c92792dd9b1809372b095040f - https://git.kernel.org/stable/c/b96e0af1b1c99cb7e6188b6fa4963a4e47beb01e - https://git.kernel.org/stable/c/26064d3e2b4d9a14df1072980e558c636fb023ea
CVE ID: CVE-2025-22123 State: PUBLISHED Published: 2025-04-16T14:13:07.213Z Last Updated: 2025-06-10T11:33:23.410Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid accessing uninitialized curseg syzbot reports a f2fs bug as below: F2FS-fs (loop3): Stopped filesystem due to reason: 7 kworker/u8:7: attempt to access beyond end of device BUG: unable to handle page fault for address: ffffed1604ea3dfa RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline] RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline] RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline] RIP: 0010:has_not_enough_free
s/f2fs/segment.h:570 [inline] RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline] RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline] RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649 <TASK> f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline] f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791 write_inode fs/fs-writeback.c:1525 [inline] __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745 writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976 wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156 wb_do_writeback fs/fs-writeback.c:2303 [inline] wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343 process_one_work kernel/workqueue.c:3236 [inline] process_sche
03 [inline] wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger no free segment fault in allocator, then it will update curseg->segno to NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed to check the flag, and access invalid curseg->segno directly in below call path, then resulting in panic:
node() missed to check the flag, and access invalid curseg->segno directly in below call path, then resulting in panic: - f2fs_write_inode - f2fs_is_checkpoint_ready - has_enough_free_secs - has_not_enough_free_secs - __get_secs_required - has_curseg_enough_space - get_ckpt_valid_blocks : access invalid curseg->segno To avoid this issue, let's: - check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in f2fs_write_inode(). - in has_curseg_enough_space(), save curseg->segno into a temp variable, and verify its validation before use. References: - https://git.kernel.org/stable/c/bf49527089ec1ba894c6e587affabbfb2329f52e - https://git.kernel.org/stable/c/7f90e5d423cd2d4c74b2abb527872f33
org/stable/c/bf49527089ec1ba894c6e587affabbfb2329f52e - https://git.kernel.org/stable/c/7f90e5d423cd2d4c74b2abb527872f335108637f - https://git.kernel.org/stable/c/986c50f6bca109c6cf362b4e2babcb85aba958f6
CVE ID: CVE-2025-22124 State: PUBLISHED Published: 2025-04-16T14:13:08.134Z Last Updated: 2025-09-09T17:05:52.349Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal
its [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct. References: - https://git.kernel.org/stable/c/60196f92bbc7901eb5cfa5d456651b87ea50a4a3 - https://git.kernel.org/stable/c/bc3a9788961631359527763d7e1fcf26554c7cb1 - https://git.kernel.org/stable/c/6130825f34d4
https://git.kernel.org/stable/c/bc3a9788961631359527763d7e1fcf26554c7cb1 - https://git.kernel.org/stable/c/6130825f34d41718c98a9b1504a79a23e379701e
CVE ID: CVE-2025-22125 State: PUBLISHED Published: 2025-04-16T14:13:08.779Z Last Updated: 2025-09-09T17:05:53.880Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cle
e REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT") References: - https://git.kernel.org/stable/c/73506e581c0b1814cdfd2229d589f30751d7de26 - https://git.kernel.org/stable/c/8a0adf3d778c4a0893c6d34a9e1b0082a6f1c495 - https://git.kernel.org/stable/c/e879a0d9cb086c8e52ce6c04e5bfa63825a6213c
CVE ID: CVE-2025-22126 State: PUBLISHED Published: 2025-04-16T14:13:09.399Z Last Updated: 2025-11-03T19:42:14.519Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev
ev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ca9f84de76723b358dfc0606668efdca54afc2e5 - https://git.kernel.org/sta
ner: References: - https://git.kernel.org/stable/c/ca9f84de76723b358dfc0606668efdca54afc2e5 - https://git.kernel.org/stable/c/d69a23d8e925f8052d657652a6875ec2712c7e33 - https://git.kernel.org/stable/c/e2a9f73ee408a460f4c9dfe03b4741d6b11652b8 - https://git.kernel.org/stable/c/5462544ccbad3fc938a71b01fa5bd3a0dc2b750a - https://git.kernel.org/stable/c/8542870237c3a48ff049b6c5df5f50c8728284fa
CVE ID: CVE-2025-22127 State: PUBLISHED Published: 2025-04-16T14:13:10.015Z Last Updated: 2025-05-26T05:19:03.761Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadloop in prepare_compress_overwrite() Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extensi
pression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: <TASK> __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x2
__f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO er
sks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages(). References: - https://git.kernel.org/stable/c/7215cf8ef54bdc9082dffac4662416d54961e258 - https://git.kernel.org/stable/c/3147ee567dd9004a49826ddeaf0a4b12865d4409
CVE ID: CVE-2025-22128 State: PUBLISHED Published: 2025-04-16T14:13:10.692Z Last Updated: 2025-06-27T10:21:16.498Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the I
This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: /* make sure affinity_hint is cleaned up */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. References: - https://git.kernel.org/stable/c/a69a594794fcad96d4cfce12aab6c5014a12b4c8 - https://git.kernel.org/stable/c/35b33ba76765ce9e72949d957f3cf1feafd2955c - https://git.kernel.org/stable/c/b43b1e2c52db77c872bd60d30
kernel.org/stable/c/35b33ba76765ce9e72949d957f3cf1feafd2955c - https://git.kernel.org/stable/c/b43b1e2c52db77c872bd60d30cdcc72c47df70c7
CVE ID: CVE-2025-22129 State: PUBLISHED Published: 2025-02-03T21:28:55.188Z Last Updated: 2025-02-04T18:41:39.965Z Severity: MEDIUM (CVSS 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) Vendors: Enalean Products: tuleap Problem Types: CWE-280 Description: Tuleap is an Open Source Suite to improve management of software developments and collaboration. In affected versions an unauthorized user might get access to restricted information. This issue has been addressed in Tuleap Community Edition 16.3.99.1736242932, Tuleap Enterprise Edition 16.2-5, and Tuleap Enterprise Edition 16.3-2. Users are advised to upgrade. There are no known workarounds for this vulnerability. Additional Analyst Notes
on 16.3-2. Users are advised to upgrade. There are no known workarounds for this vulnerability. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/Enalean/tuleap/security/advisories/GHSA-f34g-wc2m-mf76 - https://tuleap.net/plugins/git/tuleap/tuleap/stable?a=commit&h=3edf8158ba40be66f0b661888b8b2805784795d1 - https://tuleap.net/plugins/tracker/?aid=41434
CVE ID: CVE-2025-22130 State: PUBLISHED Published: 2025-01-08T15:43:05.244Z Last Updated: 2025-01-08T19:16:13.209Z Vendors: charmbracelet Products: soft-serve Problem Types: CWE-22 Description: Soft Serve is a self-hostable Git server for the command line. Prior to 0.8.2 , a path traversal attack allows existing non-admin users to access and take over other user's repositories. A malicious user then can modify, delete, and arbitrarily repositories as if they were an admin user without explicitly giving them permissions. This is patched in v0.8.2. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-j4jw-m6xr-fv6
CISA ADP Vulnrichment: References: - https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-j4jw-m6xr-fv6c - https://github.com/charmbracelet/soft-serve/commit/a8d1bf3f9349c138383b65079b7b8ad97fff78f4 - https://github.com/charmbracelet/soft-serve/releases/tag/v0.8.2
CVE ID: CVE-2025-22131 State: PUBLISHED Published: 2025-01-20T15:31:19.693Z Last Updated: 2025-01-21T14:58:15.541Z Vendors: PHPOffice Products: PhpSpreadsheet Problem Types: CWE-79 Description: PhpSpreadsheet is a PHP library for reading and writing spreadsheet files. Cross-Site Scripting (XSS) vulnerability in the code which translates the XLSX file into a HTML representation and displays it in the response. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-79xx-vf93-p7cx - https://github.com/PHPOffice/PhpSpreadsheet/commit/4088381ccfaf241d7d42c333de0dc8c98e338743
CVE ID: CVE-2025-22132 State: PUBLISHED Published: 2025-01-07T22:04:41.805Z Last Updated: 2025-01-08T15:34:50.893Z Severity: HIGH (CVSS 8.3 CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:L) Vendors: nilsonLazarin Products: WeGIA Problem Types: CWE-79, CWE-434 Description: WeGIA is a web manager for charitable institutions. A Cross-Site Scripting (XSS) vulnerability was identified in the file upload functionality of the WeGIA/html/socio/sistema/controller/controla_xlsx.php endpoint. By uploading a file containing malicious JavaScript code, an attacker can execute arbitrary scripts in the context of a victim's browser. This can lead to information theft, session hijacking, and other forms of clien
ts in the context of a victim's browser. This can lead to information theft, session hijacking, and other forms of client-side exploitation. This vulnerability is fixed in 3.2.7. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/nilsonLazarin/WeGIA/security/advisories/GHSA-h8hr-jhcx-fcv9 - https://github.com/nilsonLazarin/WeGIA/commit/330f641db43cfb0c8ea8bb6025cc0732de4d4d6b
CVE ID: CVE-2025-22133 State: PUBLISHED Published: 2025-01-07T22:07:13.958Z Last Updated: 2025-01-08T14:52:28.078Z Severity: CRITICAL (CVSS 10 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) Vendors: nilsonLazarin Products: WeGIA Problem Types: CWE-94, CWE-434 Description: WeGIA is a web manager for charitable institutions. Prior to 3.2.8, a critical vulnerability was identified in the /WeGIA/html/socio/sistema/controller/controla_xlsx.php endpoint. The endpoint accepts file uploads without proper validation, allowing the upload of malicious files, such as .phar, which can then be executed by the server. This vulnerability is fixed in 3.2.8. Additional Analyst Notes: - CISA ADP Vulnrichment: R
en be executed by the server. This vulnerability is fixed in 3.2.8. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/nilsonLazarin/WeGIA/security/advisories/GHSA-mjgr-2jxv-v8qf - https://github.com/nilsonLazarin/WeGIA/commit/a08f04de96d3caec85496d7a89a5b82d1960d9dd
CVE ID: CVE-2025-22134 State: PUBLISHED Published: 2025-01-13T20:41:08.144Z Last Updated: 2025-03-14T10:03:08.447Z Severity: MEDIUM (CVSS 4.2 CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L) Vendors: vim Products: vim Problem Types: CWE-122 Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the po
dows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003 Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://github.com/vim/vim/security/advisories/GHSA-5rgf-26wj-48v8 - https://github.com/vim/vim/commit/c9a1e257f1630a0866447e53a564f7ff96a80ead
CVE ID: CVE-2025-22136 State: PUBLISHED Published: 2025-01-08T16:02:01.460Z Last Updated: 2025-01-08T19:25:39.232Z Vendors: Eugeny Products: tabby Problem Types: CWE-94 Description: Tabby (formerly Terminus) is a highly configurable terminal emulator. Prior to 1.0.217 , Tabby enables several high-risk Electron Fuses, including RunAsNode, EnableNodeCliInspectArguments, and EnableNodeOptionsEnvironmentVariable. These fuses create potential code injection vectors even though the application is signed with hardened runtime and lacks dangerous entitlements such as com.apple.security.cs.disable-library-validation and com.apple.security.cs.allow-dyld-environment-variables. This vulnerability is fix
rity.cs.disable-library-validation and com.apple.security.cs.allow-dyld-environment-variables. This vulnerability is fixed in 1.0.217. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/Eugeny/tabby/security/advisories/GHSA-prcj-7rvc-26h4 - https://github.com/Eugeny/tabby/commit/93513541f7161fa8a59491603cabb6a101c0c08e