Export limit exceeded: 92759 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (92759 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-50628 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/gud: Fix UBSAN warning UBSAN complains about invalid value for bool: [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1 [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device [ 101.213426] usbcore: registered new interface driver gud [ 101.989431] ================================================================================ [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9 [ 101.989447] load of value 121 is not a valid value for type '_Bool' [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3 [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018 [ 101.989459] Workqueue: events_long gud_flush_work [gud] [ 101.989471] Call Trace: [ 101.989474] <TASK> [ 101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busiest_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [ 101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [ 101.989708] ================================================================================ The source of this warning is in iosys_map_clear() called from dma_buf_vmap(). It conditionally sets values based on map->is_iomem. The iosys_map variables are allocated uninitialized on the stack leading to ->is_iomem having all kinds of values and not only 0/1. Fix this by zeroing the iosys_map variables. | ||||
| CVE-2022-50635 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe() I found a null pointer reference in arch_prepare_kprobe(): # echo 'p cmdline_proc_show' > kprobe_events # echo 'p cmdline_proc_show+16' >> kprobe_events Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000000050bfc Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10 NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc REGS: c0000000348475b0 TRAP: 0300 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 88002444 XER: 20040006 CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0 ... NIP arch_prepare_kprobe+0x10c/0x2d0 LR arch_prepare_kprobe+0xfc/0x2d0 Call Trace: 0xc0000000012f77a0 (unreliable) register_kprobe+0x3c0/0x7a0 __register_trace_kprobe+0x140/0x1a0 __trace_kprobe_create+0x794/0x1040 trace_probe_create+0xc4/0xe0 create_or_delete_trace_kprobe+0x2c/0x80 trace_parse_run_command+0xf0/0x210 probes_write+0x20/0x40 vfs_write+0xfc/0x450 ksys_write+0x84/0x140 system_call_exception+0x17c/0x3a0 system_call_vectored_common+0xe8/0x278 --- interrupt: 3000 at 0x7fffa5682de0 NIP: 00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000 REGS: c000000034847e80 TRAP: 3000 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e) MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 44002408 XER: 00000000 The address being probed has some special: cmdline_proc_show: Probe based on ftrace cmdline_proc_show+16: Probe for the next instruction at the ftrace location The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets set to NULL. In arch_prepare_kprobe() it will check for: ... prev = get_kprobe(p->addr - 1); preempt_enable_no_resched(); if (prev && ppc_inst_prefixed(ppc_inst_read(prev->ainsn.insn))) { ... If prev is based on ftrace, 'ppc_inst_read(prev->ainsn.insn)' will occur with a null pointer reference. At this point prev->addr will not be a prefixed instruction, so the check can be skipped. Check if prev is ftrace-based kprobe before reading 'prev->ainsn.insn' to fix this problem. [mpe: Trim oops] | ||||
| CVE-2022-50636 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_device_is_present() for VFs by checking PF pci_device_is_present() previously didn't work for VFs because it reads the Vendor and Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong reported that if virtio I/O is in progress when the driver is unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0 blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0 virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60 unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened because pci_device_is_present(VF) returned "false" in virtio_pci_remove(), so it called virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag] | ||||
| CVE-2022-50777 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe of_phy_find_device() return device node with refcount incremented. Call put_device() to relese it when not needed anymore. | ||||
| CVE-2022-50640 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mmc: core: Fix kernel panic when remove non-standard SDIO card SDIO tuple is only allocated for standard SDIO card, especially it causes memory corruption issues when the non-standard SDIO card has removed, which is because the card device's reference counter does not increase for it at sdio_init_func(), but all SDIO card device reference counter gets decreased at sdio_release_func(). | ||||
| CVE-2022-50642 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_typec: zero out stale pointers `cros_typec_get_switch_handles` allocates four pointers when obtaining type-c switch handles. These pointers are all freed if failing to obtain any of them; therefore, pointers in `port` become stale. The stale pointers eventually cause use-after-free or double free in later code paths. Zeroing out all pointer fields after freeing to eliminate these stale pointers. | ||||
| CVE-2022-50651 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ethtool: eeprom: fix null-deref on genl_info in dump The similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref on genl_info in dump") is also needed for ethtool eeprom. | ||||
| CVE-2022-50663 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix possible memory leak in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path error_wq_init to fix it. | ||||
| CVE-2022-50677 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: ipmi: fix use after free in _ipmi_destroy_user() The intf_free() function frees the "intf" pointer so we cannot dereference it again on the next line. | ||||
| CVE-2022-50688 | 1 Cobiansoft | 1 Cobian Backup | 2026-04-15 | 8.4 High |
| Cobian Backup Gravity 11.2.0.582 contains an unquoted service path vulnerability that allows local users to potentially execute arbitrary code with elevated system privileges. Attackers can exploit the unquoted service path in the CobianBackup11 service to inject malicious code that would execute with LocalSystem privileges during service startup. | ||||
| CVE-2022-50690 | 1 Wondershare | 1 Mirrorgo | 2026-04-15 | 8.4 High |
| Wondershare MirrorGo 2.0.11.346 contains a local privilege escalation vulnerability due to incorrect file permissions on executable files. Unprivileged local users can replace the ElevationService.exe with a malicious file to execute arbitrary code with LocalSystem privileges. | ||||
| CVE-2023-20587 | 2026-04-15 | 7.1 High | ||
| Improper Access Control in System Management Mode (SMM) may allow an attacker access to the SPI flash potentially leading to arbitrary code execution. | ||||
| CVE-2022-50238 | 1 Microsoft | 1 Windows | 2026-04-15 | 7.4 High |
| The on-endpoint Microsoft vulnerable driver blocklist is not fully synchronized with the online Microsoft recommended driver block rules. Some entries present on the online list have been excluded from the on-endpoint blocklist longer than the expected periodic monthly Windows updates. It is possible to fully synchronize the driver blocklist using WDAC policies. NOTE: The vendor explains that Windows Update provides a smaller, compatibility-focused driver blocklist for general users, while the full XML list is available for advanced users and organizations to customize at the risk of usability issues. | ||||
| CVE-2022-50693 | 1 Splashtop | 1 Splashtop | 2026-04-15 | 8.4 High |
| Splashtop 8.71.12001.0 contains an unquoted service path vulnerability in the Splashtop Software Updater Service that allows local attackers to potentially execute arbitrary code. Attackers can exploit the unquoted path in C:\Program Files (x86)\Splashtop\Splashtop Software Updater\ to inject malicious executables and escalate privileges. | ||||
| CVE-2022-50740 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs() Syzkaller reports a long-known leak of urbs in ath9k_hif_usb_dealloc_tx_urbs(). The cause of the leak is that usb_get_urb() is called but usb_free_urb() (or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev or urb->ep fields have not been initialized and usb_kill_urb() returns immediately. The patch removes trying to kill urbs located in hif_dev->tx.tx_buf because hif_dev->tx.tx_buf is not supposed to contain urbs which are in pending state (the pending urbs are stored in hif_dev->tx.tx_pending). The tx.tx_lock is acquired so there should not be any changes in the list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ||||
| CVE-2023-20599 | 2026-04-15 | 7.9 High | ||
| Improper register access control in ASP may allow a privileged attacker to perform unauthorized access to ASP’s Crypto Co-Processor (CCP) registers from x86 resulting in potential loss of control of cryptographic key pointer/index leading to loss of integrity or confidentiality. | ||||
| CVE-2022-50784 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mei: fix potential NULL-ptr deref after clone If cloning the SKB fails, don't try to use it, but rather return as if we should pass it. Coverity CID: 1503456 | ||||
| CVE-2022-50709 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg() syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line in ath9k_hif_usb_rx_stream(). We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol. | ||||
| CVE-2022-47090 | 2026-04-15 | 7.8 High | ||
| GPAC MP4box 2.1-DEV-rev574-g9d5bb184b contains a buffer overflow in gf_vvc_read_pps_bs_internal function of media_tools/av_parsers.c, check needed for num_exp_tile_columns | ||||
| CVE-2022-50710 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ice: set tx_tstamps when creating new Tx rings via ethtool When the user changes the number of queues via ethtool, the driver allocates new rings. This allocation did not initialize tx_tstamps. This results in the tx_tstamps field being zero (due to kcalloc allocation), and would result in a NULL pointer dereference when attempting a transmit timestamp on the new ring. | ||||