Export limit exceeded: 105476 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (105476 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68213 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: 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. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. 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"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here. | ||||
| 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-68199 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size. | ||||
| 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-2026-68192 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool. | ||||
| 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 | ||||