Export limit exceeded: 109281 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (109281 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-68222 1 Linux 1 Linux Kernel 2026-08-19 7.8 High
In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure").
CVE-2026-68210 1 Linux 1 Linux Kernel 2026-08-19 7.8 High
In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]
CVE-2026-68209 1 Linux 1 Linux Kernel 2026-08-19 7.8 High
In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure").
CVE-2026-13463 1 Ibm 2 Aix, Cloud Pak System 2026-08-19 7.5 High
IBM Cloud Pak System 2.3.5.0 could allow a local attacker to obtain sensitive information due to the insertion of credentials into log files.
CVE-2026-68204 1 Linux 1 Linux Kernel 2026-08-19 7.8 High
In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.
CVE-2026-68196 1 Linux 1 Linux Kernel 2026-08-19 8.3 High
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as ies_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a "conn_info->status == WLAN_STATUS_SUCCESS" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.
CVE-2021-27085 1 Microsoft 7 Internet Explorer, Windows 10 1803, Windows 10 1809 and 4 more 2026-08-19 8.8 High
Internet Explorer Remote Code Execution Vulnerability
CVE-2021-27084 1 Microsoft 2 Maven For Java, Visual Studio Code 2026-08-19 7.8 High
Visual Studio Code Java Extension Pack Remote Code Execution Vulnerability
CVE-2021-27076 1 Microsoft 6 Business Productivity Servers, Sharepoint Foundation, Sharepoint Foundation 2013 and 3 more 2026-08-19 8.8 High
Microsoft SharePoint Server Remote Code Execution Vulnerability
CVE-2021-27063 1 Microsoft 10 Windows Server 1909, Windows Server 2004, Windows Server 2008 and 7 more 2026-08-19 7.5 High
Windows DNS Server Denial of Service Vulnerability
CVE-2021-27062 1 Microsoft 2 Hevc Video Extensions, High Efficiency Video Coding 2026-08-19 7.8 High
HEVC Video Extensions Remote Code Execution Vulnerability
CVE-2021-27061 1 Microsoft 2 Hevc Video Extensions, High Efficiency Video Coding 2026-08-19 7.8 High
HEVC Video Extensions Remote Code Execution Vulnerability
CVE-2021-27058 1 Microsoft 1 365 Apps 2026-08-19 7.8 High
Microsoft Office ClickToRun Remote Code Execution Vulnerability
CVE-2021-27057 1 Microsoft 11 365 Apps, Excel, Excel 2013 and 8 more 2026-08-19 7.8 High
Microsoft Office Remote Code Execution Vulnerability
CVE-2021-27056 1 Microsoft 6 365 Apps, Office, Office 2019 and 3 more 2026-08-19 7.8 High
Microsoft PowerPoint Remote Code Execution Vulnerability
CVE-2021-27055 1 Microsoft 6 365 Apps, Office, Office 2019 and 3 more 2026-08-19 7 High
Microsoft Visio Security Feature Bypass Vulnerability
CVE-2021-27054 1 Microsoft 11 365 Apps, Excel, Excel 2013 and 8 more 2026-08-19 7.8 High
Microsoft Excel Remote Code Execution Vulnerability
CVE-2021-27053 1 Microsoft 9 365 Apps, Excel, Excel 2013 and 6 more 2026-08-19 7.8 High
Microsoft Excel Remote Code Execution Vulnerability
CVE-2021-27051 1 Microsoft 2 Hevc Video Extensions, High Efficiency Video Coding 2026-08-19 7.8 High
HEVC Video Extensions Remote Code Execution Vulnerability
CVE-2021-27050 1 Microsoft 2 Hevc Video Extensions, High Efficiency Video Coding 2026-08-19 7.8 High
HEVC Video Extensions Remote Code Execution Vulnerability