Search
Search Results (16 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-90130 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: vdpa_sim: fix cleanup after worker creation failure vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance. | ||||
| CVE-2026-89996 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ | ||||
| CVE-2026-89087 | 1 Ocaml | 1 Cstruct | 2026-09-14 | 7.3 High |
| The cstruct package before 6.3.0 for OCaml mishandles indexes. | ||||
| CVE-2026-59998 | 1 Openbsd | 1 Openssh | 2026-07-08 | 4.8 Medium |
| sshd in OpenSSH before 10.4 has an undocumented security-relevant behavior: GSSAPIStrictAcceptorCheck has no value if the server is in Windows Active Directory. | ||||
| CVE-2026-23033 | 1 Linux | 1 Linux Kernel | 2026-06-02 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource. | ||||
| CVE-2026-41583 | 2 Zcashfoundation, Zfnd | 3 Zebra, Zebra-script, Zebrad | 2026-05-09 | 9.1 Critical |
| ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the "canonical" hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2. | ||||
| CVE-2026-23168 | 1 Linux | 1 Linux Kernel | 2026-04-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: flex_proportions: make fprop_new_period() hardirq safe Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race: <timer fires> run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); <hardirq is raised> ... blk_mq_end_request() blk_update_request() ext4_end_bio() folio_end_writeback() __wb_writeout_add() __fprop_add_percpu_max() if (unlikely(max_frac < FPROP_FRAC_BASE)) { fprop_fraction_percpu() seq = read_seqcount_begin(&p->sequence); - sees odd sequence so loops indefinitely Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis. To fix this problem we have to make sure write section of the sequence counter is irqsafe. | ||||
| CVE-2025-69287 | 1 Bsv-blockchain | 1 Ts-sdk | 2026-04-15 | 5.4 Medium |
| The BSV Blockchain SDK is a unified TypeScript SDK for developing scalable apps on the BSV Blockchain. Prior to version 2.0.0, a cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility between SDK implementations and potential authentication bypass scenarios. The vulnerability was located in the `Peer.ts` file of the TypeScript SDK, specifically in the `processInitialRequest` and `processInitialResponse` methods where signature data is prepared for BRC-104 mutual authentication. The TypeScript SDK incorrectly prepared signature data by concatenating base64-encoded nonce strings (`message.initialNonce + sessionNonce`) then decoding the concatenated base64 string (`base64ToBytes(concatenatedString)`). This produced ~32-34 bytes of signature data instead of the correct 64 bytes. BRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect, signatures generated by the TypeScript SDK don't match those expected by Go/Python SDKs; cross-implementation authentication fails; and an attacker could potentially exploit this to bypass authentication checks. The fix in version 2.0.0 ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations. | ||||
| CVE-2024-34995 | 1 Svnwebui | 1 Svnwebui | 2026-04-15 | 4.3 Medium |
| svnWebUI v1.8.3 was discovered to contain an arbitrary file deletion vulnerability via the dirTemps parameter under com.cym.controller.UserController#importOver. This vulnerability allows attackers to delete arbitrary files via a crafted POST request. | ||||
| CVE-2026-28498 | 1 Authlib | 1 Authlib | 2026-03-24 | 7.5 High |
| Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.9, a library-level vulnerability was identified in the Authlib Python library concerning the validation of OpenID Connect (OIDC) ID Tokens. Specifically, the internal hash verification logic (_verify_hash) responsible for validating the at_hash (Access Token Hash) and c_hash (Authorization Code Hash) claims exhibits a fail-open behavior when encountering an unsupported or unknown cryptographic algorithm. This flaw allows an attacker to bypass mandatory integrity protections by supplying a forged ID Token with a deliberately unrecognized alg header parameter. The library intercepts the unsupported state and silently returns True (validation passed), inherently violating fundamental cryptographic design principles and direct OIDC specifications. This issue has been patched in version 1.6.9. | ||||
| CVE-2025-69202 | 1 Axios-cache-interceptor | 1 Axios Cache Interceptor | 2026-01-05 | 6.5 Medium |
| Axios Cache Interceptor is a cache interceptor for axios. Prior to version 1.11.1, when a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass. The cache key is generated only from the URL, ignoring request headers like `Authorization`. When the server responds with `Vary: Authorization` (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization. Server-side applications (APIs, proxies, backend services) that use axios-cache-interceptor to cache requests to upstream services, handle requests from multiple users with different auth tokens, and upstream services replies on `Vary` to differentiate caches are affected. Browser/client-side applications (single user per browser session) are not affected. Services using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions. After `v1.11.1`, automatic `Vary` header support is now enabled by default. When server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache. | ||||
| CVE-2024-32633 | 1 Asrmicro | 26 Asr1602, Asr1602 Firmware, Asr1603 and 23 more | 2025-12-10 | 4 Medium |
| An unsigned value can never be negative, so eMMC full disk test will always evaluate the same way. | ||||
| CVE-2025-21601 | 1 Juniper | 1 Junos | 2025-08-11 | 7.5 High |
| An Improper Following of Specification by Caller vulnerability in web management (J-Web, Captive Portal, 802.1X, Juniper Secure Connect (JSC) of Juniper Networks Junos OS on SRX Series, EX Series, MX240, MX480, MX960, QFX5120 Series, allows an unauthenticated, network-based attacker, sending genuine traffic targeted to the device to cause the CPU to climb until the device becomes unresponsive. Continuous receipt of these packets will create a sustained Denial of Service (DoS) condition. This issue affects Junos OS: * All versions before 21.4R3-S9, * from 22.2 before 22.2R3-S5, * from 22.4 before 22.4R3-S4, * from 23.2 before 23.2R2-S3, * from 23.4 before 23.4R2-S3, * from 24.2 before 24.2R1-S1, 24.2R2. An indicator of compromise is to review the CPU % of the httpd process in the CLI: e.g. show system processes extensive | match httpd PID nobody 52 0 20M 191M select 2 0:01 80.00% httpd{httpd} <<<<< the percentage of httpd usage if high may be an indicator | ||||
| CVE-2025-46330 | 1 Snowflake | 1 Connector For C\/c\+\+ | 2025-05-09 | 3.3 Low |
| libsnowflakeclient is the Snowflake Connector for C/C++. Versions starting from 0.5.0 to before 2.2.0, incorrectly treat malformed requests that caused the HTTP response status code 400, as able to be retried. This could hang the application until SF_CON_MAX_RETRY requests were sent. This issue has been patched in version 2.2.0. | ||||
| CVE-2022-31017 | 1 Zulip | 1 Zulip | 2025-04-23 | 2 Low |
| Zulip is an open-source team collaboration tool. Versions 2.1.0 through and including 5.2 are vulnerable to a logic error. A stream configured as private with protected history, where new subscribers should not be allowed to see messages sent before they were subscribed, when edited causes the server to incorrectly send an API event that includes the edited message to all of the stream’s current subscribers. This API event is ignored by official clients, but can be observed by using a modified client or the browser’s developer tools. This bug will be fixed in Zulip Server 5.3. There are no known workarounds. | ||||
| CVE-2019-14829 | 1 Moodle | 1 Moodle | 2024-11-21 | 4.3 Medium |
| A vulnerability was found in Moodle affection 3.7 to 3.7.1, 3.6 to 3.6.5, 3.5 to 3.5.7 and earlier unsupported versions where activity creation capabilities were not correctly respected when selecting the activity to use for a course in single activity mode. | ||||
Page 1 of 1.