Complete feed
No mitigation yet
No fix, workaround or mitigation extracted yet
Android app · Google Play
Take your CVE monitoring with you.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Medium [CVE-2026-64408] pin L2CAP connection during netdev registration
pin L2CAP connection during netdev registration. Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-825.
Medium [CVE-2026-64513] Unconditionally recompute CR8 intercept on PPR update
Unconditionally recompute CR8 intercept on PPR update. Red Hat rates this low (CVSS 5.5).
Medium [CVE-2026-64335] fix broken rx after throttle
fix broken rx after throttle. Red Hat rates this low (CVSS 5.5).
Medium [CVE-2026-64417] fix NULL pointer dereference in debugfs
fix NULL pointer dereference in debugfs. Red Hat rates this low (CVSS 5.5).
Medium [CVE-2026-64450] fix out-of-bounds read in broadcast Gap ACK blocks
fix out-of-bounds read in broadcast Gap ACK blocks. Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-125.
Medium [CVE-2026-64457] fix vq info pointer lookup via wrong index
fix vq info pointer lookup via wrong index. Red Hat rates this low (CVSS 5.5). Weakness: CWE-476.
Medium [CVE-2026-64446] fix heap buffer overflow in rtw_cfg80211_set_wpa_ie
fix heap buffer overflow in rtw_cfg80211_set_wpa_ie(). Red Hat rates this moderate. Weakness: CWE-120.
Medium [CVE-2026-64500] Initialize completion before requesting IRQ
Initialize completion before requesting IRQ. Red Hat rates this moderate.
Medium [CVE-2026-64353] Keep dynamic inner array lookups nullable
Keep dynamic inner array lookups nullable. Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-787.
Medium [CVE-2026-64339] bound bulk IN response length to the received transfer
bound bulk IN response length to the received transfer. Red Hat rates this moderate (CVSS 5.5). Weakness: CWE-125.
Low [CVE-2026-64317] bound Rock Ridge symlink components to the SL record
bound Rock Ridge symlink components to the SL record. Red Hat rates this low (CVSS 3.9). Weakness: CWE-125.
Advisory [CVE-2026-64269] Bound RDMA-Write length to chunk size in rdma_write_sg
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region.
Advisory [CVE-2026-64285] Pin source page for write when adding CPUID data for SNP guest
In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Pin source page for write when adding CPUID data for SNP guest When populating a guest_memfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the source page as KVM will write back the "correct" CPUID information if the userspace provided data is rejected by trusted firmware. Because KVM writes to the source page using a kernel mapping, pinning for read could result in KVM clobbering read-only memory. Note, well-behaved VMMs are unlikely to be affected, as CPUID information is almost always dynamically generated by userspace, i.e. it's unlikely for the CPUID information to be backed by a read-only mapping. [sean: rewrite shortlog and changelog, tag for stable@] A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) component, specifically within the Secure Nested Paging (SNP) guest functionality. When KVM populates a guest's CPUID (Central Processor Unit Identifier) data, it may attempt to write to a source memory page that is intended to be read-only. This incorrect memory pinning could lead to memory corruption, potentially allowing an attacker to overwrite sensitive data within the kernel. Red Hat severity: not rated. Weakness: CWE-787.
Advisory [CVE-2026-64314] chacha20poly1305 - validate poly1305 template argument
In the Linux kernel, the following vulnerability has been resolved: crypto: chacha20poly1305 - validate poly1305 template argument chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp(). When the argument is missing, crypto_attr_alg_name() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp(). This matches the surrounding Crypto API template pattern where crypto_attr_alg_name() results are validated before string-specific use. A flaw was found in the Linux kernel's `chacha20poly1305` cryptographic module. This vulnerability occurs because the `chachapoly_create()` function does not properly validate a `poly1305` template argument. This can result in a system crash, causing a Denial of Service (DoS) for affected systems. Red Hat severity: not rated. Weakness: CWE-476. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.
Advisory [CVE-2026-64431] avoid calling post_write_mst_fixup for invalid index_block
In the Linux kernel, the following vulnerability has been resolved: ntfs: avoid calling post_write_mst_fixup() for invalid index_block ntfs_icx_ib_sync_write() calls post_write_mst_fixup() when ntfs_ib_write() returns an error, intending to restore the buffer after a failed write. However, ntfs_ib_write() returns an error immediately if pre_write_mst_fixup() validation fails. The caller, ntfs_icx_ib_sync_write(), interprets any error as a write failure requiring rollback. It does not differentiate between I/O errors and validation failures, and calls post_write_mst_fixup() anyway. Since post_write_mst_fixup() assumes that the index_block contents is correct, it doesn't perform the boundary checks, which results in out-of-bounds memory access.
Advisory [CVE-2026-64349] fix dwc3_readl and dwc3_writel calls in dwc3_ulpi_setup
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: fix dwc3_readl() and dwc3_writel() calls in dwc3_ulpi_setup() The dwc3_ulpi_setup() calls the register read and write calls with dwc3->regs when both these calls take the dwc3 structure directly. Chnage these two calls to fix the following sparse warning, and possibly a nasty bug in the dwc3_ulpi_setup() code: drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces) drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces) drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs Incorrect type handling in the `dwc3_readl()` and `dwc3_writel()` functions within `dwc3_ulpi_setup()` can lead to memory corruption. This vulnerability may allow an attacker to cause system instability or potentially execute arbitrary code, depending on the specific memory corruption scenario. Red Hat severity: not rated. Weakness: CWE-843. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Hardened Images as not affected.
Advisory [CVE-2026-64437] fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") made smb2_cancel() skip a work whose state is KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same freeing producer path is reached for CLOSED too: SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock() worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the cancelled branch, skips release_async_work(). The work stays on conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock pointing at the freed file_lock.
Advisory [CVE-2026-64509] fix GenDisk cleanup paths
In the Linux kernel, the following vulnerability has been resolved: rust: block: fix GenDisk cleanup paths GenDiskBuilder::build() still has fallible work after __blk_mq_alloc_disk(), but its error path only recovers the foreign queue data. That leaks the temporary gendisk and request_queue until later teardown. If the caller moved the last Arc> into build(), the leaked queue can retain blk-mq state after the tag set is dropped. Fix the pre-registration failure path by dropping the temporary gendisk reference with put_disk() before recovering queue_data, so disk_release() can tear down the owned queue. Also pair GenDisk::drop() with put_disk() after del_gendisk(). Once a Rust GenDisk has been added with device_add_disk(), del_gendisk() only unregisters it; the final gendisk reference still has to be dropped to complete the release path. This vulnerability occurs in the `GenDisk` cleanup paths, where temporary disk and request queue resources may not be properly released during error handling or after unregistration. This can lead to a resource leak, potentially causing system instability or a denial of service (DoS) due to resource exhaustion. Red Hat severity: not rated. Weakness: CWE-772. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9 as not affected.
Advisory [CVE-2026-64442] fix OOB reads in IE loops in issue_assocreq and join_cmd_hdl
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Insufficient boundary checks in the information element (IE) parsing loops within the `issue_assocreq()` and `join_cmd_hdl()` functions allow a remote attacker to cause an out-of-bounds read. By sending specially crafted, truncated IE data from a malicious Wi-Fi Access Point, an attacker could trigger a system crash, leading to a denial of service. Red Hat severity: not rated. Weakness: CWE-125.
Advisory [CVE-2026-64393] run set info with opener credentials
In the Linux kernel, the following vulnerability has been resolved: ksmbd: run set info with opener credentials SMB2 SET_INFO handlers call path-based VFS helpers after checking the access mask granted to the SMB handle. Those helpers perform their owner, inode permission and LSM checks using the current ksmbd worker credentials. Run the complete SET_INFO dispatch with the credentials captured when the handle was opened. This also removes the separate security information credential setup and keeps all SET_INFO classes under one credential scope. Direct override_creds() is used because it can nest with the request credential overrides already used by rename and link helpers. This vulnerability allows a local attacker to escalate privileges by manipulating Server Message Block (SMB2) SET_INFO operations. The system incorrectly uses the ksmbd worker's credentials instead of the original user's credentials when performing file system checks, potentially bypassing security restrictions and enabling unauthorized actions. Red Hat severity: not rated. Weakness: CWE-270. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Hardened Images as not affected.