Total
18782 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-53225 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 9.1 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop"). | |||||
| CVE-2026-53228 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 9.8 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb. | |||||
| CVE-2026-53229 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 7.5 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed. | |||||
| CVE-2026-53230 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 8.7 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 </TASK> Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max. | |||||
| CVE-2026-53231 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: don't try to setup PHY-driven SFP cages when using genphy We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy. Let's therefore only run phy_sfp_probe when not using genphy. | |||||
| CVE-2026-53227 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value. | |||||
| CVE-2025-36372 | 4 Ibm, Linux, Microsoft and 1 more | 4 Db2, Linux Kernel, Windows and 1 more | 2026-07-02 | N/A | 5.5 MEDIUM |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes Db2 Connect Server) could disclose sensitive information to an authenticated user from the monitoring and event tables. | |||||
| CVE-2026-11906 | 4 Ibm, Linux, Microsoft and 1 more | 4 Db2, Linux Kernel, Windows and 1 more | 2026-07-02 | N/A | 6.5 MEDIUM |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an authenticated user to cause a denial of service due to improper neutralization of special elements in the data query logic of XMLTable-derived columns. | |||||
| CVE-2026-13945 | 2 Google, Linux | 2 Chrome, Linux Kernel | 2026-07-02 | N/A | 3.1 LOW |
| Insufficient policy enforcement in Extensions in Google Chrome on Linux prior to 150.0.7871.47 allowed an attacker who convinced a user to install a malicious extension to perform UI spoofing via a crafted Chrome Extension. (Chromium security severity: Medium) | |||||
| CVE-2026-31694 | 1 Linux | 1 Linux Kernel | 2026-07-02 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page-cache page. The existing logic only checks whether the dirent fits in the remaining space of the current page and advances to a fresh page if not. It never checks whether the dirent itself exceeds PAGE_SIZE. As a result, a malicious FUSE server can return a dirent with namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB page systems this causes memcpy() to overflow the cache page by 24 bytes into the following kernel page. Reject dirents that cannot fit in a single page before copying them into the readdir cache. | |||||
| CVE-2026-14121 | 2 Google, Linux | 2 Chrome, Linux Kernel | 2026-07-02 | N/A | 9.8 CRITICAL |
| Use after free in Chromoting in Google Chrome on Linux prior to 150.0.7871.47 allowed a remote attacker to execute arbitrary code via malicious network traffic. (Chromium security severity: Low) | |||||
| CVE-2026-24250 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause improper validation of allowed inputs. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24248 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause improper control of code generation. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24246 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause improper control of dynamically managed code resources. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24244 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause deserialization of untrusted data. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24242 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2026-24251 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause improper control of dynamically managed code resources. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24249 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause deserialization of untrusted data. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24247 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause deserialization of untrusted data. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||
| CVE-2026-24245 | 2 Linux, Nvidia | 2 Linux Kernel, Nemo Megatron Bridge | 2026-07-02 | N/A | 7.8 HIGH |
| NVIDIA Megatron Bridge for Linux contains a vulnerability where an attacker could cause deserialization of untrusted data. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure. | |||||