Export limit exceeded: 361066 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (361066 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-53016 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - copy IV using skcipher ivsize AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length. | ||||
| CVE-2026-53017 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix data loss caused by incorrect use of nat_entry flag Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows: create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return false SPO and lost 'file A' f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC flags for the nat_entry, but this does not mean that the checkpoint has actually completed successfully. However, f2fs_need_inode_block_update() checks these flags and incorrectly assumes that the checkpoint has finished. The root cause is that the semantics of IS_CHECKPOINTED and HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully completes. This patch modifies f2fs_need_inode_block_update() to acquire the sbi->node_write lock before reading the nat_entry flags, ensuring that once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the checkpoint operation has already completed. | ||||
| CVE-2026-53019 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc() Fix inverted condition that skips frequency change trigger, causing kernel panics during cpufreq scaling. | ||||
| CVE-2026-53023 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: terminate the cached volume label after UTF-8 conversion ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer. | ||||
| CVE-2026-53027 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn = vcn0 & cmask <- vcn != vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here! | ||||
| CVE-2026-53028 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: usb: typec: Fix error pointer dereference The variable tps->partner is checked for an error pointer and then if it is, it sends an error message but does not return and then immediately dereferenced a few lines below: tps->partner = typec_register_partner(tps->port, &desc); if (IS_ERR(tps->partner)) dev_warn(tps->dev, "%s: failed to register partnet\n", __func__); if (desc.identity) { typec_partner_set_identity(tps->partner); cd321x->cur_partner_identity = st.partner_identity; } Add early return and fix spelling mistake in error message. Detected by Smatch: drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error: 'tps->partner' dereferencing possible ERR_PTR() | ||||
| CVE-2026-53031 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Validate node_id in arena_alloc_pages() arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages(). | ||||
| CVE-2026-53037 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them. | ||||
| CVE-2026-55488 | 1 Motioneye Project | 1 Motioneye | 2026-06-24 | N/A |
| motionEye (mEye) is an online interface for a piece of software called "motion," which is a video surveillance program with motion detection. Versions prior to 0.44.0 contain an absolute path traversal vulnerability in multiple media file handlers that allows an attacker to read arbitrary files from the filesystem. The affected handlers accept a user-controlled filename parameter and construct filesystem paths using `os.path.join()`. When an absolute path is supplied, Python discards the configured media directory and returns the attacker-supplied path directly. The application then bypasses Tornado's built-in path validation by overriding the relevant safety checks. As a result, an attacker can access files outside of the configured camera media directory, subject to the permissions of the motionEye process. Version 0.44.0 fixes the issue. | ||||
| CVE-2026-12760 | 2026-06-24 | N/A | ||
| A denial-of-service (DoS) vulnerability has been identified in Tapo C200 v3 in the network packet handling logic due to improper handling of IPv4 fragmented packets. An unauthenticated adjacent attacker can send crafted packets to cause excessive resource consumption, leading to instability of the device.Successful exploitation can remotely trigger a temporary denial-of-service condition, causing the camera to become unresponsive and resulting in intermittent loss of video monitoring and recording. | ||||
| CVE-2026-50193 | 1 Fasterxml | 1 Jackson-databind | 2026-06-24 | N/A |
| jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.13.0 until 2.14.0, a potential Denial-of-Service exists when attacker sends deeply nested JSON if (and only if) the service reads deeply nested (1000s of levels) JSON as JsonNode (ObjectMapper.readTree()) and writes out same (or modifided) node using JsonNode.toString(). This can consume significant amount of resources with concurrent relatively small requests (1000 nested arrays is 2kB). This vulnerability is fixed in 2.14.0. | ||||
| CVE-2026-48908 | 1 Joomshaper.net | 1 Sp Page Builder Extension For Joomla | 2026-06-24 | N/A |
| A vulnerability in SP Page Builder for Joomla allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code. | ||||
| CVE-2026-52981 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: neigh: let neigh_xmit take skb ownership neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx). sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB? Assume full ownership and remove the last code path that doesn't xmit or free skb. | ||||
| CVE-2026-52984 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: netem: fix queue limit check to include reordered packets The queue limit check in netem_enqueue() uses q->t_len which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (__qdisc_enqueue_head) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering. Include sch->q.qlen in the limit check. | ||||
| CVE-2026-52986 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: don't use simple_strtoul Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(), and ct_sip_parse_request() with a new sip_parse_port() helper that validates each digit against the buffer limit, eliminating the use of simple_strtoul() which assumes NUL-terminated strings. The previous code dereferenced pointers without bounds checks after sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated skb data. A port that reaches the buffer limit without a trailing character is also rejected as malformed. Also get rid of all simple_strtoul() usage in conntrack, prefer a stricter version instead. There are intentional changes: - Bail out if number is > UINT_MAX and indicate a failure, same for too long sequences. While we do accept 05535 as port 5535, we will not accept e.g. 'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261, we should restrict this to not waste cycles when presented with malformed packets with 64k '0' characters. - Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch 'expire=' and 'rports='; both are expected to use base-10. - In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k range. - epaddr_len now returns 0 if the port is invalid, as it already does for invalid ip addresses. This is intentional. nf_conntrack_sip performs lots of guesswork to find the right parts of the message to parse. Being stricter could break existing setups. Connection tracking helpers are designed to allow traffic to pass, not to block it. Based on an earlier patch from Jenny Guanni Qu <qguanni@gmail.com>. | ||||
| CVE-2026-52988 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on. | ||||
| CVE-2026-52989 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. | ||||
| CVE-2026-52992 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fs/adfs: validate nzones in adfs_validate_bblk() Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller. | ||||
| CVE-2026-52993 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations. | ||||
| CVE-2026-52995 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson | ||||