Affected: AlmaLinux:8: kernel-rt, AlmaLinux:8: kernel-rt-core, AlmaLinux:8: kernel-rt-debug, AlmaLinux:8: kernel-rt-debug-core, AlmaLinux:8: kernel-rt-debug-devel, AlmaLinux:8: kernel-rt-debug-modules, AlmaLinux:8: kernel-rt-debug-modules-extra, AlmaLinux:8: kernel-rt-devel, AlmaLinux:8: kernel-rt-modules, AlmaLinux:8: kernel-rt-modules-extra

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

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.

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

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…

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…

Affected: openEuler:24.03-LTS-SP1: kernel

The Linux Kernel, the operating system core itself. Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Fix timeline left held on VMA alloc error

The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform:

<4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]---

If the test also unloads the i915 module then that's followed with:

<3> [357.787478] ===…

Security update for the Linux Kernel

kernel: fbcon: Set fb_display[i]->mode to NULL when the mode is released kernel: ext4: fix e4b bitmap inconsistency reports kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg kernel: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB kernel: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg kernel: arm64: tlb: Flush walk cache when unsharing PMD tables kernel: net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer kernel: perf/core: Detach event groups during remove_on_exec kernel: Linux kernel (libceph): Denial of Service due to malformed monitor maps kernel: libceph: refresh auth->authorizer_buf{,_len} after authorizer update kernel: Linux kernel: libceph stack out-of-bounds write via crafted OSDMap kernel: drm/amdgpu: Fix context pstate override handling kernel: perf: Reject exited events as group leaders

Affected: Rocky Linux:8: kernel-rt

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

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.

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more

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 DOU…

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.