Export limit exceeded: 407820 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (407820 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-64032 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bridge: mcast: Fix a possible use-after-free when removing a bridge port When per-VLAN multicast snooping is enabled, the bridge iterates over all the bridge ports, disables the per-port multicast context on each port and enables the per-{port, VLAN} multicast contexts instead. The reverse happens when per-VLAN multicast snooping is disabled. When global multicast snooping is enabled, the bridge iterates over all the bridge ports and enables the per-port multicast context on each port. The reverse happens when multicast snooping is disabled. The above scheme can result in a situation where both types of contexts (per-port and per-{port, VLAN}) are enabled on a single bridge port: # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev br1 type bridge mcast_vlan_snooping 1 # ip link set dev br1 type bridge mcast_snooping 0 # ip link set dev br1 type bridge mcast_snooping 1 This is not intended and it is a problem since the commit cited below. Prior to this commit, when removing a bridge port, br_multicast_disable_port() would disable the per-port multicast context and the per-{port, VLAN} multicast contexts would get disabled when flushing VLANs. After this commit, br_multicast_disable_port() only disables the per-port multicast context if per-VLAN multicast snooping is disabled. If both types of contexts were enabled on the port when it was removed, the per-port multicast context would remain enabled when freeing the bridge port, leading to a use-after-free [1]. Fix by preventing the bridge from enabling / disabling the per-port multicast contexts when toggling global multicast snooping if per-VLAN multicast snooping is enabled. [1] ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0 [...] Call Trace: <IRQ> __debug_check_no_obj_freed (lib/debugobjects.c:1116) kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565) kobject_cleanup (lib/kobject.c:689) rcu_do_batch (kernel/rcu/tree.c:2617) rcu_core (kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735) irq_exit_rcu (kernel/softirq.c:752) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47)) </IRQ> | ||||
| CVE-2026-64031 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix managed cache race for unaligned extents After unaligned compressed extents were introduced, the following race could occur: [Thread 1] [Thread 2] (z_erofs_fill_bio_vec) <handle a Z_EROFS_PREALLOCATED_FOLIO folio> ... filemap_add_folio (1) (z_erofs_bind_cache) <the same folio is found..> .. .. folio_attach_private (2) filemap_add_folio (3) again Since (1) is executed but (2) hasn't been executed yet, it's possible that another thread finds the same managed folio in z_erofs_bind_cache() for a different pcluster and calls filemap_add_folio() again since folio->private is still Z_EROFS_PREALLOCATED_FOLIO. Fix this by explicitly clearing folio->private before making the folio visible in the managed cache so that another pcluster can simply wait on the locked managed folio as what we did for other shared cases [1]. This only impacts unaligned data compression (`-E48bit` with zstd, for example). [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of crafted images properly") was originally introduced to handle crafted overlapped extents, but it addresses unaligned extents as well. | ||||
| CVE-2026-100828 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-10-13 | 9.6 Critical |
| Mitigation bypass in the Bookmarks & History component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157. | ||||
| CVE-2026-64034 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 9.3 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp() re-reads the same field from the same DMA buffer for test_bit() and pointer arithmetic. DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation. Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), and passing the validated value as a parameter to mana_hwc_handle_resp(). | ||||
| CVE-2026-109526 | 1 Hbai-ltd | 1 Toonflow-app | 2026-10-13 | 3.3 Low |
| A vulnerability has been found in HBAI-Ltd Toonflow-app up to 1.1.8. This affects an unknown function of the component exportData Endpoint. Such manipulation leads to information disclosure. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.0.0 mitigates this issue. It is advisable to upgrade the affected component. The vendor explains: "The report targets ToonFlow version 1.1.8. The current release is 2.0.4, which is the result of a substantial architectural refactor; the code paths referenced in the report do not apply to the current version. The report does not describe a vulnerability in any supported release." | ||||
| CVE-2026-109955 | 1 Hono | 1 Hono | 2026-10-13 | 5.3 Medium |
| Hono from 4.12.4 before 4.13.11 contains a middleware bypass vulnerability in serveStatic that allows unauthenticated attackers to skip prefix middleware by exploiting double path decoding. Attackers can send malformed percent-encoded paths that the router matches in encoded form, reaching static files without authentication checks running. | ||||
| CVE-2026-109956 | 1 Nltk | 1 Nltk | 2026-10-13 | 7 High |
| NLTK through 3.10.3 contains a path traversal vulnerability in WekaClassifier that allows attackers to bypass nltk.pathsec containment by supplying unvalidated model paths. Attackers controlling the model_filename or model argument can make the weka JVM write files via -d or probe files via -l outside allowed data roots. | ||||
| CVE-2026-93346 | 1 Wazuh | 2 Wazuh, Wazuh-manager | 2026-10-13 | 5.3 Medium |
| Wazuh from 4.0.0 before 4.14.8 contains a race condition in API login throttling that allows unauthenticated attackers to bypass max_login_attempts by sending concurrent requests. Attackers can fire concurrent login bursts to the authenticate and run_as endpoints, each passing the block check before failures are counted, enabling unlimited password guessing. | ||||
| CVE-2026-74037 | 1 Wazuh | 2 Wazuh, Wazuh-manager | 2026-10-13 | 7.2 High |
| Wazuh 4.0.0 before 4.14.8 fails to invalidate issued tokens for run_as users with zero static roles, because check_token never consults the blacklist. Attackers with revoked administrator grants can continue authenticating and self-link the administrator role to permanently retain privileged access. | ||||
| CVE-2026-74040 | 1 Wazuh | 2 Wazuh, Wazuh-manager | 2026-10-13 | 9.1 Critical |
| Wazuh versions from 3.9.0 before 4.14.8 contain an arbitrary file overwrite vulnerability in MasterHandler.process_files_from_worker allowing a cluster worker to overwrite protected master files. Attackers controlling a worker can use a trailing-slash basename bypass and missing extra_valid enforcement to overwrite ossec.conf and agent.conf, achieving root remote code execution across the manager and every agent. | ||||
| CVE-2026-100829 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-10-13 | 9.6 Critical |
| Mitigation bypass in the DOM: Security component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157. | ||||
| CVE-2026-100830 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-10-13 | 8.1 High |
| Mitigation bypass in the DOM: Navigation component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157. | ||||
| CVE-2026-100831 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-10-13 | 8.8 High |
| Use-after-free in the DOM: UI Events & Focus Handling component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 153.4, and Firefox 157. | ||||
| CVE-2026-64029 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Serialize UMP output teardown with event_input seq_ump_process_event() borrows client->out_rfile.output without synchronizing with the first-open and last-close transition in seq_ump_client_open() and seq_ump_client_close(). The last output unuse can therefore drop opened[STR_OUT] to zero and release the rawmidi file while an in-flight event_input callback is still inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream runtime exposed to teardown before the write path has taken its own buffer reference. Add a per-client rwlock for the event_input-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through snd_rawmidi_kernel_write(). The last output close copies and clears the visible output file under the write side, then drops the lock and releases the saved rawmidi file. Use IRQ-safe rwlock guards because event_input can also be reached from atomic sequencer delivery. The buggy scenario involves two paths, with each column showing the order within that path: path A label: event_input path path B label: last unuse path 1. seq_ump_process_event() reads 1. seq_ump_client_close() client->out_rfile.output. drops opened[STR_OUT] to zero. 2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release() has not yet pinned runtime. closes the output file. 3. The writer continues using 3. close_substream() frees the borrowed substream. substream->runtime. This keeps the output substream and runtime alive for the full event_input write while keeping rawmidi release outside the rwlock. KASAN reproduced this as a slab-use-after-free in snd_rawmidi_kernel_write1(), with allocation through seq_ump_use()/snd_seq_port_connect() and free through seq_ump_unuse()/snd_seq_port_disconnect(). Validation reproduced this kernel report: KASAN slab-use-after-free in snd_rawmidi_kernel_write1+0x9d/0x400 RIP: 0033:0x7f5528af837f Read of size 8 Call trace: dump_stack_lvl+0x73/0xb0 (?:?) print_report+0xd1/0x650 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x1a7/0x340 (?:?) kasan_complete_mode_report_info+0x64/0x200 (?:?) kasan_report+0xf7/0x130 (?:?) snd_rawmidi_kernel_write1+0x9d/0x400 (?:?) __asan_load8+0x82/0xb0 (?:?) update_stack_state+0x1ef/0x2d0 (?:?) snd_rawmidi_kernel_write+0x1a/0x20 (?:?) seq_ump_process_event+0xd4/0x120 (sound/core/seq/seq_ump_client.c:82) __snd_seq_deliver_single_event+0x8a/0xe0 (?:?) snd_seq_deliver_from_ump+0x2b2/0xd60 (?:?) lock_acquire+0x14e/0x2e0 (?:?) find_held_lock+0x31/0x90 (?:?) snd_seq_port_use_ptr+0xa6/0xe0 (?:?) __kasan_check_write+0x18/0x20 (?:?) do_raw_read_unlock+0x32/0xa0 (?:?) _raw_read_unlock+0x26/0x50 (?:?) snd_seq_deliver_single_event+0x45c/0x4b0 (?:?) snd_seq_deliver_event+0x10d/0x1b0 (?:?) snd_seq_client_enqueue_event+0x192/0x240 (?:?) snd_seq_write+0x2cd/0x450 (?:?) apparmor_file_permission+0x20/0x30 (?:?) security_file_permission+0x51/0x60 (?:?) vfs_write+0x1ce/0x850 (?:?) __fget_files+0x12b/0x220 (?:?) lock_release+0xc8/0x2a0 (?:?) __rcu_read_unlock+0x74/0x2d0 (?:?) __fget_files+0x135/0x220 (?:?) ksys_write+0x15a/0x180 (?:?) rcu_is_watching+0x24/0x60 (?:?) __x64_sys_write+0x46/0x60 (?:?) x64_sys_call+0x7d/0x20d0 (?:?) do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) | ||||
| CVE-2025-59838 | 1 Monkeytype | 1 Monkeytype | 2026-10-13 | 5.4 Medium |
| Monkeytype is a minimalistic and customizable typing test. In versions 25.36.0 and prior, improper handling of user input when loading a saved custom text results in XSS. This issue has been fixed in version 25.44.0. | ||||
| CVE-2026-64028 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Avoid NULL return from hist_field_name() on truncation hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow. | ||||
| CVE-2026-64027 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: shaper: rework the VALID marking (again) Recent commit changed the semantics from NOT_VALID to VALID. I didn't realize that the flags are not stored atomically with the entry in XArray. There's still a race of reader observing a VALID mark for a slot, getting interrupted, writer replacing the entry with a different one, reader continuing, fetching the entry which is now a different pointer than the pointer for which VALID was meant. The biggest consequence of this is that we may see a UAF since net_shaper_rollback() assumed that entries without VALID can be freed without observing RCU. Looks like the XArray marks are buying us nothing at this point. Let's convert the code to an explicit valid field. The smp_load_acquire() / smp_store_release() barriers are marginally cleaner. | ||||
| CVE-2026-97334 | 2026-10-13 | N/A | ||
| The network messaging layer contained improper handling of highly compressed data affecting service availability. Software customers upgrade to resolved maintenance release. Update all Commvault installations, including CommServe server, Web Server, Command Center, MediaAgents, clients, and HyperScale. | ||||
| CVE-2026-97333 | 2026-10-13 | N/A | ||
| QAPI contained a stack-based buffer overflow affecting service availability. Software customers upgrade to resolved maintenance release. Update CommServe, Web Server, Command Center and Index Server. | ||||
| CVE-2026-96119 | 1 Ibm | 1 I | 2026-10-13 | 9.9 Critical |
| IBM i 7.3, 7.4, 7.5, and 7.6 could allow a remote authenticated attacker to obtain sensitive information or execute arbitrary code on the system due to improper data sanitization by the HTTP Server Administration web application. | ||||