Export limit exceeded: 399238 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (399238 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-97527 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Serialize NVMe unsol ctx list with a per-fcport lock The fcport->unsol_ctx_head list is modified from several contexts without a common lock. Entries are added in qla2xxx_process_purls_iocb() from the response queue ISR (under the qpair qp_lock), while they are removed from qla2xxx_process_purls_pkt() (DPC/purex worker), qla_nvme_xmt_ls_rsp() (NVMe-FC transport callback) and qla_nvme_release_lsrsp_cmd_kref() (SRB completion). The qpair qp_lock cannot serialize this per-fcport list since multiqueue adapters add entries through different qpairs, so a concurrent add and delete (or two concurrent deletes) can corrupt the list pointers. Introduce a dedicated per-fcport spinlock, unsol_ctx_lock, initialized in qla2x00_alloc_fcport(), and take it around every list_add_tail()/list_del() on unsol_ctx_head. The add nests under the existing qp_lock; no delete path takes qp_lock, so the lock order is consistent and deadlock free. | ||||
| CVE-2026-97575 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate AV1 tile counts The stateless AV1 decoders use tile_info.tile_cols and tile_rows as loop bounds and as indices into the mi_*_starts[] and *_in_sbs_minus_1[] arrays, as the divisor for context_update_tile_id, and their product bounds the per-tile descriptor buffers, but std_validate_compound() does not bound these u8 fields. Reject a V4L2_CTRL_TYPE_AV1_FRAME whose tile_cols or tile_rows exceeds V4L2_AV1_MAX_TILE_COLS / _ROWS, or whose product exceeds V4L2_AV1_MAX_TILE_COUNT. A zero tile count is left to the consuming driver so the zero-initialised control that existing userspace submits is still accepted. | ||||
| CVE-2026-98000 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: Fix potential UAF in pec_store Sashiko reports: In pec_store(), a guard(mutex)(&hwdev->lock) is taken. If the chip write operation returns an error other than -EOPNOTSUPP, the code jumps to the put label, which calls put_device(hdev). If this drops the final reference, the device is freed. When the function then returns, the guard cleanup function runs and attempts to unlock the freed mutex. Use scoped_guard() instead of guard() to avoid the problem. | ||||
| CVE-2026-98003 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Do not reallocate GA log buffers on resume Commit c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") moved the GA log allocation from iommu_init_pci() to enable_iommus_vapic(), which is called on every resume. iommu_init_ga_log() assigns iommu->ga_log and iommu->ga_log_tail unconditionally. Each resume therefore replaces the boot-time pointers and leaks both old allocations. The function also uses GFP_KERNEL from a syscore resume callback, where interrupts are disabled and the non-boot CPUs are offline. Return early if both buffers are already allocated. Clear the pointers in free_ga_log() so a partial allocation failure cannot leave ga_log dangling. | ||||
| CVE-2026-98012 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum in change path sfq_change() accepts any non-negative quantum (only rejects (int)ctl->quantum < 0). With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Reject quantum > 1<<20 with -EINVAL, matching fq_codel_change() and the init clamp. Conditions to recreate the bug: CONFIG_NET_SCH_SFQ=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root sfq tc qdisc change dev dummy0 root sfq quantum 1 stab data 32768 size_log 15 cell_log 0 | ||||
| CVE-2026-98013 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp quantum in change path fq_pie_change() accepts any quantum value from userspace, including 1. With a crafted size table qdisc_pkt_len reaches ~2 GiB, so quantum=1 makes the deficit-refill loop spin ~2^31 times under the qdisc lock (a soft lockup / denial of service). Add max(256U, ...) matching fq_codel_change(). Conditions to recreate the bug: CONFIG_NET_SCH_FQ_PIE=y. Requires CAP_NET_ADMIN (namespace-local via unshare -Urn suffices). tc qdisc add dev dummy0 root fq_pie tc qdisc change dev dummy0 root fq_pie quantum 1 stab data 32768 size_log 15 cell_log 0 | ||||
| CVE-2026-98015 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch: fix use-after-free in mlx5_eswitch_termtbl_put In mlx5_eswitch_termtbl_put(), the zero-ref cleanup check reads tt->ref_count after termtbl_mutex has been released. Two concurrent callers on the same mlx5_termtbl_handle race: one decrements ref_count to zero, removes the hash entry, and calls kfree(tt) while the other has already dropped the mutex and is about to evaluate if (!tt->ref_count), producing a use-after-free. Fix this by capturing the result of the decrement into a stack-local last variable before dropping the mutex. The cleanup decision is now made entirely under termtbl_mutex, and tt is not touched after kfree. | ||||
| CVE-2026-96272 | 1 Clip-bucket | 1 Clipbucket | 2026-09-26 | 7.5 High |
| ClipBucket v5 before 5.5.3-#182 contains a blind SQL injection vulnerability in the photo search endpoint where the query parameter is passed unsanitized into SQL WHERE and ORDER BY clauses. Unauthenticated attackers can exploit time-based blind SQL injection techniques to extract user credentials, email addresses, and administrator password hashes for account takeover. | ||||
| CVE-2026-96258 | 1 Onsite Internet Gmbh | 1 Auktion Ng Auktionssoftware | 2026-09-26 | 4.3 Medium |
| A vulnerability has been found in onSite internet GmbH Auktion NG Auktionssoftware up to 20260722. This affects an unknown part of the file /forgotpasswd.html of the component Public Password Reset Endpoint. The manipulation of the argument email leads to cross site scripting. The attack is possible to be carried out remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-95929 | 1 Iflytek | 1 Astron-agent | 2026-09-26 | 6.3 Medium |
| A weakness has been identified in iFlytek astron-agent up to 1.0.7. Affected is an unknown function of the file console/backend/commons/src/main/resources/mapper/ChatBotMarketMapper.xml of the component getBotList API endpoint. Executing a manipulation of the argument sortDirection can lead to sql injection. It is possible to launch the attack remotely. Upgrading to version reward-1575 is able to address this issue. This patch is called 6702be70ae802b1048f5fbec91e690e7b71a4165. You should upgrade the affected component. | ||||
| CVE-2026-95924 | 1 Sourcecodester | 1 Online Reviewer Management System | 2026-09-26 | 7.3 High |
| A vulnerability has been found in SourceCodester Online Reviewer Management System 1.0. Impacted is an unknown function of the file /reviewer_0/admins/assessments/databank/btn_functions.php?action=add. The manipulation of the argument difficulty_id leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2026-95829 | 1 Tduckcloud | 1 Tduck-platform | 2026-09-26 | 6.3 Medium |
| A vulnerability was identified in TDuckCloud tduck-platform up to 5.3. This vulnerability affects the function PaginationInnerInterceptor.concatOrderBy of the file tduck-api/src/main/java/com/tduck/cloud/api/config/MybatisPlusConfig.java of the component Pagination Inner Interceptor. The manipulation of the argument orders[0].column leads to sql injection. The attack can be initiated remotely. The exploit is publicly available and might be used. The identifier of the patch is ea7f0fae7cb0fd998a3284c11addce689350cd69. It is suggested to install a patch to address this issue. | ||||
| CVE-2026-95813 | 1 E621ng | 1 E621ng | 2026-09-26 | 6.1 Medium |
| e621ng versions before 26.09.16 pass untrusted request parameters directly to Rails url_for in PaginatorComponent and controller navigation links, allowing attackers to redirect pagination and navigation controls to attacker-controlled origins. Attackers can supply host, protocol, and port query parameters that are interpreted as URL generation options, causing pagination links to point to malicious domains while the initial page loads from the legitimate site. | ||||
| CVE-2026-83805 | 1 Nautobot | 1 Nautobot | 2026-09-26 | 6.4 Medium |
| Nautobot is a Network Source of Truth and Network Automation Platform. From 3.0.0 until 3.1.8, the generic ApprovalWorkflowStageResponse create endpoint does not enforce approver-group membership, change permission on the object under review, or the one-response-per-user restriction applied by the intended approve and deny actions. A user with only extras.add_approvalworkflowstageresponse can submit approved responses directly, while writable user and state fields permit responses to be attributed to arbitrary users. These forged responses can satisfy min_approvers, approve the workflow, and activate its gated ScheduledJob without a legitimate approver. This issue is fixed in version 3.1.8. | ||||
| CVE-2026-62985 | 1 Azu | 1 Request-filtering-agent | 2026-09-26 | 7.5 High |
| request-filtering-agent is an http(s).Agent implementation that blocks requests to Private/Reserved IP addresses. Prior to 3.2.1, RequestFilteringHttpAgent and RequestFilteringHttpsAgent synchronously threw from createConnection when rejecting a literal private-IP host such as 169.254.169.254 or 127.0.0.1. Because Node.js http.request and http.get expect connection failures to be delivered asynchronously, the throw bypassed req.on('error') and became an uncaught exception that could terminate the application process. Hostnames resolved through the asynchronous lookup path were not affected by this error-delivery asymmetry. This issue is fixed in version 3.2.1. | ||||
| CVE-2026-62364 | 1 Weblateorg | 1 Wlc | 2026-09-26 | 2.3 Low |
| wlc is a Weblate command-line client using Weblate's REST API. Prior to 2.0.1, automatically discovered configuration from .weblate, .weblate.ini, or weblate.ini can select the API URL while an unscoped API token is supplied through WLC_KEY or --key without a matching WLC_URL or --url. When wlc runs in an untrusted repository, pull request checkout, or directory with untrusted ancestor configuration, it can send the token to an attacker-controlled project-configured URL. URL-scoped keys in [keys] are not affected. This issue is fixed in version 2.0.1. | ||||
| CVE-2026-57576 | 1 Plone | 2 Plone.app.contenttypes, Plone.app.dexterity | 2026-09-26 | 6.5 Medium |
| plone.app.dexterity is a content-type system for the Plone content management system, and plone.app.contenttypes provides Plone’s Dexterity-based content types. Plone.app.dexterity versions through 3.2.2, 4.0.0 through 4.1.2, and 5.0.0, and plone.app.contenttypes versions through 3.0.11, 4.0.0 through 4.0.9, and 5.0.0 are vulnerable to denial of service because an authenticated user can create content with excessively long titles, descriptions, or uploaded-file names, causing Plone to become unresponsive and potentially making the resulting content difficult to edit or delete. The vulnerability is patched in plone.app.dexterity versions 3.2.3, 4.1.3, and 5.0.1, and in plone.app.contenttypes versions 3.0.12, 4.0.10, and 5.0.1. | ||||
| CVE-2026-73064 | 1 Trustedfirmware | 1 Mbed Tls | 2026-09-26 | 2.9 Low |
| In Mbed TLS 3.2.0 though 3.6.6 and 4.0.0 through 4.1.0, an attacker who can cause an entropy source to fail can remove or inject bytes into the start of the TLS stream. This only affects TLS 1.3 servers. | ||||
| CVE-2026-93208 | 1 Linux | 1 Linux Kernel | 2026-09-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: kasan: fix cache shrink race with CPU hotplug kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on all online CPUs. Each callback moves objects belonging to the cache from cpu_quarantine to the CPU's shrink_qlist, where they can later be freed from task context. kmem_cache_destroy() invokes the quarantine removal path while holding cpus_read_lock(), but kmem_cache_shrink() does not. The latter can therefore race with CPU offlining as follows: kmem_cache_shrink() CPU hotplug ------------------- ----------- on_each_cpu() CPU1 moves objects to CPU1's shrink_qlist on_each_cpu() returns CPU1 goes offline kasan_cpu_offline() drains cpu_quarantine leaves shrink_qlist untouched for_each_online_cpu() skips CPU1 The objects left on CPU1's shrink_qlist are not returned to the slab allocator. This may prevent kmem_cache_shrink() from releasing slabs that would otherwise become empty. If CPU1 remains offline, a later kmem_cache_destroy() also skips the list and can report that the cache still contains objects. An intermittent occurrence was observed with a virtio-9p filesystem. The mount and umount commands both returned 0, but the kernel logged the following during the userspace-triggered teardown: [ 2994.380134][ T111] BUG 9p-fcall-cache-1 (Tainted: G B ): Objects remaining on __kmem_cache_shutdown() [ 2994.381140][ T111] Object 0xff11000004361118 @offset=4376 [ 2994.381607][ T111] Allocated in p9_fcall_init+0x201/0x400 age=19564 cpu=1 pid=104 [ 2994.382591][ T111] p9_fcall_init+0x201/0x400 [ 2994.382810][ T111] p9_tag_alloc+0x12f/0x700 [ 2994.382982][ T111] p9_client_prepare_req+0x102/0x3e0 [ 2994.383165][ T111] p9_client_rpc+0x1ab/0xa50 [ 2994.383334][ T111] p9_client_getattr_dotl+0xb0/0x1a0 [ 2994.383515][ T111] v9fs_vfs_getattr_dotl+0x115/0x360 [ 2994.383719][ T111] vfs_getattr_nosec+0x22c/0x3a0 [ 2994.383910][ T111] vfs_statx+0xd7/0x170 [ 2994.384062][ T111] vfs_fstatat+0x45/0x80 [ 2994.384215][ T111] __do_sys_newfstatat+0x84/0xe0 [ 2994.384386][ T111] do_syscall_64+0x115/0x6a0 [ 2994.384566][ T111] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2994.399720][ T111] WARNING: mm/slub.c:1244 at __kmem_cache_shutdown+0x363/0x500, CPU#0: busybox/111 [ 2994.405655][ T111] Call Trace: [ 2994.406325][ T111] kmem_cache_destroy+0x73/0x1b0 [ 2994.406630][ T111] p9_client_destroy+0x271/0x3c0 [ 2994.407210][ T111] v9fs_session_close+0x3c/0x260 [ 2994.407409][ T111] v9fs_kill_super+0x48/0x90 [ 2994.407584][ T111] deactivate_locked_super+0xa3/0x160 [ 2994.407778][ T111] cleanup_mnt+0x1dd/0x3e0 Thus, a successful umount left objects in the 9p fcall cache and prevented the cache from being destroyed cleanly. Per-CPU shrink_qlist storage exists for every possible CPU, and each list is protected by its own raw spinlock. Iterate over possible CPUs so that a list populated before its CPU went offline is drained as well. for_each_possible_cpu() can do more work than for_each_online_cpu(), but this change only affects CONFIG_KASAN_GENERIC kernels. The extra work is limited to cache shrink and cache destruction paths and does not affect the normal allocation/free fast path. It adds one raw-spinlock-protected scan of each possible CPU's shrink list. These lists are normally empty; a non-empty list is traversed to remove objects belonging to the cache being shrunk or destroyed. | ||||
| CVE-2026-93209 | 1 Linux | 1 Linux Kernel | 2026-09-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb BT enable fails intermittently with -ETIMEDOUT (-110). The kernel log shows the HCI Read Local Version command was sent and the firmware replied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG), but the waiter in __hci_cmd_sync_sk() never woke up and timed out after 10 s: bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add bluetooth hci0: skb len 4 // hci_cmd_sync_alloc bluetooth hci0: length 1 // hci_req_sync_run Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work Bluetooth: hci0 type 1 len 4 // hci_send_frame Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb not set, hci_cmd_sync_complete() never called, req_status stays HCI_REQ_PEND --> <-- 10 s later: wait_event_interruptible_timeout expires --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk The root cause is that hci_send_cmd_sync() clones the sent command into hdev->req_skb so that hci_req_cmd_complete() can locate the registered completion callback. Under memory pressure this skb_clone() fails, leaving hdev->req_skb NULL. The firmware reply is received and processed, but hci_req_cmd_complete() finds NULL req_skb, so hci_cmd_sync_complete() is never called, req_status stays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT. req_skb is only used to read bt_cb(skb)->hci callbacks and opcode -- it is never modified. Replace skb_clone() with skb_get(), which simply increments the reference count of hdev->sent_cmd without allocating new memory and therefore cannot fail. This issue was first observed as a use-after-free in ttyport_close() when ttyport_open() failed, which was investigated in an earlier patch series [1]. That investigation led to the discovery of the true root cause described above. [1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/ | ||||