Export limit exceeded: 414500 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (414500 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-99090 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: serialize vblank counter reads against GPU reset The vblank counter callback reads display registers and scanout position without holding reset_domain->sem. During GPU recovery, display commit work can call the callback while reset owns the semaphore for writing. The hardware access then triggers the lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets TAINT_WARN when lockdep is enabled. Try to acquire the reset semaphore for reading before accessing the hardware, and hold it across the counter and scanout-position reads. If reset is already in progress, return DRM's cached software vblank count instead. This avoids blocking behind reset and avoids accessing display hardware while it is being reset. The cached count is less accurate than the hardware count, but is used only when reset prevents a safe hardware read. This addresses the reset-time warning from this vblank path; it does not suppress or fix unrelated lockdep warnings. (cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934) | ||||
| CVE-2026-99091 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix status of pending commands flushed on power off cmd_complete_rsp() receives a struct cmd_lookup and, for a pending command that has no cmd_complete callback, falls through to cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so the status sent comes from the first byte of match->sk's representation, not from match->mgmt_status. commit f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") changed the callers' data from &status to &match and updated the cmd_complete branch to match->mgmt_status, but left the fall-through passing data unchanged. In mgmt_index_removed() match->sk is NULL, so every such command is answered with status 0x00 (Success) instead of MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too, unless a Set Powered command was pending: then settings_rsp() has stored that command's socket in match->sk, and the byte sent comes from the socket pointer. Either way the status the caller set, MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device is being unregistered), is lost. Pass the status the callers set. This was seen on a QCA9377 laptop: bluetoothd's Start Discovery, pending when the adapter was powered off, was answered with Command Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the zero-length success. BlueZ master has since added the length check on that path ("adapter: Fix crash on short start discovery reply", BlueZ a734b06059cb), but userspace should still be told Not Powered, not Success. Tested on Ubuntu 7.0.0-31 with a virtual controller (hci_vhci): power off is held in HCI Write Scan Enable while a Start Discovery is submitted, and the flush answers it with status 0x00 before this change and 0x0f (Not Powered) after. | ||||
| CVE-2026-99092 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: riscv: patch: fix handling of bpf-jit execmem addresses Commit 8718e5a3090b ("riscv: patch: skip fixmap mapping when kernel text is already writable") gated the core_kernel_text() branch of patch_map() on CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch unchanged. That branch has a separate problem. That branch only creates a temporary writable fixmap alias when CONFIG_STRICT_MODULE_RWX is enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That assumption no longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack unconditionally in alloc_new_pack(), independently of any CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is read-only regardless of what CONFIG_STRICT_MODULE_RWX says. With CONFIG_STRICT_MODULE_RWX=n, patch_map() returns the read-only address directly, the subsequent copy_to_kernel_nofault() takes a page fault and returns -EFAULT. bpf_arch_text_copy() turns that into -EINVAL, which propagates through bpf_jit_binary_pack_finalize() to the WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed. Note that BPF cannot be fixed the way kprobes was in commit bdc46e507b59 ("riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX"). EXECMEM_BPF is already PAGE_KERNEL, i.e. writable at allocation time; the read-only mapping is established afterwards by generic code in alloc_new_pack(), which arch code cannot influence. The only place this can be handled is patch_map(). This is the same problem that was fixed on arm64 by commit b1480ed230ac ("arm64: patching: fix handling of execmem addresses"), and the fix is the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc area can hold executable memory that needs a temporary alias to be written. CONFIG_BPF_JIT, CONFIG_KPROBES and CONFIG_MODULES all select it. Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can be disabled with CONFIG_MODULES=y as well, and the bug is reachable in that configuration too. The !CONFIG_MMU build is unaffected: it has its own __patch_insn_set() and __patch_insn_write() implementations and never calls patch_map(). | ||||
| CVE-2026-99093 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mm: don't schedule deferred kernel page table freeing while booting Booting with a boot-time function tracer and a filter, for example ftrace=function ftrace_filter=pud_free_pmd_page panics on 7.3-rc4 as soon as the tracer starts: [ 23.531178] Starting tracer 'function' [ 23.675800] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN NOPTI [ 23.819917] KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] [ 23.964025] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.3.0-rc4-fe2ec83746e5-with-fixes-v2+ #195 PREEMPT(undef) [ 24.252248] RIP: 0010:__queue_work+0xab/0xf00 [ 25.981629] Call Trace: [ 26.125727] <TASK> [ 26.413912] ? pagetable_free_kernel+0x20/0x120 [ 26.990283] queue_work_on+0x97/0xf0 [ 27.134382] __cpa_collapse_large_pages+0x501/0x6f0 [ 27.566662] cpa_flush+0x394/0x620 [ 27.998953] change_page_attr_set_clr+0x321/0x4a0 [ 29.151729] set_memory_rox+0xa2/0xf0 [ 29.584018] create_trampoline+0x431/0x6f0 ... [ 44.343347] Kernel panic - not syncing: Attempted to kill the idle task! The boot-time tracer is started from early_trace_init(), which runs before workqueue_init_early(). Making its trampoline read-only splits a large page, and CPA collapses it again right away. The split table has been a kernel page table since commit 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables"), so the collapse frees it through pagetable_free_kernel(), which queues work on system_percpu_wq - still NULL at that point. That commit is correct in itself; it only lets CPA reach pagetable_free_kernel() before the workqueue that function relies on exists. Keep putting the table on the list, but don't schedule the work while the system is still booting. A core_initcall schedules it once to free whatever was queued by then. | ||||
| CVE-2026-69978 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-26 | 5.6 Medium |
| Null pointer dereference in Windows VMSwitch allows an authorized attacker to deny service locally. | ||||
| CVE-2026-69979 | 1 Microsoft | 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more | 2026-10-26 | 5.5 Medium |
| Improper protection of alternate path in Windows AppX Deployment Service allows an authorized attacker to bypass a security feature locally. | ||||
| CVE-2026-69982 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows Server 2012 and 10 more | 2026-10-26 | 5.9 Medium |
| Weak authentication in Active Directory Federation Services (AD FS) allows an unauthorized attacker to bypass a security feature over a network. | ||||
| CVE-2026-69984 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-26 | 7.5 High |
| Use after free in Remote Desktop Client allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-69985 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-26 | 8.8 High |
| Heap-based buffer overflow in Windows Libarchive allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-105723 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-26 | 7.5 High |
| Untrusted pointer dereference in Windows Distributed File System (DFS) allows an unauthorized attacker to elevate privileges over a network. | ||||
| CVE-2026-105722 | 1 Microsoft | 17 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 14 more | 2026-10-26 | 7 High |
| Use after free in Windows Broadcast DVR User Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-95127 | 2026-10-26 | 7.5 High | ||
| An issue in libass v.0.17.5 allows a remote attacker to cause a denial of service via the ass_outline_construct() in libass/ass_render.c | ||||
| CVE-2026-94402 | 1 Ibm | 5 Carbon Charts, Carboncharts Angular, Carboncharts React and 2 more | 2026-10-26 | 6.1 Medium |
| IBM Carbon Charts 0.4.0 through 1.27.19 is vulnerable to cross-site scripting. The MeterChart component's Title.truncateTitle() function re-inserts a substring of user-supplied label text into the DOM via an unsanitized innerHTML write when the title exceeds the available container width. A remote attacker could exploit this vulnerability to execute arbitrary JavaScript in the victim's browser session. | ||||
| CVE-2026-78801 | 2026-10-26 | 4.3 Medium | ||
| An issue in SKYWORTH DIGITAL CO., LTD SK-WR6640X Wi-Fi 6 Dual-Band Fiber Router (AX1800M) V1.0.3 allows a remote attacker to obtain sensitive information via the hidden_factory_switch.gch | ||||
| CVE-2026-77058 | 1 Boneio | 1 Boneio | 2026-10-26 | N/A |
| boneIO Black is vulnerable to Cross-Site Request Forgery (CSRF) on all state-changing API endpoints because it lacks CSRF tokens and does not validate Origin or Referer headers. A remote attacker can craft a malicious webpage that, when visited by a user on the internal network, sends cross-origin requests to the device. This allows the attacker to reboot the controller, toggle relay circuits, control gates and blinds, or shut down the device, causing loss of integrity and availability. Critically, due to CVE-2026-77053 (authentication disabled by default), any user on the same internal network can trigger attacker-controlled actions by visiting the malicious website. This issue was fixed in version 1.6.0. | ||||
| CVE-2026-77056 | 1 Boneio | 1 Black Debian Images | 2026-10-26 | N/A |
| boneIO black_debian_images ships with a Mosquitto MQTT broker that uses the same default credentials on all devices. These credentials are publicly documented on github, and there is no indication in the instructions to change them. A remote attacker can use them to gain full read and write access to the broker, allowing control of connected relays, blinds, and gates, and injection of fake entities into a linked Home Assistant installation. This issue was fixed in version 1.6.0 of the image: MQTT passwords are generated per device at first boot. Devices upgraded from earlier versions keep their existing broker credentials; from boneio 1.6.0 the web panel reports credentials that are still the published defaults, and the owner has to change them. | ||||
| CVE-2026-77054 | 1 Boneio | 1 Boneio | 2026-10-26 | N/A |
| boneIO Black stores passwords, including the MQTT broker and web panel passwords, in cleartext. The GET /api/config endpoint returns the full configuration with sub-services passwords exposed. Any authenticated user can call the endpoint and access the administrative passwords in cleartext form. Critically, due to CVE-2026-77053 (authentication disabled by default), an unauthenticated attacker on the same local network can retrieve all passwords. This issue was fixed in version 1.6.0: web panel passwords are stored as salted scrypt hashes in a file readable only by the service account, and the API and logs no longer return secret values. The MQTT broker password has to stay recoverable because the application presents it to the broker as a client; it is kept in a separate file readable only by the service account and is no longer exposed through the API. | ||||
| CVE-2026-76308 | 1 Splunk | 1 Splunk | 2026-10-26 | 6.5 Medium |
| In Splunk SOAR versions below 8.7.0, an authenticated user could change the Enterprise Security edition through the Representational State Transfer (REST) API and cause Splunk SOAR to apply the license change. The vulnerability is possible because Splunk SOAR authenticates requests to manage the Enterprise Security edition but does not authorize the caller before it applies the license change. For more information see Using the REST API reference for Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/rest-api-reference/8.7.0/using-the-splunk-soar-rest-api/using-the-rest-api-reference-for-splunk-soar-on-premises), Obtain and configure a Splunk SOAR (On-premises) license (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.7.0/configure-your-companys-settings-in-splunk-soar-on-premises/obtain-and-configure-a-splunk-soar-on-premises-license), and Integration of Splunk SOAR with Splunk Enterprise Security (https://help.splunk.com/en/splunk-enterprise-security-8/administer/8.7/automation-with-playbooks/integration-of-splunk-soar-with-splunk-enterprise-security) in the Splunk documentation. | ||||
| CVE-2026-76304 | 1 Splunk | 1 Splunk | 2026-10-26 | 4.3 Medium |
| In Splunk SOAR versions below 8.7.0, an authenticated user who does not hold a role with permission to edit Automation Brokers could download the Splunk SOAR Automation Broker Docker Compose configuration file. The file contains the Uniform Resource Locator (URL) of the Splunk SOAR instance, the container image location, and the Splunk SOAR Automation Broker version. The vulnerability is possible because Splunk SOAR returns the configuration file without enforcing the Automation Broker edit permission. For more information see Install Splunk Automation Broker on a Docker host (https://help.splunk.com/en/splunk-soar/splunk-automation-broker/install-and-create-classic-splunk-soar-automation-brokers/install-splunk-automation-broker-on-a-docker-host) and Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) in the Splunk documentation. | ||||
| CVE-2026-76296 | 1 Splunk | 1 Splunk Enterprise | 2026-10-26 | 4.3 Medium |
| In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could create, move, edit, or delete sourcetype renaming configurations that they own in apps that they do not have permission to access. The vulnerability is possible when Splunk Web is turned on because Splunk Web does not verify the required app permissions before it performs sourcetype renaming operations. For more information see Rename source types at search time (https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.6/configure-source-types/rename-source-types-at-search-time) in the Splunk documentation. | ||||