Threats Tagged 'cve-2026-63875'

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.

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: fbcon: Set fb_display[i]->mode to NULL when the mode is released (CVE-2025-40323) * kernel: ext4: fix e4b bitmap inconsistency reports (CVE-2026-45942) * kernel: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg (CVE-2026-46230) * kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB (CVE-2026-46204) * kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg (CVE-2026-46199) * kernel: arm64: tlb: Flush walk cache when unsharing PMD tables (CVE-2026-63875) * kernel: net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer (CVE-2026-64034) * kernel: perf/core: Detach event groups during remove_on_exec (CVE-2026-64556) * kernel: Linux kernel: libceph stack out-of-bounds write via crafted OSDMap (CVE-2026-68159) * kernel: libceph: refresh auth->authorizer_buf{,_len} after authorizer update (CVE-2026-68156) * kernel: Linux kernel (libceph): Denial of Service due to malformed monitor maps (CVE-2026-68155) * kernel: drm/amdgpu: Fix context pstate override handling (CVE-2026-68273) * kernel: perf: Reject exited events as group leaders (CVE-2026-74753) 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 in Red Hat Enterprise Linux have been addressed in an official security update. These vulnerabilities include 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, libceph, drm/amdgpu, netfilter, accel/ivpu, and others. The update is rated as important by Red Hat Product Security and includes official patches to remediate these issues.

In the Linux kernel, the following vulnerability has been resolved: arm64: tlb: Flush walk cache when unsharing PMD tables When huge_pmd_unshare() is called to unshare a PMD table, the tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true but the aarch64 tlb_flush() only checked tlb->freed_tables to determine whether to use TLBF_NONE (vae1is, invalidates walk cache) or TLBF_NOWALKCACHE (vale1is, leaf-only). This caused the stale PMD page table entry to remain in the walk cache after unshare, potentially leading to incorrect page table walks. Fix by including unshared_tables in the check, so that when unsharing tables, TLBF_NONE is used and the walk cache is properly invalidated. Here is the detailed distinction between vae1is and vale1is: | Instruction Combination | Actual Invalidation Scope | | ------------------------ | --------------------------------------------------| | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) | | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 | | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) | | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |

In the Linux kernel, the following vulnerability has been resolved: arm64: tlb: Flush walk cache when unsharing PMD tables When huge_pmd_unshare() is called to unshare a PMD table, the tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true but the aarch64 tlb_flush() only checked tlb->freed_tables to determine whether to use TLBF_NONE (vae1is, invalidates walk cache) or TLBF_NOWALKCACHE (vale1is, leaf-only). This caused the stale PMD page table entry to remain in the walk cache after unshare, potentially leading to incorrect page table walks. Fix by including unshared_tables in the check, so that when unsharing tables, TLBF_NONE is used and the walk cache is properly invalidated. Here is the detailed distinction between vae1is and vale1is: | Instruction Combination | Actual Invalidation Scope | | ------------------------ | --------------------------------------------------| | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) | | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 | | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) | | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |

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.