Export limit exceeded: 101069 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (101069 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-90203 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: Squashfs: check block offset is not negative If a negative offset is read off disk (for example the offset into the decompressed fragment block), this will cause squashfs_copy_data() to perform an out of bounds access. Fix by checking if offset is negative, and returning 0. This matches existing behaviour where an offset beyond the block returns 0 bytes copied. To trigger this out of bounds access requires a crafted Squashfs filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be able to mount such a filesystem, but once mounted, an unprivileged user can trigger the out of bounds access by reading the crafted file with the negative offset. | ||||
| CVE-2026-90207 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: midi: Serialize input teardown with event_input snd_midi_input_event() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in snd_rawmidi_input_trigger(): snd_rawmidi_input_trigger(up=0) snd_midi_input_event() -> snd_rawmidi_kernel_read() -> snd_rawmidi_input_trigger(up=1) -> cancel_work_sync() which ends with the underlying device being active unexpectedly. When this is called from close_substream(), further input can re-trigger the input event leaving it running after rawmidi_release_priv() has set rfile->rmidi to NULL which leads to: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 Call trace: snd_midi_input_event+0x3c/0x134 [snd_seq_midi] (P) snd_rawmidi_input_event_work+0x1c/0x2c process_one_work+0x150/0x3a4 worker_thread+0x190/0x318 Apply a similar approach to commit ef7607ab1c8ad ("ALSA: seq: midi: Serialize output teardown with event_input") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1]. With this change in place, midisynth_unsubscribe() clears the input file so snd_midi_input_event() will not re-trigger the stream and will be quiesced by the cancel_work_sync() in snd_rawmidi_input_trigger(). [1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/ | ||||
| CVE-2026-90225 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and then dereferenced the cached pointer inside the locked region. llcp_sock_bind() assigns and clears llcp_sock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on lock_sock(), and then dereference a freed nfc_llcp_local once bind() has unwound. Move the llcp_sock->local read and the NULL check inside the lock_sock(sk) region so bind() cannot mutate or free the pointer between the load and the use. | ||||
| CVE-2026-90289 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Resize MST HDCP per-connector arrays to 32 AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of 32 connectors. But the way it's used is like MAX_DISPLAY_COUNT. Hence we're off by one with DRM core, which supports a max of 32 connectors. Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT to match its actual use, and increase the size to 32 to match the originally intended size. | ||||
| CVE-2026-90392 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential UAF when reading bpf link info In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields. | ||||
| CVE-2026-90419 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent out-of-bounds read in super root block parsing super-root inode metadata size is trusted before nilfs_read_inode_common(). Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfs_read_inode_common() read past the end of the super-root block. [ryusuke: clarify the commit title] | ||||
| CVE-2026-92488 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: complete object teardown when the destroy command fails erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable. Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic. | ||||
| CVE-2026-93137 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free on mm_struct in bpf_find_vma() bpf_find_vma() reads task->mm and calls mmap_read_trylock(mm) without holding a reference on the mm. On a foreign task, a concurrent exit_mm() can free the mm_struct between the lockless read and the trylock, resulting in a use-after-free. mm_struct is not SLAB_TYPESAFE_BY_RCU. For the current task, task->mm is stable. For a foreign task, pin the mm under task->alloc_lock and release it with mmput_async(), mirroring commit d8e27d2d22b6 ("bpf: fix mm lifecycle in open-coded task_vma iterator"). Use spin_trylock() instead of get_task_mm() so BPF context does not block on alloc_lock. Reject irqs-disabled contexts and !CONFIG_MMU on the foreign-task path because dropping the mm reference is not safe there. Race: CPU0 (BPF program) CPU1 (exiting task) ============================ ========================== bpf_find_vma(foreign_task): mm = task->mm exit_mm(): task->mm = NULL mmput(mm) -> frees mm_struct mmap_read_trylock(mm) // UAF on mm | ||||
| CVE-2026-92067 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the Widget: Gtk component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92060 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the Internationalization component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92058 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the Graphics component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92056 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the Graphics: Text component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92049 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the Widget: Win32 component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92046 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the Graphics component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92042 | 1 Mozilla | 1 Firefox | 2026-09-20 | 7.5 High |
| Race condition in the DOM: Content Processes component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. | ||||
| CVE-2026-92040 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the JavaScript: WebAssembly component. This vulnerability was fixed in Firefox 156 and Thunderbird 156. | ||||
| CVE-2026-92029 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the SVG component. This vulnerability was fixed in Firefox 156, Firefox ESR 115.41, Firefox ESR 140.16, Firefox ESR 153.3, Thunderbird 156, Thunderbird 140.16, and Thunderbird 153.3. | ||||
| CVE-2026-92028 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 156, Firefox ESR 115.41, Firefox ESR 140.16, Firefox ESR 153.3, Thunderbird 156, Thunderbird 140.16, and Thunderbird 153.3. | ||||
| CVE-2026-92024 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the SVG component. This vulnerability was fixed in Firefox 156, Firefox ESR 115.41, Firefox ESR 140.16, Firefox ESR 153.3, Thunderbird 156, Thunderbird 140.16, and Thunderbird 153.3. | ||||
| CVE-2026-92023 | 1 Mozilla | 1 Firefox | 2026-09-20 | 8.8 High |
| Use-after-free in the XML component. This vulnerability was fixed in Firefox 156, Firefox ESR 115.41, Firefox ESR 140.16, Firefox ESR 153.3, Thunderbird 156, Thunderbird 140.16, and Thunderbird 153.3. | ||||