Export limit exceeded: 399443 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (399443 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-97981 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Count dropped frames as NAPI work The RX loop only consumes budget when it successfully delivers a frame. Error paths keep consuming descriptors without reducing the budget, so a stream of bad frames can process the entire receive ring in one poll. Move the budget accounting to a common end-of-frame path. This counts each completed frame as NAPI work whether it was delivered or dropped, matching the behavior of the vendor driver. | ||||
| CVE-2026-97987 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: virtio_input: reset device if input_register_device() fails Probe marks the device DRIVER_OK with virtio_device_ready() before calling input_register_device(). If registration fails, the error path cleared vi->ready and called del_vqs() while the device was still live, so the device could keep DMA to queues that were already torn down. Match remove/freeze: call virtio_reset_device() on that path before tearing down the virtqueues. | ||||
| CVE-2026-100072 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ACPI: platform: Use acpi_bus_get_primary_device() The acpi_get_first_physical_node() usage in acpi_platform_fill_resource() and acpi_create_platform_device() is generally unsafe because in theory the device returned by it may be freed at any time [1]. It is also inefficient because acpi_get_first_physical_node() is called multiple times for the same argument which can be avoided. Address these issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and adjusting the code to call it just once at the beginning of and acpi_create_platform_device() and drop the device reference acquired by it upon the return from that function. | ||||
| CVE-2026-97564 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.idmap descriptions cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in "os:"/"gs:"/"oi:"/"gi:" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf4efbc ("smb: client: reject userspace cifs.spnego descriptions"), which applied the same restriction to cifs.spnego. | ||||
| CVE-2026-100074 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf_refcount field as unique BPF_REFCOUNT is not marked as a unique field, while it should be. Fix this oversight. | ||||
| CVE-2026-100077 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm: Recover HW before retire hung submit During recovery, it is not safe to retire the hung submit before we recover the GPU. Retiring the submit triggers BO free and that can result in GPU pagefaults since the GPU may be actively accessing those BOs. To fix this, retire the submits after gpu recovery is complete in recover_worker(). Patchwork: https://patchwork.freedesktop.org/patch/730655/ | ||||
| CVE-2026-97588 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: s390/crypto: Map EBUSY to EIO when key conversion fails repeatedly When hardware persistently returns -EBUSY after exhausting retries, the error propagates to crypto_finalize_*_request(). The crypto API's completion wrapper treats -EBUSY as a queueing status and swallows it, preventing the completion callback from firing. This causes callers using crypto_wait_req() to block indefinitely. Translate persistent -EBUSY to -EIO after retry exhaustion to ensure proper error propagation and callback invocation. | ||||
| CVE-2026-75658 | 1 Adobe | 2 Adobe Bridge, Bridge | 2026-09-25 | 7.8 High |
| Bridge is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-75663 | 1 Adobe | 2 Adobe Bridge, Bridge | 2026-09-25 | 7.8 High |
| Bridge is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-75665 | 1 Adobe | 2 Adobe Bridge, Bridge | 2026-09-25 | 7.8 High |
| Bridge is affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-75676 | 1 Adobe | 2 Adobe Bridge, Bridge | 2026-09-25 | 7.8 High |
| Bridge is affected by a Stack-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-98144 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: put the chained BO when its mapping fails amdxdna_cmd_set_error() looks up the first BO of a command chain, which takes a reference, and drops it at the end of the function. The mapping of that BO is established in between, and the failure path returns without the put, so the reference is leaked. Ordinary use does not reach it. The chain has been submitted before any of this runs, so aie2_cmdlist_fill_slot() has already called amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its address. What makes it reachable is that the BO is resolved again by handle here, and the handle is userspace's to recycle: closing it after submission and importing a dma-buf whose exporter implements no vmap onto the same id leaves amdxdna_gem_get_obj() returning an object this cannot map, since prime_import() types every import AMDXDNA_BO_SHARE. | ||||
| CVE-2026-98149 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix percpu map update indexing with sparse CPU IDs Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU. | ||||
| CVE-2026-97897 | 1 Krayin | 1 Laravel-crm | 2026-09-25 | 3.5 Low |
| A security flaw has been discovered in Krayin laravel-crm up to 2.2.5. This issue affects some unknown processing of the file Sanitizer.php of the component TinyMCE Media Upload. The manipulation results in cross site scripting. The attack may be performed from remote. Upgrading to version 2.2.6 is capable of addressing this issue. The patch is identified as 734aa10ae6c2ffa4c96c8869a89aa66940e4d345. You should upgrade the affected component. | ||||
| CVE-2026-16468 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-09-25 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary commands due to OS command injection. | ||||
| CVE-2026-16469 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-09-25 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 px-runtime could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-17102 | 1 Ibm | 1 Datastage On Cloud Pak For Data | 2026-09-25 | 8.8 High |
| IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-97896 | 1 Krayin | 1 Laravel-crm | 2026-09-25 | 3.5 Low |
| A vulnerability was identified in krayin laravel-crm up to 2.2.5. This vulnerability affects the function ConfigurationForm::rules of the file packages/Webkul/Admin/src/Http/Requests/ConfigurationForm.php of the component Upload Functionality. The manipulation leads to cross site scripting. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. Upgrading to version 2.2.6 is able to resolve this issue. The identifier of the patch is b9836530ec9f5ef0f51653bb0cbbc47ef7184f51. It is advisable to upgrade the affected component. | ||||
| CVE-2026-97934 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from a "STACKTRACE" histogram key "cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field. | ||||
| CVE-2026-97936 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from the histogram stacktrace modifier parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read. | ||||