Search

Search Results (409947 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-80871 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: crypto: xilinx-trng - Remove crypto_rng interface Implementing the crypto_rng interface has no purpose, as it isn't used in practice. It's being removed from other drivers too. Just remove it. This leaves hwrng, which is actually used. Tagging with 'Cc stable' due to the bugs that this removes: - xtrng_trng_generate() sometimes returned success even when it didn't fill in all the bytes. - It was possible for xtrng_trng_generate() and xtrng_hwrng_trng_read() to run concurrently and interfere with each other, as the locking code in xtrng_hwrng_trng_read() was broken.
CVE-2026-80877 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: afs: Fix vllist leak Fix a leak of the new vllist in afs_update_cell() in the event that it is an empty list (nr_servers == 0), in which case the old list isn't displaced unless the old list is also empty.
CVE-2026-80911 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked() If either tplg_ops->dai_config or widget_kcontrol_setup fail during widget setup we would double decrement the use_count of the widget because the sof_widget_free_unlocked() would be called twice, similarly the core_put would be invoked twice as well. Since the use_count and core_put() is handled within the widget_free function we need to return without falling through the pipe_widget_free label. The fixes tag is picked to the last change around this part of the code which is adequately old enough for backporting purposes.
CVE-2026-61614 1 Solidinvoice 1 Solidinvoice 2026-09-04 5.9 Medium
SolidInvoice is an open-source invoicing platform. Prior to version 3.0.1, the REST API authenticator accepts bearer tokens via a `?token=` URL query parameter as a fallback to the `X-API-TOKEN` header. This causes long-lived API credentials to be recorded in server access logs, proxy logs, browser history, and HTTP Referer headers sent to third-party origins. Version 3.0.1 fixes the issue.
CVE-2026-69502 1 Microsoft 1 Azure Sql Database 2026-09-04 10 Critical
Server-side request forgery (ssrf) in Azure SQL Database allows an unauthorized attacker to elevate privileges over a network.
CVE-2025-67041 1 Lantronix 5 Eds3000ps, Eds3008ps1ns, Eds3008ps1ns Firmware and 2 more 2026-09-04 7.2 High
An issue was discovered in Lantronix EDS3000PS 3.1.0.0R2. The host parameter of the TFTP client in the Filesystem Browser page is not properly sanitized. This can be exploited to escape from the original command and execute an arbitrary one with root privileges.
CVE-2026-64367 1 Linux 1 Linux Kernel 2026-09-04 7.8 High
In the Linux kernel, the following vulnerability has been resolved: HID: hid-goodix-spi: validate report size to prevent stack buffer overflow goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack buffer (tmp_buf), writing an 11-12 byte header followed by the caller-supplied report data. The HID core caps report size at HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set hid_ll_driver.max_buffer_size and performs no bounds checking before copying the payload: memcpy(tmp_buf + tx_len, buf, len); A hidraw SET_REPORT ioctl with a report larger than ~116 bytes overflows the stack buffer. Add a size check after constructing the header, rejecting reports that would exceed the buffer capacity. Discovered by Atuin - Automated Vulnerability Discovery Engine.
CVE-2026-64365 1 Linux 1 Linux Kernel 2026-09-04 7.8 High
In the Linux kernel, the following vulnerability has been resolved: HID: letsketch: fix UAF on inrange_timer at driver unbind letsketch_driver does not provide a .remove callback, but letsketch_probe() arms a per-device timer: timer_setup(&data->inrange_timer, letsketch_inrange_timeout, 0); The timer is re-armed from letsketch_raw_event() with a 100 ms timeout on every pen-in-range report, and its callback dereferences data->input_tablet to deliver a synthetic BTN_TOOL_PEN release. letsketch_data is allocated with devm_kzalloc(), and its input_dev fields are devm-allocated via letsketch_setup_input_tablet(). On device unbind (USB unplug or rmmod), the HID core runs its default teardown and devm cleanup frees both letsketch_data and the input devices. Because no .remove callback exists, nothing drains the timer first: if raw_event armed it within ~100 ms of the unbind, the pending timer fires on freed memory. This is a UAF read of data and of data->input_tablet, followed by input_report_key() / input_sync() into the freed input_dev. The same problem can occur on the probe error path: if hid_hw_start() enabled I/O on an always-poll-quirk device and then failed, raw_event may have armed the timer before devm releases data. Fix by adding a .remove callback that calls hid_hw_stop() first. hid_hw_stop() synchronously kills the URBs that deliver raw_event(), so once it returns no path can re-arm the timer. timer_shutdown_sync() then drains any in-flight callback and permanently disables further mod_timer() calls. Apply the same timer_shutdown_sync() in the probe error path so the timer is guaranteed not to outlive data.
CVE-2026-55401 1 Absolute 1 Secure Access 2026-09-04 5.3 Medium
CVE-2026-55401 is a null dereference vulnerability on the load-balancing sub-system of Secure Access servers prior to 14.57. Attackers can send an unauthenticated packet to a Secure Access server with load balancing enabled, which results in the internal load balancer crashing. After a successful attack, the Secure Access server is still able to accept connections and is still able to issue a failover to connected clients. ‍ https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L
CVE-2025-70082 1 Lantronix 5 Eds3000ps, Eds3008ps1ns, Eds3008ps1ns Firmware and 2 more 2026-09-04 2.7 Low
The administrator password can be changed without knowledge of the current password. When chained with an authentication bypass vulnerability, this issue may allow unauthenticated attackers to modify the administrator password.
CVE-2026-55400 1 Absolute 1 Secure Access 2026-09-04 6.5 Medium
CVE-2026-55400 is an integer underflow in Secure Access servers prior to version 14.57. Attackers with an authenticated session can send specially crafted traffic to a server in a non-default configuration and cause a persistent denial of service.
CVE-2026-55402 1 Absolute 1 Secure Access 2026-09-04 5.9 Medium
CVE-2026-55402 is an out of bounds read vulnerability in Secure Access servers prior to version 14.57. Attackers with an ‘in the middle’ position can send specially crafted data to a server causing a persistent denial of service.
CVE-2025-67039 1 Lantronix 5 Eds3000ps, Eds3008ps1ns, Eds3008ps1ns Firmware and 2 more 2026-09-04 9.8 Critical
An issue was discovered in Lantronix EDS3000PS 3.1.0.0R2. The authentication on management pages can be bypassed by appending a specific suffix to the URL and by sending an Authorization header that uses "admin" as the username.
CVE-2026-82635 2 Faberon, Tw93 2 Pake, Pake 2026-09-04 8.8 High
Pake before 3.13.1 joins the JavaScript-supplied filename for the download_file Tauri command onto the user's Downloads directory with no sanitization. A filename containing path traversal sequences (for example ../Library/LaunchAgents/com.evil.plist) or an absolute path resolves outside ~/Downloads. The command then fetches attacker-controlled content from the supplied URL (via Rust HTTP, not the browser) and writes it to that path. A script that can invoke the command can overwrite user-writable files and install persistence (macOS LaunchAgents, Linux autostart, Windows Startup), leading to code execution in the user account. All desktop apps generated from an affected Pake tree expose the same command.
CVE-2026-65643 2 Cpanel, Webpros 2 Cpanel, Cpanel 2026-09-04 8.8 High
Eval injection in cPanel 11.138.0.0 and earlier allows remote authenticated users to execute arbitrary code as root.
CVE-2026-80889 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix timer drain order, wakeup handling and tx_gen ordering This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator.
CVE-2026-80895 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: mshv: Order pt_vp_array publish against irqfd assertion path mshv_partition_ioctl_create_vp() initialises a VP struct (allocations, mutex_init, init_waitqueue_head, page mappings) and then publishes the pointer into partition->pt_vp_array. Several ISR paths read this array locklessly: the intercept ISR, the two scheduler ISRs, and mshv_try_assert_irq_fast() on the irqfd fast path. Of these, only mshv_try_assert_irq_fast() can structurally race the publish. It runs from an eventfd waker without holding pt_mutex, and MSHV_IRQFD does not require the target lapic_apic_id (== vp_index) to refer to an existing VP at registration time. A user can therefore register an irqfd targeting a yet-to-be-created VP, then trigger mshv_try_assert_irq_fast() concurrently with MSHV_CREATE_VP for the same index. On weakly-ordered architectures the reader can observe a non-NULL pointer in pt_vp_array before the initialising stores to the VP struct become visible, leading to use of partially-initialised fields (e.g. vp_register_page). The other ISR readers cannot reach this race: the hypervisor will not generate intercept or scheduler messages for a VP that has never been told to run, and the user can only call MSHV_RUN_VP on the VP fd returned by MSHV_CREATE_VP, which by construction is returned after the publish. Leave those readers as plain loads. Use smp_store_release() in mshv_partition_ioctl_create_vp() to publish the pointer, and pair it with smp_load_acquire() in mshv_try_assert_irq_fast(). On x86 these compile to plain accesses under TSO; on ARM64 they emit one-instruction acquire/release barriers, acceptable on this fast path. The destroy-side path (destroy_partition() clearing pt_vp_array[i] to NULL after kfree(vp)) has a separate ordering and lifetime concern that is out of scope here.
CVE-2026-80897 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: netfs: release readahead folios on iterator preparation failure netfs_prepare_read_iterator() batches readahead folios in put_batch so that the folio references can be dropped after the I/O iterator has been prepared. If rolling_buffer_load_from_ra() fails after earlier folios have been batched, the function returns immediately and leaves those references held. Release the batch before returning the error.
CVE-2026-80899 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: erofs: remove fscache backend entirely EROFS over fscache was introduced to provide image lazy pulling functionality. After the feature landed, the fscache subsystem made netfs a new hard dependency, which is unexpected for a local filesystem and has an kernel-defined caching hierarchy which could be inflexible compared to the fanotify pre-content hooks. Therefore, this feature has been deprecated for almost two years. As EROFS file-backed mounts and fanotify pre-content hooks both upstream for a while and already providing equivalent functionality (erofs-utils has supported fanotify pre-content hooks), let's remove the fscache backend now. The main application of this feature is Nydus [1], and they plan to move to use fanotify pre-content hooks in the near future too. I hope this patch can be merged into Linux 7.2, which is also motivated by newly found implementation issues [2][3] that are not worth investigating given the deprecation and limited development resources. The associated fscache/cachefiles cleanup patch will follow separately through the vfs tree (netfs) later: it seems fine since the codebase is isolated by CONFIG_CACHEFILES_ONDEMAND. [1] https://github.com/dragonflyoss/nydus/blob/v2.1.0/docs/nydus-fscache.md [2] https://github.com/dragonflyoss/nydus/pull/1824 [3] https://lore.kernel.org/r/[email protected]
CVE-2026-80901 1 Linux 1 Linux Kernel 2026-09-04 N/A
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix the checksum validations ip_vs_in_icmp_v6() is missing checksum validation for ICMPv6 packets from clients. In fact, as for TCP/UDP we should validate the checksum for ICMP packets only when we mangle the packets on MASQ or on reply for tunnel. Also, Sashiko points out that handle_response_icmp() being common for IPv4 and IPv6 is missing the pseudo-header calculation while validating ICMPv6 messages from real servers which is a problem if checksum is not validated by the hardware. Fix the problems by creating ip_vs_checksum_common_check() helper and use it for TCP/UDP/ICMP both for IPv4 and IPv6. Rely on the nf_checksum() for validating the ICMP messages but use it also for TCP and UDP. Use correct IP offset for IP_VS_DBG_RL_PKT for TCP/UDP/SCTP. IPVS packets (TCP/UDP/SCTP/ICMP) do not need checksum validation on LOCAL_OUT (local clients or local real servers) and on FORWARD (traffic from servers on LAN). Do it only on LOCAL_IN, in case nf_checksum() is not called on PRE_ROUTING. Also, ip_vs_checksum_complete() can be marked static.