Export limit exceeded: 361517 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 361517 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (361517 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-52783 | 1 Opf | 1 Openproject | 2026-06-26 | 8.2 High |
| OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, OpenProject's Storages module writes the OneDrive/SharePoint userless OAuth access_token plaintext to Rails.cache under the deterministic key storage.<id>.httpx_access_token, repopulated continuously by an hourly cron and every userless-OAuth call site (see Write cadence). None of the three allowed cache backends (file_store, memcache, redis) encrypts at rest. An attacker with read access to the cache backend recovers the Azure-AD application-tier bearer with an anonymous get over the memcached binary protocol (or the equivalent against Redis). This vulnerability is fixed in 17.3.3 and 17.4.1. | ||||
| CVE-2026-52781 | 1 Opf | 1 Openproject | 2026-06-26 | 6.4 Medium |
| OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, the HTML sanitizer grants <macro> elements unrestricted data-* attributes via :data wildcard. An attacker injects data-controller="poll-for-changes" into a work package description, causing Stimulus.js to mount a controller that fetches an attacker-uploaded attachment and passes it to renderStreamMessage(). This executes arbitrary Turbo Stream actions — including redirect_to — in every victim's authenticated browser session, redirecting them to an attacker-controlled server. This vulnerability is fixed in 17.3.3 and 17.4.1. | ||||
| CVE-2026-52779 | 1 Opf | 1 Openproject | 2026-06-26 | 5.4 Medium |
| OpenProject is open-source, web-based project management software. Prior to 17.3.3 and 17.4.1, a cross-project IDOR / authorization context confusion in the Calendar and Team Planner modules allows a user with management permissions in one project to delete public Calendar or Team Planner Queries from another project where they do not have the corresponding management permissions. Both modules authorize the request against the project identified by :project_id in the URL, but the actual Query object is loaded later by :id from Query.visible(current_user) without verifying that the loaded Query belongs to the authorized project. As a result, an attacker can use permissions from Project A to delete shared/public Calendar or Team Planner views from Project B, causing integrity impact and limited availability impact for users relying on those shared views. This vulnerability is fixed in 17.3.3 and 17.4.1. | ||||
| CVE-2026-53287 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: audit: fix incorrect inheritable capability in CAPSET records __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008. | ||||
| CVE-2026-53292 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via pn_socket_autobind(): kernel BUG at net/phonet/socket.c:213! RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline] RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: sock_sendmsg_nosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] __sys_sendto+0x402/0x590 net/socket.c:2280 ... pn_socket_autobind() calls pn_socket_bind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero: err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn)); if (err != -EINVAL) return err; BUG_ON(!pn_port(pn_sk(sock->sk)->sobject)); return 0; /* socket was already bound */ However pn_socket_bind() also returns -EINVAL when sk->sk_state is not TCP_CLOSE, even when the socket has never been bound and pn_port() is still 0. In that case the BUG_ON() fires and panics the kernel from a user-triggerable path. Treat the "bind returned -EINVAL but pn_port() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno. | ||||
| CVE-2026-53293 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG There were multiple issues in that code. First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock. Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock. Then we used down_read_trylock() instead of waiting for the reset to finish. (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e) | ||||
| CVE-2026-53294 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mailbox: mailbox-test: don't free the reused channel The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs. | ||||
| CVE-2026-53295 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mailbox: add sanity check for channel array Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here. | ||||
| CVE-2026-53298 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails. | ||||
| CVE-2026-53299 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx() If queue entry list allocation fails in airoha_qdma_init_tx_queue routine, airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference accessing the queue entry array. The issue is due to the early ndesc initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. | ||||
| CVE-2026-53300 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix NTMP DMA use-after-free issue The AI-generated review reported a potential DMA use-after-free issue [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending command is not explicitly aborted, while ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer has already been reallocated elsewhere, this may lead to silent memory corruption. Because the hardware eventually processes the pending command and perform a DMA write of the response to the physical address of the freed buffer. To resolve this issue, this patch does the following modifications: 1. Convert cbdr->ring_lock from a spinlock to a mutex The lock was originally a spinlock in case NTMP operations might be invoked from atomic context. After downstream support for all NTMP tables, no such usage has materialized. A mutex lock is now required because the driver now needs to reclaim used BDs and release associated DMA memory within the lock's context, while dma_free_coherent() might sleep. 2. Introduce software command BD (struct netc_swcbd) The hardware write-back overwrites the addr and len fields of the BD, so the driver cannot rely on the hardware BD to free the associated DMA memory. The driver now maintains a software shadow BD storing the DMA buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only reclaims older BDs when the number of used BDs reaches NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no longer needed and are removed. 3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd() netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes consuming the response. At this point, if a concurrent thread submits a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer while it is still in use. Move ring_lock ownership to the caller to ensure the response buffer cannot be reclaimed prematurely. So the helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added. These changes eliminate the DMA use-after-free condition and ensure safe and consistent BD reclamation and DMA buffer lifecycle management. | ||||
| CVE-2026-53311 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fuse: fix uninit-value in fuse_dentry_revalidate() fuse_dentry_revalidate() may be called with a dentry that didn't had ->d_time initialised. The issue was found with KMSAN, where lookup_open() calls __d_alloc(), followed by d_revalidate(), as shown below: ===================================================== BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 d_revalidate fs/namei.c:1030 [inline] lookup_open fs/namei.c:4405 [inline] open_last_lookups fs/namei.c:4583 [inline] path_openat+0x1614/0x64c0 fs/namei.c:4827 do_file_open+0x2aa/0x680 fs/namei.c:4859 [...] Uninit was created at: slab_post_alloc_hook mm/slub.c:4466 [inline] slab_alloc_node mm/slub.c:4788 [inline] kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807 __d_alloc+0x55/0xa00 fs/dcache.c:1740 d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604 lookup_open fs/namei.c:4398 [inline] open_last_lookups fs/namei.c:4583 [inline] path_openat+0x135f/0x64c0 fs/namei.c:4827 do_file_open+0x2aa/0x680 fs/namei.c:4859 [...] ===================================================== | ||||
| CVE-2026-53313 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166) | ||||
| CVE-2026-53320 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy] | ||||
| CVE-2026-53322 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Clean up DMABUFs before disabling function On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver. | ||||
| CVE-2026-46604 | 2026-06-26 | N/A | ||
| The TIFF decoder can panic when decoding an invalid image with an out-of-bounds strip offset. | ||||
| CVE-2026-53302 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: eip93 - fix hmac setkey algo selection eip93_hmac_setkey() allocates a temporary ahash transform for computing HMAC ipad/opad key material. The allocation uses the driver-specific cra_driver_name (e.g. "sha256-eip93") but passes CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms. Since the EIP93 hash algorithms are the only ones registered under those driver names and they are inherently async, the lookup is self-contradictory and always fails with -ENOENT. When called from the AEAD setkey path, this failure leaves the SA record partially initialized with zeroed digest fields. A subsequent crypto operation then dereferences a NULL pointer in the request context, resulting in a kernel panic: ``` pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93] lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93] sp : ffffffc082feb820 x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000 x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980 x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0 x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000 x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009 x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0 Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740) ``` The reported symbol eip93_aead_handle_result+0xc8c is a resolution artifact from static functions being merged under the nearest exported symbol. Decoding the faulting sequence: ``` 910142b6 ADD X22, X21, #0x50 f94012e0 LDR X0, [X23, #0x20] f9002aa0 STR X0, [X21, #0x50] f90006d3 STR X19, [X22, #0x8] f9400740 LDR X0, [X26, #0x8] ``` The faulting LDR at [X26, #0x8] is loading ctx->flags (offset 8 in eip93_hash_ctx), where ctx has been resolved to NULL from a partially initialized or unreachable transform context following the failed setkey. Fix this by dropping the CRYPTO_ALG_ASYNC mask from the crypto_alloc_ahash() call. The code already handles async completion correctly via crypto_wait_req(), so there is no requirement to restrict the lookup to synchronous algorithms. Note that hashing a single 64-byte block through the hardware is likely slower than doing it in software due to the DMA round-trip overhead, but offloading it may still spare CPU cycles on the slower embedded cores where this IP is found. [Detailed investigation report of this bug] | ||||
| CVE-2026-53306 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tty: hvc_iucv: fix off-by-one in number of supported devices MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops. | ||||
| CVE-2026-53314 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: padata: Put CPU offline callback in ONLINE section to allow failure syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible. | ||||
| CVE-2026-53315 | 1 Linux | 1 Linux Kernel | 2026-06-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp() ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp (in seconds since the Unix epoch) through a platform-specific RAS system callback and is used for timestamping RAS error events. The function checks ras_core in the conditional statement before calling the sys_fn callback. However, when the condition fails, the function prints an error message using ras_core->dev. If ras_core is NULL, this can lead to a potential NULL pointer dereference when accessing ras_core->dev. Add an early NULL check for ras_core at the beginning of the function and return 0 when the pointer is not valid. This prevents the dereference and makes the control flow clearer. | ||||