Total
94370 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-22115 | 2025-07-24 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix block group refcount race in btrfs_create_pending_block_groups() Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'. However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent. The broken refcount aspect will result in a warning like: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] <TASK> [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] </TASK> [1272.961238] ---[ end trace 0000000000000000 ]--- Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc. Fix this fully by taking the lock arou ---truncated--- | |||||
| CVE-2025-54371 | 2025-07-23 | N/A | N/A | ||
| Rejected reason: This CVE is a duplicate of another CVE. | |||||
| CVE-2025-41662 | 2025-07-23 | N/A | N/A | ||
| Rejected reason: CVE-2025-41662 is considered redundant or unnecessary and thus should be withdrawn. Instead, a new CVE CVE-2025-41687 has been reserved to better reflect the updated analysis. | |||||
| CVE-2025-53640 | 2025-07-22 | N/A | N/A | ||
| Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Starting in version 2.2 and prior to version 3.3.7, an endpoint used to display details of users listed in certain fields (such as ACLs) could be misused to dump basic user details (such as name, affiliation and email) in bulk. Version 3.3.7 fixes the issue. Owners of instances that allow everyone to create a user account, who wish to truly restrict access to these user details, should consider restricting user search to managers. As a workaround, it is possible to restrict access to the affected endpoints (e.g. in the webserver config), but doing so would break certain form fields which could no longer show the details of the users listed in those fields, so upgrading instead is highly recommended. | |||||
| CVE-2025-7783 | 2025-07-22 | N/A | N/A | ||
| Use of Insufficiently Random Values vulnerability in form-data allows HTTP Parameter Pollution (HPP). This vulnerability is associated with program files lib/form_data.Js. This issue affects form-data: < 2.5.4, 3.0.0 - 3.0.3, 4.0.0 - 4.0.3. | |||||
| CVE-2025-53892 | 2025-07-22 | N/A | N/A | ||
| Vue I18n is the internationalization plugin for Vue.js. The escapeParameterHtml: true option in Vue I18n is designed to protect against HTML/script injection by escaping interpolated parameters. However, starting in version 9.0.0 and prior to versions 9.14.5, 10.0.8, and 11.1.0, this setting fails to prevent execution of certain tag-based payloads, such as <img src=x onerror=...>, if the interpolated value is inserted inside an HTML context using v-html. This may lead to a DOM-based XSS vulnerability, even when using escapeParameterHtml: true, if a translation string includes minor HTML and is rendered via v-html. Versions 9.14.5, 10.0.8, and 11.1.0 contain a fix for the issue. | |||||
| CVE-2025-49604 | 2025-07-22 | N/A | N/A | ||
| Rejected reason: DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none. | |||||
| CVE-2025-7397 | 2025-07-22 | N/A | N/A | ||
| A vulnerability in the ascgshell, of Brocade ASCG before 3.3.0 stores any command executed in the Command Line Interface (CLI) in plain text within the command history. A local authenticated user that can access sensitive information like passwords within the CLI history leading to unauthorized access and potential data breaches. | |||||
| CVE-2025-53888 | 2025-07-22 | N/A | N/A | ||
| RIOT-OS, an operating system that supports Internet of Things devices, has an ineffective size check implemented with `assert()` can lead to buffer overflow in versions up to and including 2025.04. Assertions are usually compiled out in production builds. If assertions are the only defense against untrusted inputs, the software may be exposed to attacks that utilize the lack of proper input checks. In the `l2filter_add()` function shown below, `addr_len` is checked using an assertion and is subsequently used as an argument in a `memcpy()` call. When assertions are disabled, there would be no size check for `addr_len`. As a consequence, if an attacker were to provide an `addr_len` value larger than `CONFIG_L2FILTER_ADDR_MAXLEN`, they can trigger a buffer overflow and write past the `list[i].addr` buffer. If the unchecked input is attacker-controlled, the impact of the buffer overflow can range from a denial of service to arbitrary code execution. Commit f6f7de4ccc107c018630e4c15500825caf02e1c2 contains a patch for the vulnerability. | |||||
| CVE-2025-49485 | 2025-07-22 | N/A | N/A | ||
| A SQL injection vulnerability in the Balbooa Forms plugin 1.0.0-2.3.1.1 for Joomla allows privileged users to execute arbitrary SQL commands via the 'id' parameter. | |||||
| CVE-2025-50057 | 2025-07-22 | N/A | N/A | ||
| A DOS vulnerability in RSFiles! component 1.16.3-1.17.7 Joomla was discovered. The issue allows unauthenticated remote attackers to deny access to service via the search feature. | |||||
| CVE-2025-50058 | 2025-07-22 | N/A | N/A | ||
| A stored XSS vulnerability in the RSDirectory! component 1.0.0-2.2.8 Joomla was discovered. The issue allows remote authenticated attackers to inject arbitrary web script or HTML via the review reply component. | |||||
| CVE-2025-50126 | 2025-07-22 | N/A | N/A | ||
| A stored XSS vulnerability in the RSBlog! component 1.11.6-1.14.5 Joomla was discovered. The issue allows remote authenticated users to inject arbitrary web script or HTML via the jform[tags_text] parameter. | |||||
| CVE-2025-50056 | 2025-07-22 | N/A | N/A | ||
| A reflected XSS vulnerability in RSMail! component 1.19.20 - 1.22.26 28 Joomla was discovered. The issue allows remote attackers to inject arbitrary web script or HTML via the crafted parameter. | |||||
| CVE-2025-7398 | 2025-07-22 | N/A | N/A | ||
| Brocade ASCG before 3.3.0 allows for the use of medium strength cryptography algorithms on internal ports ports 9000 and 8036. | |||||
| CVE-2025-49486 | 2025-07-22 | N/A | N/A | ||
| A stored XSS vulnerability in the Balbooa Gallery plugin 1.0.0-2.4.0 for Joomla allows privileged users to store malicious scripts in gallery items. | |||||
| CVE-2025-6391 | 2025-07-22 | N/A | N/A | ||
| Brocade ASCG before 3.3.0 logs JSON Web Tokens (JWT) in log files. An attacker with access to the log files can withdraw the unencrypted tokens with security implications, such as unauthorized access, session hijacking, and information disclosure. | |||||
| CVE-2025-2425 | 2025-07-22 | N/A | N/A | ||
| Time-of-check to time-of-use race condition vulnerability potentially allowed an attacker to use the installed ESET security software to clear the content of an arbitrary file on the file system. | |||||
| CVE-2025-38350 | 2025-07-22 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: net/sched: Always pass notifications when child class becomes empty Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free. The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free: tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent. | |||||
| CVE-2025-4049 | 2025-07-22 | N/A | N/A | ||
| Use of hard-coded, the same among all vulnerable installations SQLite credentials vulnerability in SIGNUM-NET FARA allows to read and manipulate local-stored database.This issue affects FARA: through 5.0.80.34. | |||||