Total
34884 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-20402 | 1 Mediatek | 20 Mt2735, Mt6833, Mt6853 and 17 more | 2026-04-18 | 6.5 Medium |
| In Modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY00693083; Issue ID: MSV-5928. | ||||
| CVE-2026-20977 | 1 Samsung | 2 Android, Mobile Devices | 2026-04-18 | 5.5 Medium |
| Improper access control in Emergency Sharing prior to SMR Feb-2026 Release 1 allows local attackers to interrupt its functioning. | ||||
| CVE-2026-20978 | 1 Samsung | 2 Android, Mobile Devices | 2026-04-18 | 6.1 Medium |
| Improper authorization in KnoxGuardManager prior to SMR Feb-2026 Release 1 allows local attackers to bypass the persistence configuration of the application. | ||||
| CVE-2026-20980 | 1 Samsung | 2 Android, Mobile Devices | 2026-04-18 | 6.8 Medium |
| Improper input validation in PACM prior to SMR Feb-2026 Release 1 allows physical attacker to execute arbitrary commands. | ||||
| CVE-2026-20981 | 1 Samsung | 2 Android, Mobile Devices | 2026-04-18 | 6.6 Medium |
| Improper input validation in FacAtFunction prior to SMR Feb-2026 Release 1 allows privileged physical attacker to execute arbitrary command with system privilege. | ||||
| CVE-2026-20732 | 1 F5 | 22 Big-ip, Big-ip Access Policy Manager, Big-ip Advanced Firewall Manager and 19 more | 2026-04-18 | 3.1 Low |
| A vulnerability exists in an undisclosed BIG-IP Configuration utility page that may allow an attacker to spoof error messages. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | ||||
| CVE-2026-22549 | 3 F5, Kubernetes, Redhat | 3 Big-ip Container Ingress Services, Kubernetes, Openshift | 2026-04-18 | 4.9 Medium |
| A vulnerability exists in F5 BIG-IP Container Ingress Services that may allow excessive permissions to read cluster secrets. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | ||||
| CVE-2026-23083 | 1 Linux | 1 Linux Kernel | 2026-04-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO. | ||||
| CVE-2026-23086 | 1 Linux | 1 Linux Kernel | 2026-04-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to local buffer size The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base. Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport. This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have. [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message] | ||||
| CVE-2026-23096 | 1 Linux | 1 Linux Kernel | 2026-04-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove. | ||||
| CVE-2026-23097 | 1 Linux | 1 Linux Kernel | 2026-04-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages. | ||||
| CVE-2026-23104 | 1 Linux | 1 Linux Kernel | 2026-04-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ice: fix devlink reload call trace Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced internal temperature sensor reading via HWMON. ice_hwmon_init() was added to ice_init_feature() and ice_hwmon_exit() was added to ice_remove(). As a result if devlink reload is used to reinit the device and then the driver is removed, a call trace can occur. BUG: unable to handle page fault for address: ffffffffc0fd4b5d Call Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60 The call trace repeats approximately every 10 minutes when system monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs attributes that reference freed module memory. The sequence is: 1. Driver load, ice_hwmon_init() gets called from ice_init_feature() 2. Devlink reload down, flow does not call ice_remove() 3. Devlink reload up, ice_hwmon_init() gets called from ice_init_feature() resulting in a second instance 4. Driver unload, ice_hwmon_exit() called from ice_remove() leaving the first hwmon instance orphaned with dangling pointer Fix this by moving ice_hwmon_exit() from ice_remove() to ice_deinit_features() to ensure proper cleanup symmetry with ice_hwmon_init(). | ||||
| CVE-2026-0945 | 2 Drupal, Role Delegation Project | 2 Role Delegation, Role Delegation | 2026-04-17 | 5.4 Medium |
| Privilege Defined With Unsafe Actions vulnerability in Drupal Role Delegation allows Privilege Escalation.This issue affects Role Delegation: from 1.3.0 before 1.5.0. | ||||
| CVE-2026-24921 | 1 Huawei | 1 Harmonyos | 2026-04-17 | 4.8 Medium |
| Address read vulnerability in the HDC module. Impact: Successful exploitation of this vulnerability will affect availability and confidentiality. | ||||
| CVE-2026-24923 | 1 Huawei | 1 Harmonyos | 2026-04-17 | 6.3 Medium |
| Permission control vulnerability in the HDC module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2026-24931 | 1 Huawei | 1 Harmonyos | 2026-04-17 | 5.9 Medium |
| Vulnerability of improper criterion security check in the card module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2026-24924 | 1 Huawei | 1 Harmonyos | 2026-04-17 | 6.1 Medium |
| Vulnerability of improper permission control in the print module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2026-24927 | 1 Huawei | 2 Emui, Harmonyos | 2026-04-17 | 5.5 Medium |
| Out-of-bounds access vulnerability in the frequency modulation module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2026-25650 | 1 Smn2gnt | 2 Mcp-salesforce, Mcp Salesforce Connector | 2026-04-17 | 7.5 High |
| MCP Salesforce Connector is a Model Context Protocol (MCP) server implementation for Salesforce integration. Prior to 0.1.10, arbitrary attribute access leads to disclosure of Salesforce auth token. This vulnerability is fixed in 0.1.10. | ||||
| CVE-2026-0485 | 1 Sap | 2 Businessobjects Bi Platform, Businessobjects Business Intelligence Platform | 2026-04-17 | 7.5 High |
| SAP BusinessObjects BI Platform allows an unauthenticated attacker to send specially crafted requests that could cause the Content Management Server (CMS) to crash and automatically restart. By repeatedly submitting these requests, the attacker could induce a persistent service disruption, rendering the CMS completely unavailable. Successful exploitation results in a high impact on availability, while confidentiality and integrity remain unaffected. | ||||