Export limit exceeded: 401155 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 25008 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (25008 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-97479 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: driver core: Avoid warning when removing a device while its supplier is unbinding During driver removal, the following warning can appear: WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc ... Call trace: __device_links_no_driver+0xcc/0xfc (P) device_links_driver_cleanup+0xa8/0xf0 device_release_driver_internal+0x208/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c device_links_unbind_consumers+0xe0/0x108 device_release_driver_internal+0xec/0x23c driver_detach+0xa0/0x12c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 pci_unregister_driver+0x20/0x9c lan966x_pci_driver_exit+0x18/0xa90 [lan966x_pci] This warning is triggered when a consumer is removed because the links status of its supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY is not set. The topology in terms of consumers/suppliers used was the following (consumer ---> supplier): i2c -----------> OIC ----> PCI device | ^ | | +---> pinctrl ---+ When the PCI device is removed, the OIC (interrupt controller) has to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c need to be removed. The removal order is: 1) i2c 2) pinctrl 3) OIC 4) PCI device In details, the removal sequence is the following (with 0000:01:00.0 the PCI device): driver_detach: call device_release_driver_internal(0000:01:00.0)... device_links_busy(0000:01:00.0): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(0000:01:00.0): 0000:01:00.0--oic link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(oic)... device_links_busy(oic): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(oic): oic--pinctrl link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(pinctrl)... device_links_busy(pinctrl): links->status = DL_DEV_UNBINDING device_links_unbind_consumers(pinctrl): pinctrl--i2c link->status = DL_STATE_SUPPLIER_UNBIND call device_release_driver_internal(i2c)... device_links_busy(i2c): links->status = DL_DEV_UNBINDING __device_links_no_driver(i2c)... pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND oic--i2c link->status is DL_STATE_ACTIVE oic--i2c link->supplier->links.status is DL_DEV_UNBINDING The warning is triggered by the i2c removal because the OIC (supplier) links status is not DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING. It is perfectly legit to have the links status set to DL_DEV_UNBINDING in that case. Indeed we had started to unbind the OIC which triggered the consumer unbinding and didn't finish yet when the i2c is unbound. Avoid the warning when the supplier links status is set to DL_DEV_UNBINDING and thus support this removal sequence without any warnings. | ||||
| CVE-2026-97412 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: pds_core: quiesce DMA before freeing resources pdsc_teardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory. Add pci_clear_master() to pdsc_teardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced. Add pci_set_master() to pdsc_setup() to re-enable bus mastering, which is needed for the firmware recovery path since pdsc_teardown() now disables it. | ||||
| CVE-2026-84842 | 2 Ibm, Linux | 2 Guardium Data Protection, Linux Kernel | 2026-10-01 | 8.1 High |
| IBM Guardium Data Protection 12.2 is vulnerable to path traversal and arbitrary file deletion in the Datasource REST component. An authenticated remote attacker could exploit this vulnerability to delete files and potentially cause denial of service or impact system integrity. | ||||
| CVE-2026-84440 | 2 Ibm, Linux | 2 Guardium Data Protection, Linux Kernel | 2026-10-01 | 7.5 High |
| IBM Guardium Data Protection 12.2 is vulnerable to command injection in the SNMP alert notification functionality. An authenticated attacker who can influence policy alert text can cause attacker-controlled data to be executed as operating system commands by the SNMP alerter service, which runs with root privileges. | ||||
| CVE-2026-97423 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cxl/region: Validate partition index before array access construct_region() reads cxled->part and uses it to index cxlds->part[] without checking for a negative value. If the partition was never resolved, part remains at its initial value of -1, causing an out-of-bounds array access. Add a guard to return -EBUSY when part is negative. The check was dropped during a merge. | ||||
| CVE-2026-97424 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq cp_ecc_error_irq is acquired in amdgpu_gfx_ras_late_init() but released in gfx_v9_0_hw_fini(), so the put site has to query amdgpu_irq_enabled() because the get is skipped on SR-IOV VF. ras_late_init / ras_fini have no suspend counterpart, so move the put to amdgpu_gfx_ras_suspend() / amdgpu_gfx_ras_fini() and add a matching ras_suspend callback that is invoked from amdgpu_ras_suspend() before disable_all_features(). The get and put now sit in the same place and check the same condition (not VF, funcs registered), no refcount querying needed. An active flag gates ras_fini so the suspend-then-unload-without-resume path falls into amdgpu_ras_block_late_fini_default() instead of double-releasing what ras_suspend already cleaned up. Drop the cp_ecc_error_irq put from gfx_v9_0_hw_fini(). gfx_v8_0 manages cp_ecc_error_irq locally and is unaffected; no other GFX generation has this IRQ. | ||||
| CVE-2026-97426 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: fix SmartShift bias sysfs store PM refcount on parse error Return the parse error before acquiring PM access. | ||||
| CVE-2026-97443 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/ftrace: Fix WARNING in __unregister_ftrace_function perf_ftrace_function_unregister() unconditionally calls unregister_ftrace_function() without checking whether the ftrace_ops was ever successfully registered. This triggers a WARN_ON in __unregister_ftrace_function() when the ops doesn't have FTRACE_OPS_FL_ENABLED set. This can happen during perf_event_alloc() error cleanup when perf_trace_destroy() is called via __free_event() on an event whose ftrace_ops registration failed or was already torn down by perf_try_init_event()'s err_destroy path. The call path is: perf_event_alloc() error cleanup -> __free_event() -> event->destroy() [tp_perf_event_destroy] -> perf_trace_destroy() -> perf_trace_event_close() -> TRACE_REG_PERF_CLOSE -> perf_ftrace_function_unregister() -> unregister_ftrace_function() -> __unregister_ftrace_function() -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED)) Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to unregister. If the ops is not enabled, just free the filter and return success. | ||||
| CVE-2026-97473 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked() When topology_physical_package_id()/topology_logical_die_id() returns a negative value, rapl_add_package_cpuslocked() returns ERR_PTR(-EINVAL) directly without freeing the rapl_package structure that was just allocated by kzalloc_obj(), leaking memory on every failed package addition. Use the existing err_free_package label so that the allocation is released on the error path. | ||||
| CVE-2026-97477 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/counter: Fix num_counters leak on bind_qp failure in alloc_and_bind() When __rdma_counter_bind_qp() fails in alloc_and_bind(), the error path jumps to err_mode which frees the counter without decrementing port_counter->num_counters. The only place that decrements is rdma_counter_free(), which is unreachable since the counter was never successfully bound. This leak accumulates across repeated failures, permanently preventing the port from switching to AUTO mode (-EBUSY in __counter_set_mode()) and blocking the MANUAL→NONE auto-revert in rdma_counter_free(). When the mode was NONE before the call, the MANUAL mode set by __counter_set_mode() also leaks since the revert logic is never reached. Add an err_bind label between the num_counters increment and the existing err_mode label. It decrements num_counters and mirrors the MANUAL→NONE revert from rdma_counter_free(), ensuring the port state is fully restored on bind failure. | ||||
| CVE-2026-97493 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Bound GPIO I2C table entry count from VBIOS Reject undersized tables and cap the derived entry count to AMDGPU_MAX_I2C_BUS so we do not overrun adev->i2c_bus[] or walk an absurd number of entries on corrupt size fields. | ||||
| CVE-2026-97511 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: avoid out-of-bounds access in monitor In NAN, we don't know on what band the frame will be sent. Therefore we set info->band to NUM_NL80211_BANDS. However, this leads to out-of-bound access in ieee80211_add_tx_radiotap_header when we try to access the sbands array. Fix it by not accessing the array if the band is NUM_NL80211_BANDS. This means that we will not report rate info for legacy rate in NAN. But nobody really cares about it. | ||||
| CVE-2026-97533 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF A previous commit protected against races between ptdump and CPA collapse, however one still exists between attribute changes and collapse as reported by Denis V. Lunev (linked). When an attribute change arises, a lockless page table walker obtains a PTE entry, which is later written to via set_pte_atomic(): ... -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> _lookup_address_cpa() -> lookup_address_in_pgd_attr() -> [ lockless page table walker ] -> set_pte_atomic() There is nothing preventing a concurrent CPA collapse which can free the PTE that was retrieved here, resulting in a use-after-free. With the mmap write lock taken on init_mm over CPA collapse, resolve this race by acquiring an mmap read lock on init_mm over __change_page_attr_set_clr(). This locks across the whole operation over which the walk and the PTE entry write occurs, solving the race. It is safe to do this here, as no spinlocks are held upon entry to __change_page_attr_set_clr(). However, the lock must not be held over an allocation, as allocation can trigger reclaim and shrinkers may call into CPA recursively, making deadlocks possible (init_mm -> ... -> fs_reclaim -> init_mm). A page table is allocated when a huge page needs to be split: -> change_page_attr_set_clr() -> __change_page_attr_set_clr() -> __change_page_attr() -> split_large_page() [ pagetable_alloc() ] -> __split_large_page() Avoid deadlocks by dropping the mmap lock across pagetable_alloc() in split_large_page() and track whether this is needed by adding a new 'init_mm_read_locked' flag to struct cpa_data. This is safe as __split_large_page() (called with locks re-established) revalidates that the page table entry is the same as it was prior to the locks being dropped and __change_page_attr() repeats the entire page table walk whenever a split occurs, so concurrent split and collapse are accounted for. Concurrent ptdump is also safe as the lock is only dropped over page table allocation during which time the page table has not yet been modified. The CPA_COLLAPSE flag is only set by set_memory_rox(), which exclusively operates upon vmalloc ranges, and on x86 only within the module mapping space. This is important, because some callers directly invoke __change_page_attr_set_clr(), bypassing this lock. However, none of these operate within the module mapping space. * cpa_process_alias() - a recursive helper called by __change_page_attr_set_clr(). * __set_memory_enc_pgtable() - operates on the direct mapping and (via __vmbus_establish_gpadl()) the vmalloc mapping space. * __set_pages_[n]p() - called by set_direct_map_[invalid, default, valid]_noflush(), __kernel_map_pages() - operates on the direct map. * kernel_[un]map_pages_in_pgd() - operates on EFI ranges. This work is based upon Denis V. Lunev's excellent analysis of the bug with gratitude. [ dhansen: move to imperative voice in changelog ] | ||||
| CVE-2026-97525 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Allocate split page tables as kernel page tables A PTE is allocated directly without going through the standard page table allocation routines (such as pte_alloc_one_kernel()) when the CPA code splits a large page (__split_large_page()). This means the page table constructor is never called nor is the page table marked as a kernel page table. The former results in the folio associated with the page table not being marked as a page table (__pagetable_ctor() is never called thus neither is __folio_set_pgtable()) nor are statistics updated to reflect it (lruvec_stat_add_folio() is never called). The latter issue of failing to mark the page table as a kernel page table (ptdesc_set_kernel() is never called) is far more problematic. Since commit: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") kernel page table freeing has been batched and since the subsequent commit: e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space") IOTLB cache entries for kernel page tables have been invalidated upon being freed. Since split page tables are freed without this invalidation, the IOTLB can contain stale entries for them. Resolve the issue by using the ordinary PTE allocation API at split time. This results in these kernel page tables invoking a page table constructor, and thus requires a page table destructor. Destructors are not always present, like for early allocated direct map page tables). Conditionally call pagetable_dtor_free() if the PG_table folio flag for the ptdesc is set, otherwise we free the page table via pagetable_free(). Regardless of which path is taken page tables marked as kernel page tables, which now includes split page tables, take the correct route through pagetable_free_kernel(). There is a user-visible side effect in that split page tables will appear in nr_page_table_pages in /proc/vmstat (as do other kernel page tables allocated after early boot), however this is a positive change. This issue started being markedly problematic after commit: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") so choose this as the Fixes target. [ dhansen: rephrase in imperative mood ] | ||||
| CVE-2026-97501 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning. While this class of Mediatek hardware does not have separate clear/set registers, the pinctrl context has a spinlock that is taken whenever a register read-modify-write is done. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options. Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmxops to signal we are no longer using the pinctrl GPIO layer for setting the direction. | ||||
| CVE-2026-97503 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: genirq/proc: Size interrupt directory names for 10-digit interrupt numbers /proc/irq/<n>/ directory names are built in `char name[10]` buffers with `sprintf(name, "%u", irq)`. Ten-digit IRQ numbers already need 11 bytes including the trailing NUL, and current sparse-IRQ configurations allow interrupt numbers in that range. Size the temporary name buffer for the current decimal form and switch to bounded formatting when creating or removing the proc entry. | ||||
| CVE-2026-97504 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: watchdog: lenovo_se10_wdt: Fix use-after-free and resource leak risk Review by sashiko.dev highlighted potential use after free and resource leak instances. Set se10_pdev to null to prevent use after free Remove DMI call back and instead directly call se10_create_platform_device. Handle error cases appropriately | ||||
| CVE-2026-97505 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store() Currently, the __resource_resize_store() allows writing to the resourceN_resize sysfs attribute to change a BAR's size without checking for capabilities, currently relying only on the file access check. Resizing a BAR modifies PCI device configuration and can disrupt active drivers. After the upcoming conversion to static attributes, it will also trigger resource file updates via sysfs_update_groups(). Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR resize operations. | ||||
| CVE-2026-97513 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Release m2m_ctx after Instance Removed from List Possible use after free if IRQ thread manages to obtain spinlock between m2m_ctx release and wave5_release function removing stream instance from list of active instances. The IRQ thread looks for the m2m_ctx which is freed so null pointer dereference occurs. | ||||
| CVE-2023-1989 | 4 Debian, Linux, Netapp and 1 more | 11 Debian Linux, Linux Kernel, H300s and 8 more | 2026-10-01 | 7 High |
| A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. A call to btsdio_remove with an unfinished job may cause a race problem which leads to a UAF on hdev devices. | ||||