Export limit exceeded: 409932 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (7036 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-8961 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-05-20 | 6.5 Medium |
| Spoofing issue in the Form Autofill component. This vulnerability was fixed in Firefox 151, Firefox ESR 140.11, Thunderbird 151, and Thunderbird 140.11. | ||||
| CVE-2026-43424 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically managed and tied to userspace configuration via ConfigFS. It can be NULL if the USB host sends requests before the nexus is fully established or immediately after it is dropped. Currently, functions like `bot_submit_command()` and the data transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately dereference `tv_nexus->tvn_se_sess` without any validation. If a malicious or misconfigured USB host sends a BOT (Bulk-Only Transport) command during this race window, it triggers a NULL pointer dereference, leading to a kernel panic (local DoS). This exposes an inconsistent API usage within the module, as peer functions like `usbg_submit_command()` and `bot_send_bad_response()` correctly implement a NULL check for `tv_nexus` before proceeding. Fix this by bringing consistency to the nexus handling. Add the missing `if (!tv_nexus)` checks to the vulnerable BOT command and request processing paths, aborting the command gracefully with an error instead of crashing the system. | ||||
| CVE-2026-43463 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc, afs: Fix missing error pointer check after rxrpc_kernel_lookup_peer() rxrpc_kernel_lookup_peer() can also return error pointers in addition to NULL, so just checking for NULL is not sufficient. Fix this by: (1) Changing rxrpc_kernel_lookup_peer() to return -ENOMEM rather than NULL on allocation failure. (2) Making the callers in afs use IS_ERR() and PTR_ERR() to pass on the error code returned. | ||||
| CVE-2026-43471 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace() The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL pointer dereference when accessing hwq->id. This can happen if ufshcd_mcq_req_to_hwq() returns NULL. This patch adds a NULL check for hwq before accessing its id field to prevent a kernel crash. Kernel log excerpt: [<ffffffd5d192dc4c>] notify_die+0x4c/0x8c [<ffffffd5d1814e58>] __die+0x60/0xb0 [<ffffffd5d1814d64>] die+0x4c/0xe0 [<ffffffd5d181575c>] die_kernel_fault+0x74/0x88 [<ffffffd5d1864db4>] __do_kernel_fault+0x314/0x318 [<ffffffd5d2a3cdf8>] do_page_fault+0xa4/0x5f8 [<ffffffd5d2a3cd34>] do_translation_fault+0x34/0x54 [<ffffffd5d1864524>] do_mem_abort+0x50/0xa8 [<ffffffd5d2a297dc>] el1_abort+0x3c/0x64 [<ffffffd5d2a29718>] el1h_64_sync_handler+0x44/0xcc [<ffffffd5d181133c>] el1h_64_sync+0x80/0x88 [<ffffffd5d255c1dc>] ufshcd_add_command_trace+0x23c/0x320 [<ffffffd5d255bad8>] ufshcd_compl_one_cqe+0xa4/0x404 [<ffffffd5d2572968>] ufshcd_mcq_poll_cqe_lock+0xac/0x104 [<ffffffd5d11c7460>] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod] [<ffffffd5d19ab92c>] __handle_irq_event_percpu+0xc8/0x348 [<ffffffd5d19abca8>] handle_irq_event+0x3c/0xa8 [<ffffffd5d19b1f0c>] handle_fasteoi_irq+0xf8/0x294 [<ffffffd5d19aa778>] generic_handle_domain_irq+0x54/0x80 [<ffffffd5d18102bc>] gic_handle_irq+0x1d4/0x330 [<ffffffd5d1838210>] call_on_irq_stack+0x44/0x68 [<ffffffd5d183af30>] do_interrupt_handler+0x78/0xd8 [<ffffffd5d2a29c00>] el1_interrupt+0x48/0xa8 [<ffffffd5d2a29ba8>] el1h_64_irq_handler+0x14/0x24 [<ffffffd5d18113c4>] el1h_64_irq+0x80/0x88 [<ffffffd5d2527fb4>] arch_local_irq_enable+0x4/0x1c [<ffffffd5d25282e4>] cpuidle_enter+0x34/0x54 [<ffffffd5d195a678>] do_idle+0x1dc/0x2f8 [<ffffffd5d195a7c4>] cpu_startup_entry+0x30/0x3c [<ffffffd5d18155c4>] secondary_start_kernel+0x134/0x1ac [<ffffffd5d18640bc>] __secondary_switched+0xc4/0xcc | ||||
| CVE-2026-43431 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xhci: Fix NULL pointer dereference when reading portli debugfs files Michal reported and debgged a NULL pointer dereference bug in the recently added portli debugfs files Oops is caused when there are more port registers counted in xhci->max_ports than ports reported by Supported Protocol capabilities. This is possible if max_ports is more than maximum port number, or if there are gaps between ports of different speeds the 'Supported Protocol' capabilities. In such cases port->rhub will be NULL so we can't reach xhci behind it. Add an explicit NULL check for this case, and print portli in hex without dereferencing port->rhub. | ||||
| CVE-2026-31425 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rds: ib: reject FRMR registration before IB connection is established rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel. The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists. KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64 Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker. | ||||
| CVE-2026-31394 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| 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] | ||||
| CVE-2026-32738 | 1 Struktur | 1 Libheif | 2026-05-20 | 6.5 Medium |
| libheif is a HEIF and AVIF file format decoder and encoder. In versions 1.21.2 and below, a crafted 792-byte HEIF sequence file with samples_per_chunk=0 in the stsc box causes an unsigned integer underflow in the Chunk constructor (m_last_sample = 0 + 0 - 1 = UINT32_MAX), mapping all samples to an empty chunk and resulting in a denial of service. When any sample is accessed, the library reads from index 0 of an empty std::vector, causing a guaranteed SEGV (null-page read). The file parses successfully without producing an error; the crash occurs on the first frame access. This issue has been fixed in version 1.22.0. | ||||
| CVE-2026-34216 | 1 Ctrlpanel-gg | 1 Panel | 2026-05-20 | 6.6 Medium |
| CtrlPanel is open-source billing software for hosting providers. In versions 1.1.1 and prior, the admin settings update endpoint accepted a fully qualified class name directly from user-supplied request input and used it for dynamic static method calls and object instantiation without any allowlist validation, allowing for authenticated Remote Code Execution. An authenticated admin-level user could supply an arbitrary class name available in the Composer autoloader, potentially triggering unintended constructor or magic method execution. The update() method reads settings_class directly from the HTTP request and passed it to new $settings_class() and $settings_class::getValidations() without verifying that the provided value corresponds to a legitimate settings class: Because PHP resolves class names against the Composer autoloader at runtime, any autoloadable class in the application or its dependencies could be instantiated. Depending on the classes available in the dependency tree, this can trigger unintended side effects through constructors or magic methods (__construct, __toString, __wakeup), following a PHP object injection / gadget chain pattern. This issue has been fixed in version 1.2.0. | ||||
| CVE-2026-31397 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 7.8 High |
| 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. | ||||
| CVE-2026-31438 | 1 Linux | 1 Linux Kernel | 2026-05-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix kernel BUG in netfs_limit_iter() for ITER_KVEC iterators When a process crashes and the kernel writes a core dump to a 9P filesystem, __kernel_write() creates an ITER_KVEC iterator. This iterator reaches netfs_limit_iter() via netfs_unbuffered_write(), which only handles ITER_FOLIOQ, ITER_BVEC and ITER_XARRAY iterator types, hitting the BUG() for any other type. Fix this by adding netfs_limit_kvec() following the same pattern as netfs_limit_bvec(), since both kvec and bvec are simple segment arrays with pointer and length fields. Dispatch it from netfs_limit_iter() when the iterator type is ITER_KVEC. | ||||
| CVE-2026-8567 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-05-19 | 4.3 Medium |
| Integer overflow in ANGLE in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-8573 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-05-19 | 8.3 High |
| Integer overflow in Codecs in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker to potentially perform a sandbox escape via a crafted video file. (Chromium security severity: Medium) | ||||
| CVE-2026-8391 | 1 Mozilla | 1 Firefox | 2026-05-19 | 5.3 Medium |
| Other issue in the JavaScript Engine component. This vulnerability was fixed in Firefox 150.0.3, Firefox ESR 115.36, Firefox ESR 140.11, and Thunderbird 140.11. | ||||
| CVE-2026-32134 | 1 Nanomq | 1 Nanomq | 2026-05-19 | 5.9 Medium |
| NanoMQ MQTT Broker (NanoMQ) is an all-around Edge Messaging Platform. In versions 0.24.10 and below, when NanoMQ handles high-concurrency reconnect traffic using a reconnect-collision payload, the broker can crash due to a NULL pointer dereference during MQTT session resumption for clean_start=0 clients. The transport's p_peer callback (tcptran_pipe_peer()) iterates cpipe->subinfol while copying session metadata from the cached old pipe to the new reconnecting pipe, without checking whether the pointer is NULL. Under a reconnect race, cpipe->subinfol can be freed and set to NULL before session restore invokes this function, resulting in a remote unauthenticated Denial-of-Service (process crash) condition. This issue has been fixed in version 0.24.11. | ||||
| CVE-2026-8510 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-05-19 | 7.5 High |
| Integer overflow in Skia in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical) | ||||
| CVE-2026-8519 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-05-19 | 8.8 High |
| Integer overflow in ANGLE in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical) | ||||
| CVE-2026-8534 | 2 Google, Linux | 3 Chrome, Chrome Os, Linux Kernel | 2026-05-19 | 8.3 High |
| Integer overflow in GPU in Google Chrome on Linux and ChromeOS prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-8577 | 1 Google | 1 Chrome | 2026-05-19 | 8.8 High |
| Integer overflow in Fonts in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-8559 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-05-19 | 4.3 Medium |
| Integer overflow in Internationalization in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High) | ||||