Export limit exceeded: 383110 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (383110 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80581 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout Ignore IPC errors for pipeline state change if the firmware state is crashed or the IPC has timed out. If the firmware has crashed the kernel still needs to go through the state changes to reset its internal to be able to correctly work the next time the DSP is booted up. The case with IPC timeout is a bit more problematic, but it has been rootcaused to be the result of system scheduling blockage and the firmware did actually received and handled the message, but the reply handling got blocked by issues outside of the SOF stack. So far the best way to handle this is to continue with setting the state. | ||||
| CVE-2026-80580 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: bound mode sysfs output to the sysfs buffer mode_string() uses snprintf() which can return a value larger than the remaining buffer space. show_modes() accumulates the return value into i without checking whether i has reached PAGE_SIZE, causing the offset to advance past the sysfs buffer if the modelist is long enough. Add a size parameter to mode_string() and use scnprintf() to return only the bytes actually written. Add an early return when offset already exceeds the buffer. In show_modes(), stop accumulating once the buffer is full. | ||||
| CVE-2026-80579 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: clear fb_info->mode before deleting a videomode fb_set_var() can delete a mode from info->modelist when userspace passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code checks that the mode being deleted is not the current info->var and that fbcon is not using it, but it does not check fb_info->mode. fb_info->mode may still point into the modelist entry being deleted. If the entry is freed, later mode sysfs reads through show_mode() can dereference a stale pointer. Clear fb_info->mode before calling fb_delete_videomode() when it matches the mode being removed. | ||||
| CVE-2026-80578 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: core: Fix pointer desynchronization in fb_io_read() In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to a faulty user buffer), the loop adjusts the chunk size 'c' and updates the remaining 'count'. However, the hardware 'src' pointer has already been eagerly advanced by the original chunk size. If the loop is allowed to continue, the read will resume from an incorrect, over-advanced offset. Since the remaining 'count' was only decremented by the successful bytes, this desynchronization causes the next iterations to execute more hardware reads than originally bounded, eventually leading to out-of-bounds I/O reads. Fix this by breaking out of the loop immediately upon a partial copy_to_user(). A partial copy indicates a faulty user buffer, making subsequent read attempts futile. Breaking out ensures we return the number of successfully read bytes without risking out-of-bounds hardware accesses in subsequent mismatched iterations. | ||||
| CVE-2026-80577 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/panthor: skip zero-sized firmware sections panthor_fw_load_section_entry() skips BO creation when the firmware section VA range is empty. If such a section is added to the firmware section list, section->mem is left as NULL. Later reload and unplug paths iterate over all firmware sections and dereference section->mem, which can lead to a NULL pointer dereference. Zero-sized firmware sections are valid, so accept them as no-op entries but skip adding them to the section list. | ||||
| CVE-2026-80576 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: reject oversized IBs with per-ring packet limits On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission. Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types. (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52) | ||||
| CVE-2026-80575 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: cs40l50-vibra - validate custom data from user space cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect straight from the ff_effect the user passed to EVIOCSFF, without requiring it to hold anything: work_data.custom_data = memdup_array_user(periodic->custom_data, periodic->custom_len, sizeof(s16)); work_data.custom_len = periodic->custom_len; The driver then reads two words out of that buffer: custom_data[0] as the waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the index within the bank in cs40l50_effect_index_set(). Neither read is covered by a length check, and custom_len is fully user controlled: - custom_len == 0 makes memdup_array_user() call memdup_user() with a length of zero, which returns ZERO_SIZE_PTR rather than an error, so custom_data[0] dereferences it. - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps effect->type out of the OWT case, and custom_data[1] is then read one word past the allocation. The bank value itself is also mishandled. It is masked with CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a custom_data[0] of 0x8000 or above wraps to a negative value that passes the "bank_type >= CS40L50_WVFRM_BANK_NUM" test. cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the switch statement's default case gets a chance to reject it: base_index = vib->dsp.banks[effect->type].base_index; max_index = vib->dsp.banks[effect->type].max_index; Require the two words the driver reads to be present, and hold the masked bank in a u32 so the existing upper-bound test covers the whole range. The da7280 haptic driver already range checks custom_len this way. | ||||
| CVE-2026-80574 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet Make finger2 (and also finger1) unsigned, so that if the finger index in the packet is 0 then subtracting 1 creates an array index which overflows above the existing check for FOC_MAX_FINGERS, as the existing comment says it should, instead of writing to state->fingers[-1]. | ||||
| CVE-2026-80573 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: iforce - validate input packet lengths iforce_process_packet() reads fixed fields from joystick, wheel and status packets without first checking their lengths. In particular, the shared hats-and-buttons helper unconditionally reads data[6]. The status tail is a sequence of 16-bit effect addresses, but an incomplete final address is also consumed. A successful zero-length USB URB additionally reads the packet ID before the common parser is called. Reject the zero-length USB transfer, require the seven-byte joystick and wheel prefixes and the two-byte status prefix, and consume only complete status-tail addresses. | ||||
| CVE-2026-80572 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: byd - synchronize timer deletion before freeing private data byd_disconnect() uses timer_delete() before freeing the driver's private data. This does not wait for a running byd_clear_touch() callback, which dereferences the private data and its psmouse pointer. A callback racing with disconnect can therefore access the private data after it has been freed. The timer can also still be re-armed by byd_process_byte() while the disconnect is in progress. Use timer_shutdown_sync() before freeing the private data: it waits for a running callback and turns any later re-arm attempt into a no-op. | ||||
| CVE-2026-80571 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak In papr_phy_attest_create_handle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd). Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd. | ||||
| CVE-2026-80570 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - zero report size on F54 work error In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow. Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first. | ||||
| CVE-2026-80569 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check. | ||||
| CVE-2026-80568 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - block s_input when F54 queue is busy Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers. Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming). | ||||
| CVE-2026-80567 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue Previously, rmi_f54_buffer_queue() waited for the worker thread to finish but ignored whether it succeeded. If the worker failed (e.g., due to a timeout or register read failure), the queue thread would silently return success, delivering stale or uninitialized memory to userspace. Add a 'report_error' field to struct f54_data to store the worker's exit status. Check this field in rmi_f54_buffer_queue() after the worker finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error occurred. | ||||
| CVE-2026-80566 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: Input: hynitron_cstxxx - validate touch count and finger IDs The driver allocates max_touch_num input slots, which are indexed from zero through max_touch_num - 1. The current check allows a finger ID equal to max_touch_num to reach cst3xx_report_contact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot. The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data. Reject finger IDs equal to or greater than max_touch_num, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state. The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device. | ||||
| CVE-2026-80565 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: qce - fix error path in devm_qce_register_algs If ops->register_algs() fails, the error path repeatedly calls the same ops->unregister_algs() from the failed registration. Use the loop index to unregister the previously registered algorithms instead. | ||||
| CVE-2026-80564 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: gve: fix NULL dereference due to missing ptp adjfine Fix NULL dereference due to missing implementation of adjfine, which can be triggered from usermode as follows: sudo ./testptp -d /dev/ptp0 -f 0 [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 552.061946] Call Trace: [ 552.064487] <TASK> [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0 [ 552.070874] ? get_clock_desc+0x6b/0xb0 [ 552.074825] pc_clock_adjtime+0x78/0xc0 [ 552.078755] __do_sys_clock_adjtime+0x85/0x110 [ 552.083293] do_syscall_64+0xea/0x610 | ||||
| CVE-2026-80563 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind The "trigger" debugfs file has a hand-rolled ->write handler (trigger_write()) that dereferences the per-device gpio_la_poll_priv. The file is created with debugfs_create_file_unsafe(), and the handler never takes a debugfs reference. Nothing keeps the object alive while the handler runs. priv is allocated with devm_kzalloc(). devres frees it when the platform device is unbound. debugfs_create_file_unsafe() installs no full_proxy wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not wait for an in-flight trigger_write(). The blob_lock taken there does not help, because trigger_write() never takes it. A write that races an unbind therefore writes into freed memory: trigger_write() gpio_la_poll_remove() priv = m->private buf = memdup_user() [may sleep] mutex_lock(&priv->blob_lock) debugfs_remove_recursive() [no wait] mutex_unlock(&priv->blob_lock) (remove returns; devres frees priv) priv->trig_data = buf <-- use-after-free write priv->trig_len = count The race is reachable by root via /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind. Create "trigger" with debugfs_create_file() instead. Its full_proxy wrapper makes debugfs_remove_recursive() drain any in-flight ->write before it returns. The use-after-free is confirmed under KASAN with a minimal reproducer of the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern (available on request); it produces a slab-use-after-free write in the handler. | ||||
| CVE-2026-80562 | 1 Linux | 1 Linux Kernel | 2026-08-26 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: gpio: ml-ioh: use raw_spinlock_t for the register lock ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irq_set_type callback additionally emits a dev_warn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same fix as commit a02b8950d619 ("gpio: pch: use raw_spinlock_t for the register lock"); this driver shares the same structure as gpio-pch. | ||||