Threats Tagged 'cve-2026-64102'

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: RDMA/siw: Reject MPA FPDU length underflow before signed receive math (CVE-2026-64102) * kernel: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets (CVE-2026-68299) * kernel: net/liquidio: drop cached VF pci_dev LUT (CVE-2026-72329) * kernel: dm-integrity: don't increment hash_offset twice (CVE-2026-72099) Bug Fix(es) and Enhancement(s): * [RHEL 8.10] "kernel BUG at lib/list_debug.c:28!": list_add corruption in register_trace_event RHEL 8.10 (JIRA:RHEL-214136) * request_key_auth use-after-free on every request-key upcall since 4.18.0-553.165.1 (regression from CVE-2026-63823 backport) (JIRA:RHEL-270349) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

A vulnerability in the Linux kernel's soft-iWARP implementation allows a malicious connected siw peer to send a malformed iWARP FPDU with an underflow in the MPA length field. This causes a signed integer underflow leading to a large unsigned read in kernel memory copy operations. The issue is addressed by adding a check to reject malformed FPDUs that violate protocol length constraints, terminating the connection on error.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 (CVE-2026-46076) * kernel: ext4: fix e4b bitmap inconsistency reports (CVE-2026-45942) * kernel: KVM: arm64: Reassign nested_mmus array behind mmu_lock (CVE-2026-46317) * kernel: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() (CVE-2026-53341) * kernel: perf/core: Detach event groups during remove_on_exec (CVE-2026-64556) * kernel: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets (CVE-2026-68299) * kernel: crypto: tegra - fix rctx->cryptlen calculation in tegra_gcm_do_one_req() (CVE-2026-80522) * kernel: perf: Reject exited events as group leaders (CVE-2026-74753) * kernel: nvme-tcp: reject a read that transferred too few bytes (CVE-2026-89480) * kernel: KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation (CVE-2026-89775) Bug Fix(es) and Enhancement(s): * KVM: s390: Limit adapter indicator access to mapped page [rhel-10.2.z] (JIRA:RHEL-188661) * crypto: xxhash64 should not be fips approved [rhel-10.2.z] (JIRA:RHEL-254943) * kata-tdx TD vCPU stuck at reset vector (EIP=0xFFF0) on Intel Xeon 6 (Granite Rapids / Sierra Forest) ? guest never executes. (10.2.z) (JIRA:RHEL-260402) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Multiple security vulnerabilities affecting the Linux kernel have been addressed in a security update. These include fixes for use-after-free, out-of-bounds reads, integer overflows, memory corruption, denial of service, and buffer overflow issues across various kernel subsystems such as fbcon, smb, drm/amdgpu, netfilter, accel/ivpu, and others. The update is applicable to SUSE and Red Hat Enterprise Linux distributions. The vendor has released official patches to remediate these vulnerabilities.

In the Linux kernel, the following vulnerability has been resolved: ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.