News & Sicurezza

CVE ID :CVE-2026-28529 Published : March 25, 2026, 1 p.m. | 51 minutes ago Description :cryptodev-linux version 1.14 and prior contain a page reference handling flaw in the get_userbuf function of the /dev/crypto device driver that allows local users to trigger use-after-free conditions. Attackers with access to the /dev/crypto interface can repeatedly decrement reference counts of controlled pages to achieve local privilege escalation. Severity: 8.5 | HIGH Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2025-27260 Published : March 25, 2026, 12:54 p.m. | 58 minutes ago Description :Ericsson Indoor Connect 8855 versions prior to 2025.Q3 contains an Improper Filtering of Special Elements vulnerability which, if exploited, can lead to unauthorized modification of certain information Severity: 7.2 | HIGH Visit the link for more details, such as CVSS details, affected products, timeline, and more...

GitLab Critical Alert: High-Severity Flaws Allow App Impersonation and AI Token Leaks GitLab has released a critical security advisory alongside versions 18.10.1, 18.9.3, and 18.8.7 for its Community (CE) and Enterprise Editions (EE). The release addresses a battery of vulnerabilities, ... Read more Published Date: Mar 25, 2026 (1 day, 4 hours ago) Vulnerabilities has been mentioned in this article.

AI Infrastructure at Risk: NVIDIA Fixes Critical 9.0 RCE Flaw in Apex Library (CVE-2025-33244) NVIDIA has issued an urgent security update for its Apex library to remediate a critical vulnerability that could allow attackers to execute malicious code on Linux-based systems. The flaw, tracked as ... Read more Published Date: Mar 25, 2026 (1 day, 4 hours ago) Vulnerabilities has been mentioned in this article. CVE-2025-33244 CVE-2025-15517 CVE-2025-33179 CVE-2025-33187 CVE-2024-0138

PTC Warns of Critical Windchill, FlexPLM Flaw Enabling Remote Code Execution PTC has issued an urgent advisory regarding a critical Windchill and FlexPLM vulnerability that exposes affected systems to Remote Code Execution (RCE). The flaw, identified as CVE-2026-4681, has been ... Read more Published Date: Mar 25, 2026 (1 day, 3 hours ago) Vulnerabilities has been mentioned in this article. CVE-2026-4681 CVE-2026-21992

CVE ID :CVE-2026-31788 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: restrict usage in unprivileged domU The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains. In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature. The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest. Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today. The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot. This is XSA-482 --- V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich) Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-23395 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :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. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-23394 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :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 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 clo...

CVE ID :CVE-2026-23393 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :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. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-23387 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: pinctrl: cirrus: cs42l43: Fix double-put in cs42l43_pin_probe() devm_add_action_or_reset() already invokes the action on failure, so the explicit put causes a double-put. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-23390 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :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 Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...

CVE ID :CVE-2026-23391 Published : March 25, 2026, 11:16 a.m. | 2 hours, 36 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. - timeout policy, nfnetlink_cttimeout might remove it. The use of templates with zone and event cache filter are safe, since this just copies values. Flush these enqueued packets in case the template rule gets removed. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...