NULL Pointer Dereference Affecting kernel-rt-debug-kvm package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
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 applications- Snyk IDSNYK-RHEL10-KERNELRTDEBUGKVM-21263953
- published20 Oct 2026
- disclosed18 Oct 2026
Introduced: 18 Oct 2026
NewCVE-2026-98537 (opens in a new tab)How to fix?
There is no fixed version for RHEL:10 kernel-rt-debug-kvm.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt-debug-kvm package and not the kernel-rt-debug-kvm package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
workqueue: Fix NULL current_pwq deref in flush dependency check
check_flush_dependency() uses current_wq_worker() to determine whether the caller is a workqueue worker and then dereferences worker->current_pwq to test whether the current workqueue is WQ_MEM_RECLAIM.
current_wq_worker() only means that %current has PF_WQ_WORKER set. A kworker can reach check_flush_dependency() while it is not executing a work item. One such path is worker_thread() acting as the pool manager, where create_worker() does GFP_KERNEL allocation and the allocation path invokes the OOM notifier. In that state worker->current_pwq is NULL because current_pwq is set only by process_one_work() and cleared again after the work function returns.
[ 416.760634][ T375] Call trace: [ 416.760638][ T375] check_flush_dependency+0x80/0x120 (P) [ 416.760648][ T375] __flush_work+0x98/0x224 [ 416.760657][ T375] flush_work+0x30/0x44 [ 416.760665][ T375] ... [ 416.760710][ T375] blocking_notifier_call_chain+0x58/0xa0 [ 416.760719][ T375] out_of_memory+0xb4/0x458 [ 416.760730][ T375] __alloc_pages_may_oom+0x11c/0x1a8 [ 416.760739][ T375] __alloc_pages_slowpath+0x314/0x46c [ 416.760746][ T375] __alloc_frozen_pages_noprof+0x110/0x1a4 [ 416.760753][ T375] new_slab+0x12c/0x484 [ 416.760759][ T375] ___slab_alloc+0x7a8/0xc7c [ 416.760765][ T375] __slab_alloc+0x74/0xd8 [ 416.760772][ T375] __kmalloc_cache_node_noprof+0x2ac/0x304 [ 416.760779][ T375] alloc_worker+0x28/0x60 [ 416.760785][ T375] create_worker+0x4c/0x20c [ 416.760790][ T375] worker_thread+0xe8/0x2b8 [ 416.760796][ T375] kthread+0x1a8/0x200 [ 416.760805][ T375] ret_from_fork+0x10/0x20
Guard the WQ_MEM_RECLAIM-worker warning with worker->current_pwq. If the kworker is not currently executing a work item, there is no current workqueue to diagnose with that warning. The PF_MEMALLOC warning is left unchanged so explicit reclaim context flushing a !WQ_MEM_RECLAIM target is still reported.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2555014
- https://access.redhat.com/security/cve/CVE-2026-98537
- https://git.kernel.org/stable/c/0c6b9b1e295aeff1132ac7aa738148cc65f06485
- https://git.kernel.org/stable/c/1dccf5dc2f8fe688270b261ca4216e03c6a1e674
- https://git.kernel.org/stable/c/513121e69388604619ea8c0ee07e86a3d1b5b5dc
- https://git.kernel.org/stable/c/8ffececcb88262389b4f91fed0fe4884b68204bc
- https://git.kernel.org/stable/c/9bb739a5c5a570c28a62afb98e9326e2a49743c1
- https://git.kernel.org/stable/c/cc190a6a1d20b87e6a9435202fc2a3bd84c79fb3
- https://git.kernel.org/stable/c/db6365ced4d5855e321f772b240c0e473bcfcdd5
- https://git.kernel.org/stable/c/f97e6d0572d1b39998e053732332bc3cfdd0b9aa