Export limit exceeded: 17400 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (17400 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23389 | 1 Linux | 1 Linux Kernel | 2026-03-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ice: Fix memory leak in ice_set_ringparam() In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings. Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails. Compile tested only. Issue found using a prototype static analysis tool and code review. | ||||
| CVE-2026-23390 | 1 Linux | 1 Linux Kernel | 2026-03-27 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow The dma_map_sg tracepoint can trigger a perf buffer overflow when tracing large scatter-gather lists. With devices like virtio-gpu creating large DRM buffers, nents can exceed 1000 entries, resulting in: phys_addrs: 1000 * 8 bytes = 8,000 bytes dma_addrs: 1000 * 8 bytes = 8,000 bytes lengths: 1000 * 4 bytes = 4,000 bytes Total: ~20,000 bytes This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing: WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405 perf buffer not large enough, wanted 24620, have 8192 Cap all three dynamic arrays at 128 entries using min() in the array size calculation. This ensures arrays are only as large as needed (up to the cap), avoiding unnecessary memory allocation for small operations while preventing overflow for large ones. The tracepoint now records the full nents/ents counts and a truncated flag so users can see when data has been capped. Changes in v2: - Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from Steven Rostedt) - This allocates only what's needed up to the cap, avoiding waste for small operations Reviwed-by: Sean Anderson <sean.anderson@linux.dev> | ||||
| CVE-2026-23392 | 1 Linux | 1 Linux Kernel | 2026-03-27 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu(). There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised. Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks. | ||||
| CVE-2026-23393 | 1 Linux | 1 Linux Kernel | 2026-03-27 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: Fix race condition in peer_mep deletion When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in softirq context under rcu_read_lock (without RTNL) and can re-schedule ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync() returning and kfree_rcu() being called. The following is a simple race scenario: cpu0 cpu1 mep_delete_implementation() cancel_delayed_work_sync(ccm_rx_dwork); br_cfm_frame_rx() // peer_mep still in hlist if (peer_mep->ccm_defect) ccm_rx_timer_start() queue_delayed_work(ccm_rx_dwork) hlist_del_rcu(&peer_mep->head); kfree_rcu(peer_mep, rcu); ccm_rx_work_expired() // on freed peer_mep To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync() in both peer MEP deletion paths, so that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected. The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable. | ||||
| CVE-2026-23394 | 1 Linux | 1 Linux Kernel | 2026-03-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls. | ||||
| CVE-2026-23395 | 1 Linux | 1 Linux Kernel | 2026-03-27 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAG_DEFER_SETUP) which can cause more than L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer causing an overflow. The spec is quite clear that the same identifier shall not be used on subsequent requests: 'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d So this attempts to check if there are any channels pending with the same identifier and rejects if any are found. | ||||
| CVE-2025-14808 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 3.1 Low |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 could allow an attacker to obtain sensitive information from the query string of an HTTP GET method to process a request which could be obtained using man in the middle techniques. | ||||
| CVE-2025-14810 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 6.3 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 does not invalidate a session after privileges have been modified which could allow an authenticated user to retain access to sensitive information. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L CWE: CWE-613: Insufficient Session Expiration CVSS Source: IBM CVSS Base score: 6.3 CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) | ||||
| CVE-2025-14912 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 5.4 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. | ||||
| CVE-2026-1262 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 4.3 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is affected by an information disclosure vulnerability. | ||||
| CVE-2025-36258 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 7.1 High |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 product stores user credentials and other sensitive information in plain text which can be read by a local user. | ||||
| CVE-2025-36422 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 4.3 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 IBM InfoSphere DataStage Flow Designer is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts. | ||||
| CVE-2026-2483 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 5.4 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session | ||||
| CVE-2026-1014 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 6.5 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to exposure of sensitive information via JSON server response manipulation. | ||||
| CVE-2026-1015 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 5.4 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. | ||||
| CVE-2025-14807 | 3 Ibm, Linux, Microsoft | 4 Aix, Infosphere Information Server, Linux Kernel and 1 more | 2026-03-27 | 6.5 Medium |
| IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is vulnerable to HTTP header injection, caused by improper validation of input by the HOST headers. This could allow an attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking. | ||||
| CVE-2026-23256 | 1 Linux | 1 Linux Kernel | 2026-03-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak. Fix this by changing the loop to iterate from the current index i down to 0. Compile tested only. Issue found using code review. | ||||
| CVE-2026-23282 | 1 Linux | 1 Linux Kernel | 2026-03-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix oops due to uninitialised var in smb2_unlink() If SMB2_open_init() or SMB2_close_init() fails (e.g. reconnect), the iovs set @rqst will be left uninitialised, hence calling SMB2_open_free(), SMB2_close_free() or smb2_set_related() on them will oops. Fix this by initialising @close_iov and @open_iov before setting them in @rqst. | ||||
| CVE-2026-23293 | 1 Linux | 1 Linux Kernel | 2026-03-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the nd_tbl is never initialized because inet6_init() exits before ndisc_init() is called which initializes it. If an IPv6 packet is injected into the interface, route_shortcircuit() is called and a NULL pointer dereference happens on neigh_lookup(). BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neigh_lookup+0x20/0x270 [...] Call Trace: <TASK> vxlan_xmit+0x638/0x1ef0 [vxlan] dev_hard_start_xmit+0x9e/0x2e0 __dev_queue_xmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x12f/0x1590 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix this by adding an early check on route_shortcircuit() when protocol is ETH_P_IPV6. Note that ipv6_mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module. | ||||
| CVE-2026-23344 | 1 Linux | 1 Linux Kernel | 2026-03-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix use-after-free on error path In the error path of sev_tsm_init_locked(), the code dereferences 't' after it has been freed with kfree(). The pr_err() statement attempts to access t->tio_en and t->tio_init_done after the memory has been released. Move the pr_err() call before kfree(t) to access the fields while the memory is still valid. This issue reported by Smatch static analyser | ||||