NULL Pointer Dereference Affecting python3-perf package, versions <0:4.18.0-513.5.1.el8_9
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 applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-CENTOS8-PYTHON3PERF-12898104
- published27 Sept 2025
- disclosed17 Sept 2025
Introduced: 17 Sep 2025
CVE-2022-50369 (opens in a new tab)How to fix?
Upgrade Centos:8 python3-perf to version 0:4.18.0-513.5.1.el8_9 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python3-perf package and not the python3-perf package as distributed by Centos.
See How to fix? for Centos:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix null-ptr-deref in vkms_release()
A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release().
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below:
vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated
Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release().
References
- https://access.redhat.com/security/cve/CVE-2022-50369
- https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d
- https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645
- https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5
- https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee
- https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac