Export limit exceeded: 349059 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (349059 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-43163 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update. | ||||
| CVE-2026-43175 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841 The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure there are 8 slots for those newly registered clk_hw pointers, else there is going to be out of bounds write when pointers 4..7 are set into struct rs9_driver_data .clk_dif[4..7] field. Since there are other structure members past this struct clk_hw pointer array, writing to .clk_dif[4..7] fields corrupts both the struct rs9_driver_data content and data around it, sometimes without crashing the kernel. However, the kernel does surely crash when the driver is unbound or during suspend. Fix this, increase the struct clk_hw pointer array size to the maximum output count of 9FGV0841, which is the biggest chip that is supported by this driver. | ||||
| CVE-2026-43179 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix incorrect early exits for invalid metabox-enabled images Crafted EROFS images with metadata compression enabled can trigger incorrect early returns, leading to folio reference leaks. However, this does not cause system crashes or other severe issues. | ||||
| CVE-2026-43191 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust PHY FSM transition to TX_EN-to-PLL_ON for TMDS on DCN35 [Why] A backport of the change made for DCN401 that addresses an issue where we turn off the PHY PLL when disabling TMDS output, which causes the OTG to remain stuck. The OTG being stuck can lead to a hang in the DCHVM's ability to ACK invalidations when it thinks the HUBP is still on but it's not receiving global sync. The transition to PLL_ON needs to be atomic as there's no guarantee that the thread isn't pre-empted or is able to complete before the IOMMU watchdog times out. [How] Backport the implementation from dcn401 back to dcn35. There's a functional difference in when the eDP output is disabled in dcn401 code so we don't want to utilize it directly. | ||||
| CVE-2026-43200 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functions struct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target); While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specify the parameters in the correct order, pci_primary_epc_epf_unlink() and pci_secondary_epc_epf_unlink() specify the parameters in the wrong order, leading to the below kernel crash when using the unlink command in configfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0 [mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen] | ||||
| CVE-2026-43201 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ARM processor Error: don't go past allocated memory If the BIOS generates a very small ARM Processor Error, or an incomplete one, the current logic will fail to deferrence err->section_length and ctx_info->size Add checks to avoid that. With such changes, such GHESv2 records won't cause OOPSes like this: [ 1.492129] Internal error: Oops: 0000000096000005 [#1] SMP [ 1.495449] Modules linked in: [ 1.495820] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.18.0-rc1-00017-gabadcc3553dd-dirty #18 PREEMPT [ 1.496125] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 [ 1.496433] Workqueue: kacpi_notify acpi_os_execute_deferred [ 1.496967] pstate: 814000c5 (Nzcv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1.497199] pc : log_arm_hw_error+0x5c/0x200 [ 1.497380] lr : ghes_handle_arm_hw_error+0x94/0x220 0xffff8000811c5324 is in log_arm_hw_error (../drivers/ras/ras.c:75). 70 err_info = (struct cper_arm_err_info *)(err + 1); 71 ctx_info = (struct cper_arm_ctx_info *)(err_info + err->err_info_num); 72 ctx_err = (u8 *)ctx_info; 73 74 for (n = 0; n < err->context_info_num; n++) { 75 sz = sizeof(struct cper_arm_ctx_info) + ctx_info->size; 76 ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + sz); 77 ctx_len += sz; 78 } 79 and similar ones while trying to access section_length on an error dump with too small size. [ rjw: Subject tweaks ] | ||||
| CVE-2026-43202 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached. | ||||
| CVE-2026-43204 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6asm: drop DSP responses for closed data streams 'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses after closing")' attempted to ignore DSP responses arriving after a stream had been closed. However, those responses were still handled, causing lockups. Fix this by unconditionally dropping all DSP responses associated with closed data streams. | ||||
| CVE-2026-43210 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing: ring-buffer: Fix to check event length before using Check the event length before adding it for accessing next index in rb_read_data_buffer(). Since this function is used for validating possibly broken ring buffers, the length of the event could be broken. In that case, the new event (e + len) can point a wrong address. To avoid invalid memory access at boot, check whether the length of each event is in the possible range before using it. | ||||
| CVE-2026-43220 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu/amd: serialize sequence allocation under concurrent TLB invalidations With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return. | ||||
| CVE-2026-43221 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipmi: ipmb: initialise event handler read bytes IPMB doesn't use i2c reads, but the handler needs to set a value. Otherwise an i2c read will return an uninitialised value from the bus driver. | ||||
| CVE-2026-43224 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix sgtable leak on mapping failures In an unlikely case when io_populate_area_dma() fails, which could only happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine, io_zcrx_map_area() will have an initialised and not freed table. It was supposed to be cleaned up in the error path, but !is_mapped prevents that. | ||||
| CVE-2026-43229 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Fix device cleanup order to prevent kernel panic Move video device unregistration to the beginning of the remove function to ensure all video operations are stopped before cleaning up the worker thread and disabling PM runtime. This prevents hardware register access after the device has been powered down. In polling mode, the hrtimer periodically triggers wave5_vpu_timer_callback() which queues work to the kthread worker. The worker executes wave5_vpu_irq_work_fn() which reads hardware registers via wave5_vdi_read_register(). The original cleanup order disabled PM runtime and powered down hardware before unregistering video devices. When autosuspend triggers and powers off the hardware, the video devices are still registered and the worker thread can still be triggered by the hrtimer, causing it to attempt reading registers from powered-off hardware. This results in a bus error (synchronous external abort) and kernel panic. This causes random kernel panics during encoding operations: Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Modules linked in: wave5 rpmsg_ctrl rpmsg_char ... CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread Tainted: G M W pc : wave5_vdi_read_register+0x10/0x38 [wave5] lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5] Call trace: wave5_vdi_read_register+0x10/0x38 [wave5] kthread_worker_fn+0xd8/0x238 kthread+0x104/0x120 ret_from_fork+0x10/0x20 Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: synchronous external abort: Fatal exception | ||||
| CVE-2026-7932 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | 4.4 Medium |
| Insufficient policy enforcement in Downloads in Google Chrome prior to 148.0.7778.96 allowed a local attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-7937 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | 3.1 Low |
| Insufficient policy enforcement in DevTools in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension. (Chromium security severity: Medium) | ||||
| CVE-2026-7946 | 4 Apple, Google, Linux and 1 more | 5 Macos, Chrome, Chrome Os and 2 more | 2026-05-07 | 4.3 Medium |
| Insufficient policy enforcement in WebUI in Google Chrome on Linux, Mac, Windows, ChromeOS prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-7958 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-05-07 | 5.4 Medium |
| Inappropriate implementation in ServiceWorker in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to inject arbitrary scripts or HTML (UXSS) via a crafted Chrome Extension. (Chromium security severity: Medium) | ||||
| CVE-2026-43077 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Fix minimum RX size check for decryption The check for the minimum receive buffer size did not take the tag size into account during decryption. Fix this by adding the required extra length. | ||||
| CVE-2026-43123 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fbcon: check return value of con2fb_acquire_newinfo() If fbcon_open() fails when called from con2fb_acquire_newinfo() then info->fbcon_par pointer remains NULL which is later dereferenced. Add check for return value of the function con2fb_acquire_newinfo() to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ||||
| CVE-2026-43127 | 1 Linux | 1 Linux Kernel | 2026-05-07 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix circular locking dependency in run_unpack_ex Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock. The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone(). This creates an AB-BA deadlock. Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock. | ||||