CVE-2022-50563 Affecting kernel-source package, versions <5.14.21-150400.24.184.1
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-SLES154-KERNELSOURCE-14043009
- published18 Nov 2025
- disclosed15 Nov 2025
Introduced: 15 Nov 2025
NewCVE-2022-50563 (opens in a new tab)How to fix?
Upgrade SLES:15.4 kernel-source to version 5.14.21-150400.24.184.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-source package and not the kernel-source package as distributed by SLES.
See How to fix? for SLES:15.4 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
dm thin: Fix UAF in run_timer_softirq()
When dm_resume() and dm_destroy() are concurrent, it will lead to UAF, as follows:
BUG: KASAN: use-after-free in __run_timers+0x173/0x710 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 <snip> Call Trace: <IRQ> dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+0x16e/0x62c __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0
One of the concurrency UAF can be shown as below:
use free
do_resume | __find_device_hash_cell | dm_get | atomic_inc(&md->holders) | | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | atomic_read(&md->holders) | msleep(1) dm_resume | __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add delay work | dm_put | atomic_dec(&md->holders) | | dm_table_destroy | pool_dtr | __pool_dec | __pool_destroy | destroy_workqueue | kfree(pool) # free pool time out __do_softirq run_timer_softirq # pool has already been freed
This can be easily reproduced using:
- create thin-pool
- dmsetup suspend pool
- dmsetup resume pool
- dmsetup remove_all # Concurrent with 3
The root cause of this UAF bug is that dm_resume() adds timer after dm_destroy() skips cancelling the timer because of suspend status. After timeout, it will call run_timer_softirq(), however pool has already been freed. The concurrency UAF bug will happen.
Therefore, cancelling timer again in __pool_destroy().
References
- https://www.suse.com/security/cve/CVE-2022-50563.html
- https://bugzilla.suse.com/1252480
- https://git.kernel.org/stable/c/34cd15d83b7206188d440b29b68084fcafde9395
- https://git.kernel.org/stable/c/34fe9c2251f19786a6689149a6212c6c0de1d63b
- https://git.kernel.org/stable/c/550a4fac7ecfee5bac6a0dd772456ca62fb72f46
- https://git.kernel.org/stable/c/7ae6aa649394e1e7f6dafb55ce0d578c0572a280
- https://git.kernel.org/stable/c/7ee059d06a5d3c15465959e0472993e80fbe4e81
- https://git.kernel.org/stable/c/88430ebcbc0ec637b710b947738839848c20feff
- https://git.kernel.org/stable/c/94e231c9d6f2648d2f1f68e7f476e050ee0a6159
- https://git.kernel.org/stable/c/d9971fa4d8bde63d49c743c1b32d12fbbd3a30bd
- https://git.kernel.org/stable/c/e8b8e0d2bbf7d1172c4f435621418e29ee408d46