Export limit exceeded: 419546 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (419546 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-99253 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: rearm local work wake up before sleep io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that. Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run. | ||||
| CVE-2026-99239 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add. Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems. Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write. | ||||
| CVE-2026-99237 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Hold trace_types_lock when resetting last boot data from readers update_last_data_if_empty() is called from tracing_open() with O_TRUNC, tracing_read_pipe() and tracing_buffers_read() without trace_types_lock. Two readers can both pass the LAST_BOOT test and free module_delta twice, and a module notifier can update module_delta while it is being freed. Take trace_types_lock in those paths and keep the callers that already hold it on an unlocked variant. | ||||
| CVE-2026-99235 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Save the event file instead of the compatible histogram create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed: file = hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it: BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger. | ||||
| CVE-2026-99233 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Verify event_call identity when updating synth_event refcount In event_hist_trigger_parse() and hist_unreg_all(), the histogram registration and unregistration paths look up find_synth_event() using trace_event_name(file->event_call) and adjust se->ref if a match is found. Because find_synth_event() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it. Introduce find_synth_event_call() to verify that &se->call matches file->event_call before adjusting se->ref. | ||||
| CVE-2026-99231 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: own the request before clearing ->head io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless. | ||||
| CVE-2014-125001 | 1 Cardosystems | 2 Scala Rider Q3, Scala Rider Q3 Firmware | 2026-11-03 | 8.1 High |
| A vulnerability classified as critical has been found in Cardo Systems Scala Rider Q3. Affected is the file /cardo/api of the Cardo-Updater. Unauthenticated remote code execution with root permissions is possible. Firewalling or disabling the service is recommended. | ||||
| CVE-2026-121501 | 1 Mathurvishal | 1 Cloudclassroom-php-project | 2026-11-03 | 6.3 Medium |
| A vulnerability was determined in mathurvishal CloudClassroom-PHP-Project. The affected element is the function session_regenerate_id of the file loginlinkadmin.php. Executing a manipulation of the argument PHPSESSID can lead to session fixiation. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-117069 | 1 Openairinterface | 1 Oai-cn5g-amf | 2026-11-03 | 7.5 High |
| An integer truncation vulnerability in the NAS decoder of OpenAirInterface (OAI) CN5G AMF v2.2.1 allows an unauthenticated remote attacker to cause a denial of service (DoS) via crafted NAS Registration Requests containing a malformed IMEISV in the 5GS Mobile Identity IE. The Type6NasIe::Validate() function truncates a 32-bit length value to 16 bits, bypassing length validation and causing an out-of-bounds heap read in DecodeImeisv(), which can crash the AMF process. | ||||
| CVE-2025-22436 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In multiple locations, there is a possible way to trick a user into disclosing Autofill contents due to a tapjacking/overlay attack. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-0053 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In multiple locations, there is a possible method for a primary user to disable secure nfc on other full users due to insufficient isolation between Android users. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-120572 | 1 Mozilla | 1 Firefox | 2026-11-03 | 8.8 High |
| Incorrect boundary conditions in the Layout: Block and Inline component. This vulnerability was fixed in Firefox 159.0.1. | ||||
| CVE-2026-121445 | 2 Darylldoyle, Drupal | 2 Svg-sanitizer, Svg Sanitizer | 2026-11-03 | 5.9 Medium |
| darylldoyle svg-sanitizer from 1.0.0 before 1.1.0 contains a regular expression denial of service vulnerability in the image-set pattern of stripRemoteCssTokens() when removeRemoteReferences is enabled. Attackers can submit SVGs with many unclosed image-set tokens to exhaust CPU, or trigger PCRE limits causing sanitize() to throw a TypeError and leave unsanitized content. | ||||
| CVE-2013-10004 | 1 Telecomsoftware | 2 Samwin Agent, Samwin Contact Center | 2026-11-03 | 6.5 Medium |
| A vulnerability classified as critical was found in Telecommunication Software SAMwin Contact Center Suite 5.1. This vulnerability affects the function passwordScramble in the library SAMwinLIBVB.dll of the component Password Handler. Incorrect implementation of a hashing function leads to predictable authentication possibilities. Upgrading to version 6.2 is able to address this issue. It is recommended to upgrade the affected component. | ||||
| CVE-2026-84490 | 1 Apple | 3 Ios And Ipados, Ipados, Iphone Os | 2026-11-03 | 2 Low |
| This issue was addressed through improved state management. This issue is fixed in iOS 27 and iPadOS 27. An attacker with physical access to a locked device may be able to bypass Digital ID authentication when iPhone Mirroring is active. | ||||
| CVE-2026-101424 | 1 Oracle | 1 Peoplesoft Enterprise Peopletools | 2026-11-03 | 5.8 Medium |
| Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: Report Distribution). Supported versions that are affected are 8.61-8.63. Difficult to exploit vulnerability allows high privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise PeopleTools. While the vulnerability is in PeopleSoft Enterprise PeopleTools, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all PeopleSoft Enterprise PeopleTools accessible data. CVSS 3.1 Base Score 5.8 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N). | ||||
| CVE-2026-115295 | 1 Elastic | 1 Kibana | 2026-11-03 | 4.3 Medium |
| Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana can lead to information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with read access to connectors in one Kibana space can retrieve connector execution log information from other spaces that they are not authorized to access. The disclosed information includes connector names and identifiers, execution status, timestamps, error messages, and aggregated execution statistics. | ||||
| CVE-2026-115297 | 1 Elastic | 1 Packetbeat | 2026-11-03 | 6.5 Medium |
| NULL Pointer Dereference (CWE-476) in the AMQP protocol parser in Packetbeat can lead to denial of service via specially crafted network traffic. An unauthenticated attacker who can send traffic on a network segment that Packetbeat monitors for AMQP can cause a Go runtime panic that terminates the Packetbeat process. A single crafted packet is sufficient. No AMQP authentication is necessary. While Packetbeat is not running, it does not collect network telemetry. | ||||
| CVE-2026-115298 | 1 Elastic | 1 Elasticsearch | 2026-11-03 | 4.3 Medium |
| Incorrect Authorization (CWE-863) in Elasticsearch can lead to information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user whose index access is restricted by field-level security can retrieve the value of a constant_keyword field that their role excludes. Some search and query features do not apply the field-level security restriction to this field type. | ||||
| CVE-2026-115710 | 1 Elastic | 1 Elasticsearch | 2026-11-03 | 4.2 Medium |
| Use of Cache Containing Sensitive Information (CWE-524) in Elasticsearch can lead to information disclosure and incorrect search results via specially crafted search requests. For some query types, Elasticsearch can share cached query results between users who have field-level security restrictions and users who do not. A user restricted by field-level security can learn which documents match a value in a field that they cannot read. A restricted user can also cause users with full access to receive incomplete search results. Disclosure is only possible when a user with full access ran the same query on the same shard recently. | ||||