News & Sicurezza
Aggiornamenti da ENISA, NVD e le principali fonti di cybersecurity europee. Tutto quello che un Responsabile Tecnico deve sapere.
38911 risultati
CVE ID :CVE-2026-31397 Published : April 3, 2026, 4:16 p.m. | 3 hours, 38 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd() move_pages_huge_pmd() handles UFFDIO_MOVE for both normal THPs and huge zero pages. For the huge zero page path, src_folio is explicitly set to NULL, and is used as a sentinel to skip folio operations like lock and rmap. In the huge zero page branch, src_folio is NULL, so folio_mk_pmd(NULL, pgprot) passes NULL through folio_pfn() and page_to_pfn(). With SPARSEMEM_VMEMMAP this silently produces a bogus PFN, installing a PMD pointing to non-existent physical memory. On other memory models it is a NULL dereference. Use page_folio(src_page) to obtain the valid huge zero folio from the page, which was obtained from pmd_page() and remains valid throughout. After commit d82d09e48219 ("mm/huge_memory: mark PMD mappings of the huge zero folio special"), moved huge zero PMDs must remain special so vm_normal_page_pmd() continues to treat them as special mappings. move_pages_huge_pmd() currently reconstructs the destination PMD in the huge zero page branch, which drops PMD state such as pmd_special() on architectures with CONFIG_ARCH_HAS_PTE_SPECIAL. As a result, vm_normal_page_pmd() can treat the moved huge zero PMD as a normal page and corrupt its refcount. Instead of reconstructing the PMD from the folio, derive the destination entry from src_pmdval after pmdp_huge_clear_flush(), then handle the PMD metadata the same way move_huge_pmd() does for moved entries by marking it soft-dirty and clearing uffd-wp. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-31396 Published : April 3, 2026, 4:16 p.m. | 3 hours, 38 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use-after-free access to PTP clock PTP clock is registered on every opening of the interface and destroyed on every closing. However it may be accessed via get_ts_info ethtool call which is possible while the interface is just present in the kernel. BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 Read of size 4 at addr ffff8880194345cc by task syz.0.6/948 CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106 print_address_description mm/kasan/report.c:316 [inline] print_report+0x17f/0x496 mm/kasan/report.c:420 kasan_report+0xd9/0x180 mm/kasan/report.c:524 ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426 gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349 macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371 __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558 ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline] __dev_ethtool net/ethtool/ioctl.c:3017 [inline] dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095 dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510 sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215 sock_ioctl+0x577/0x6d0 net/socket.c:1320 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:46 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 457: kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:699 [inline] ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_cloc...
CVE ID :CVE-2026-31395 Published : April 3, 2026, 4:16 p.m. | 1 hour, 38 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix OOB access in DBG_BUF_PRODUCER async event handler The ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER handler in bnxt_async_event_process() uses a firmware-supplied 'type' field directly as an index into bp->bs_trace[] without bounds validation. The 'type' field is a 16-bit value extracted from DMA-mapped completion ring memory that the NIC writes directly to host RAM. A malicious or compromised NIC can supply any value from 0 to 65535, causing an out-of-bounds access into kernel heap memory. The bnxt_bs_trace_check_wrap() call then dereferences bs_trace->magic_byte and writes to bs_trace->last_offset and bs_trace->wrapped, leading to kernel memory corruption or a crash. Fix by adding a bounds check and defining BNXT_TRACE_MAX as DBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 to cover all currently defined firmware trace types (0x0 through 0xc). Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-31394 Published : April 3, 2026, 4:16 p.m. | 1 hour, 38 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations ieee80211_chan_bw_change() iterates all stations and accesses link->reserved.oper via sta->sdata->link[link_id]. For stations on AP_VLAN interfaces (e.g. 4addr WDS clients), sta->sdata points to the VLAN sdata, whose link never participates in chanctx reservations. This leaves link->reserved.oper zero-initialized with chan == NULL, causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw() when accessing chandef->chan->band during CSA. Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata() before accessing link data. [also change sta->sdata in ARRAY_SIZE even if it doesn't matter] Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-31393 Published : April 3, 2026, 3:15 p.m. | 39 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access l2cap_information_rsp() checks that cmd_len covers the fixed l2cap_info_rsp header (type + result, 4 bytes) but then reads rsp->data without verifying that the payload is present: - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads 4 bytes past the header (needs cmd_len >= 8). - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header (needs cmd_len >= 5). A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an out-of-bounds read of adjacent skb data. Guard each data access with the required payload length check. If the payload is too short, skip the read and let the state machine complete with safe defaults (feat_mask and remote_fixed_chan remain zero from kzalloc), so the info timer cleanup and l2cap_conn_start() still run and the connection is not stalled. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
Apache Traffic Server Patches “Double-Header” DoS and Request Smuggling Flaws Apache Traffic Server, the high-performance web proxy cache responsible for keeping the modern web fast, is facing a double-header of security challenges. Trusted by ISPs and global enterprises to max ... Read more Published Date: Apr 03, 2026 (3 days, 1 hour ago) Vulnerabilities has been mentioned in this article. CVE-2025-65114 CVE-2025-58136 CVE-2026-34751 CVE-2026-5281 CVE-2026-3502 CVE-2026-33032 CVE-2026-33526 CVE-2026-21962 CVE-2024-56196 CVE-2024-56195
Password Hijack in the Modern Stack: Payload CMS Patches Critical 9.1 CVSS Reset Flaw The rapid-growth, fullstack Next.js framework Payload—known for giving developers “instant backend superpowers” —is facing a serious security challenge. A critical vulnerability has been identified in ... Read more Published Date: Apr 03, 2026 (3 days ago) Vulnerabilities has been mentioned in this article.
CVE-2026-4370 (CVSS 10): Critical Juju Flaw Grants Attackers Total Infrastructure Control The cybersecurity community is on high alert following the discovery of a critical security flaw in Juju, the popular open-source application orchestration engine. Labeled as CVE-2026-4370, the vulner ... Read more Published Date: Apr 03, 2026 (3 days ago) Vulnerabilities has been mentioned in this article. CVE-2026-34751 CVE-2026-35093 CVE-2026-4370 CVE-2026-5281 CVE-2026-3502 CVE-2026-33032 CVE-2026-4404 CVE-2026-4606 CVE-2026-21962
CVE ID :CVE-2026-5468 Published : April 3, 2026, 1:30 p.m. | 24 minutes ago Description :A security flaw has been discovered in Casdoor 2.356.0. This affects the function dangerouslySetInnerHTML. Performing a manipulation of the argument formCss/formCssMobile/formSideHtml results in cross site scripting. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-28736 Published : April 3, 2026, 1:25 p.m. | 29 minutes ago Description :** UNSUPPORTED WHEN ASSIGNED ** Focalboard version 8.0 fails to validate file ownership when serving uploaded files. This allows an authenticated attacker who knows a victim's fileID to read the content of the file. NOTE: Focalboard as a standalone product is not maintained and no fix will be issued. Severity: 4.3 | MEDIUM Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-23426 Published : April 3, 2026, 1:24 p.m. | 30 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse() The logicvc_drm_config_parse() function calls of_get_child_by_name() to find the "layers" node but fails to release the reference, leading to a device node reference leak. Fix this by using the __free(device_node) cleanup attribute to automatic release the reference when the variable goes out of scope. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-23425 Published : April 3, 2026, 1:24 p.m. | 30 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix ID register initialization for non-protected pKVM guests In protected mode, the hypervisor maintains a separate instance of the `kvm` structure for each VM. For non-protected VMs, this structure is initialized from the host's `kvm` state. Currently, `pkvm_init_features_from_host()` copies the `KVM_ARCH_FLAG_ID_REGS_INITIALIZED` flag from the host without the underlying `id_regs` data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed. Consequently, `kvm_has_feat()` checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as `ctxt_has_tcrx()` for TCR2_EL1 support. As a result, certain system registers (e.g., TCR2_EL1, PIR_EL1, POR_EL1) are not saved/restored during the world switch, which could lead to state corruption. Fix this by explicitly copying the ID registers from the host `kvm` to the hypervisor `kvm` for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure `KVM_ARCH_FLAG_ID_REGS_INITIALIZED` is cleared initially in `pkvm_init_features_from_host` so that `vm_copy_id_regs` can properly initialize them and set the flag once done. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
Pagina 2468 di 3243