In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade Rocky-Linux:9 kernel-rt-modules-extra to version 0:5.14.0-687.47.1.el9_8 or higher.
This issue was patched in RLSA-2026:67150.
Note: Versions mentioned in the description apply only to the upstream kernel-rt-modules-extra package and not the kernel-rt-modules-extra package as distributed by Rocky-Linux.
See How to fix? for Rocky-Linux:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pt: Reset current_op in xe_pt_update_ops_init()
xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it.
After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind.
Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry.
Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init().
v2 (Matt):
(cherry picked from commit 046045543e530605c441063535e7dca0075369a6)