fkie_cve-2022-50369
Vulnerability from fkie_nvd
Published
2025-09-17 15:15
Modified
2025-09-18 13:43
Severity ?
Summary
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
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vkms: Fix null-ptr-deref in vkms_release()\n\nA null-ptr-deref is triggered when it tries to destroy the workqueue in\nvkms-\u003eoutput.composer_workq in vkms_release().\n\n KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24\n RIP: 0010:destroy_workqueue+0x2f/0x710\n ...\n Call Trace:\n \u003cTASK\u003e\n ? vkms_config_debugfs_init+0x50/0x50 [vkms]\n __devm_drm_dev_alloc+0x15a/0x1c0 [drm]\n vkms_init+0x245/0x1000 [vkms]\n do_one_initcall+0xd0/0x4f0\n do_init_module+0x1a4/0x680\n load_module+0x6249/0x7110\n __do_sys_finit_module+0x140/0x200\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe reason is that an OOM happened which triggers the destroy of the\nworkqueue, however, the workqueue is alloced in the later process,\nthus a null-ptr-deref happened. A simple call graph is shown as below:\n\n vkms_init()\n vkms_create()\n devm_drm_dev_alloc()\n __devm_drm_dev_alloc()\n devm_drm_dev_init()\n devm_add_action_or_reset()\n devm_add_action() # an error happened\n devm_drm_dev_init_release()\n drm_dev_put()\n kref_put()\n drm_dev_release()\n vkms_release()\n destroy_workqueue() # null-ptr-deref happened\n vkms_modeset_init()\n vkms_output_init()\n vkms_crtc_init() # where the workqueue get allocated\n\nFix this by checking if composer_workq is NULL before passing it to\nthe destroy_workqueue() in vkms_release()." } ], "id": "CVE-2022-50369", "lastModified": "2025-09-18T13:43:34.310", "metrics": {}, "published": "2025-09-17T15:15:35.830", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…