Export limit exceeded: 25020 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (25020 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80918 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up. | ||||
| CVE-2026-80920 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: io_uring: defer eventfd signaling when queued from a wakeup handler io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held. eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll. Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline. | ||||
| CVE-2026-80916 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: kcov: fix data corruption and race conditions on PREEMPT_RT syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area. On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state. Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites. Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state. It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in (1) doing vmalloc() in kcov_remote_start() despite !in_task() context (2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE (3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes problems. | ||||
| CVE-2026-80917 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using "pci-host-cam-generic" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [<c038db9c>] pci_generic_config_read+0x40/0xb0 [<c038da04>] pci_bus_read_config_dword+0x50/0xb0 [<c0391e94>] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [<c039245c>] pci_scan_single_device+0xa4/0x11c [<c0392570>] pci_scan_slot+0x9c/0x23c [<c039388c>] pci_scan_child_bus_extend+0x58/0x2f4 [<c0393db0>] pci_scan_root_bus_bridge+0x64/0xe8 [<c0393e54>] pci_host_probe+0x20/0xc8 [<c03bc6f4>] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log] | ||||
| CVE-2026-80922 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Allow zero as a random number Zero is a valid random number and needs to be allowed. Otherwise the output is distinguishable from random. | ||||
| CVE-2026-0291 | 3 Linux, Palo Alto Networks, Paloaltonetworks | 3 Linux Kernel, Prisma Access Agent, Prisma Access Agent | 2026-09-09 | 4.4 Medium |
| An improper link resolution before file access vulnerability exists in the Palo Alto Networks Prisma® Access Agent on Linux platforms that enables a local low privileged user to delete system files in a limited scope and disable Prisma Access Agent. The Prisma Access Agent on macOS, Windows, iOS, Android, and Chrome OS is not affected. | ||||
| CVE-2026-80923 | 1 Linux | 1 Linux Kernel | 2026-09-09 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free | ||||
| CVE-2026-77104 | 3 Commvault, Linux, Microsoft | 3 Commvault, Linux Kernel, Windows | 2026-09-09 | 7.5 High |
| CommServe contained a path traversal issue affecting information disclosure. Software customers upgrade to resolved maintenance release. Update CommServe. | ||||
| CVE-2026-77103 | 3 Commvault, Linux, Microsoft | 3 Commvault, Linux Kernel, Windows | 2026-09-09 | 7.5 High |
| CommServe contained an authentication bypass issue affecting access authorization and information disclosure. Software customers upgrade to resolved maintenance release. Update CommServe. | ||||
| CVE-2026-77102 | 3 Commvault, Linux, Microsoft | 3 Commvault, Linux Kernel, Windows | 2026-09-09 | 7.5 High |
| CommServe contained a heap-based buffer overflow issue affecting service availability. Software customers upgrade to resolved maintenance release. Update CommServe. | ||||
| CVE-2026-77101 | 3 Commvault, Linux, Microsoft | 3 Commvault, Linux Kernel, Windows | 2026-09-09 | 7.5 High |
| CommServe contained a stack-based buffer overflow issue affecting service availability. Software customers upgrade to resolved maintenance release. Update CommServe. | ||||
| CVE-2026-77105 | 3 Commvault, Linux, Microsoft | 3 Commvault, Linux Kernel, Windows | 2026-09-09 | 8.8 High |
| CommServe contained a cryptographic signature verification issue affecting privilege management. Software customers upgrade to resolved maintenance release. Update CommServe and Web Server. | ||||
| CVE-2026-17622 | 5 Apple, Ibm, Langflow and 2 more | 5 Macos, Langflow Oss, Langflow and 2 more | 2026-09-09 | 6.5 Medium |
| IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory. | ||||
| CVE-2026-17627 | 5 Apple, Ibm, Langflow and 2 more | 5 Macos, Langflow Oss, Langflow and 2 more | 2026-09-09 | 4.9 Medium |
| IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information and inject messages into workflow history due to improper authorization. | ||||
| CVE-2026-17631 | 5 Apple, Ibm, Langflow and 2 more | 5 Macos, Langflow Oss, Langflow and 2 more | 2026-09-09 | 5 Medium |
| IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery (SSRF) vulnerability. | ||||
| CVE-2026-53322 | 1 Linux | 1 Linux Kernel | 2026-09-09 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Clean up DMABUFs before disabling function On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver. | ||||
| CVE-2026-53277 | 1 Linux | 1 Linux Kernel | 2026-09-09 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation walk_s1() and kvm_walk_nested_s2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the respective walkers without taking kvm->srcu. Fix by acquiring kvm->srcu prior to the table walk in both instances. | ||||
| CVE-2026-53185 | 1 Linux | 1 Linux Kernel | 2026-09-09 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed. | ||||
| CVE-2026-53009 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-09-09 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ice: fix double-free of tx_buf skb If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time. The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path. The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch. I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN. I looked for similar bugs in related Intel drivers and did not find any. | ||||
| CVE-2026-46189 | 1 Linux | 1 Linux Kernel | 2026-09-09 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free. | ||||