CVE-2022-50579 json
arm64: ftrace: fix module PLTs with mcount
published 2025-10-22 12 mo ago modified 2026-06-17 4 mo ago also EUVD-2022-55649
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 11%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
arm64: ftrace: fix module PLTs with mcount
Li Huafei reports that mcount-based ftrace with module PLTs was broken by commit:
a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.")
When a module PLTs are used and a module is loaded sufficiently far away from the kernel, we'll create PLTs for any branches which are out-of-range. These are separate from the special ftrace trampoline PLTs, which the module PLT code doesn't directly manipulate.
When mcount is in use this is a problem, as each mcount callsite in a module will be initialized to point to a module PLT, but since commit a6253579977e4c6f ftrace_make_nop() will assume that the callsite has been initialized to point to the special ftrace trampoline PLT, and ftrace_find_callable_addr() rejects other cases.
This means that when ftrace tries to initialize a callsite via ftrace_make_nop(), the call to ftrace_find_callable_addr() will find that the `_mcount` stub is out-of-range and is not handled by the ftrace PLT, resulting in a splat:
| ftrace_test: loading out-of-tree module taints kernel. | ftrace: no module PLT for _mcount | ------------[ ftrace bug ]------------ | ftrace failed to modify | [<ffff800029180014>] 0xffff800029180014 | actual: 44:00:00:94 | Initializing ftrace call sites | ftrace record flags: 2000000 | (0) | expected tramp: ffff80000802eb3c | ------------[ cut here ]------------ | WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270 | Modules linked in: | CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22 | Hardware name: linux,dummy-virt (DT) | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : ftrace_bug+0x94/0x270 | lr : ftrace_bug+0x21c/0x270 | sp : ffff80000b2bbaf0 | x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000 | x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00 | x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8 | x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff | x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118 | x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666 | x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030 | x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4 | x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001 | x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022 | Call trace: | ftrace_bug+0x94/0x270 | ftrace_process_locs+0x308/0x430 | ftrace_module_init+0x44/0x60 | load_module+0x15b4/0x1ce8 | __do_sys_init_module+0x1ec/0x238 | __arm64_sys_init_module+0x24/0x30 | invoke_syscall+0x54/0x118 | el0_svc_common.constprop.4+0x84/0x100 | do_el0_svc+0x3c/0xd0 | el0_svc+0x1c/0x50 | el0t_64_sync_handler+0x90/0xb8 | el0t_64_sync+0x15c/0x160 | ---[ end trace 0000000000000000 ]--- | ---------test_init-----------
Fix this by reverting to the old behaviour of ignoring the old instruction when initialising an mcount callsite in a module, which was the behaviour prior to commit a6253579977e4c6f.
Patch / fix
- Linux Linux 5.10.150, 5.15.75, 5.19, 5.19.17, 6.0.3, 6.1
- linux Debian 14, Debian 13, Debian 12 6.0.3-1
debian advisories DEBIAN-CVE-2022-50579
- linux Ubuntu 22.04 LTS 5.15.0-60.66
- linux-aws Ubuntu 22.04 LTS 5.15.0-1030.34
- linux-gcp Ubuntu 22.04 LTS 5.15.0-1029.36
- linux-gke Ubuntu 22.04 LTS 5.15.0-1027.32
- linux-ibm Ubuntu 22.04 LTS 5.15.0-1025.28
- linux-kvm Ubuntu 22.04 LTS 5.15.0-1028.33
- linux-azure Ubuntu 22.04 LTS 5.15.0-1033.40
- linux-gkeop Ubuntu 22.04 LTS 5.15.0-1015.19
ubuntu advisories UBUNTU-CVE-2022-50579
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-64kb SLES 15 SP5-LTSS, SLE High Performance Computing 15 SP5-LTSS, SLE High Performance Computing 15 SP5-ESPOS 5.14.21-150500.55.127.1
- kernel-syms SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE High Performance Computing 15 SP5-LTSS +1 more 5.14.21-150500.55.127.1
- kernel-source SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE Micro 5.5 +2 more 5.14.21-150500.55.127.1
- kernel-default SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE Micro 5.5 +3 more 5.14.21-150500.55.127.1
- kernel-obs-build SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE High Performance Computing 15 SP5-LTSS +1 more 5.14.21-150500.55.127.1
- kernel-default-base SLES for SAP 15 SP5, SLES 15 SP5-LTSS, SLE Micro 5.5 +2 more 5.14.21-150500.55.127.1.150500.6.61.1
- kernel-rt SLE Micro 5.5 5.14.21-150500.13.112.1
- kernel-source-rt SLE Micro 5.5 5.14.21-150500.13.112.1
suse advisories SUSE-SU-2025:4320-1SUSE-SU-2025:4149-1SUSE-SU-2025:4139-1SUSE-SU-2025:4111-1
- git.kernel.org/stable/c/657de36c72f57fa172a66b06f826b3f5bc56f42e commit
- git.kernel.org/stable/c/6c93b683cedaef745884cb9d554d02ed6266b897 commit
- git.kernel.org/stable/c/0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2 commit
- git.kernel.org/stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3 commit
- git.kernel.org/stable/c/8cfb08575c6d4585f1ce0deeb189e5c824776b04 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2022-50579 updated cvss 4.4
kernel: arm64: ftrace: fix module PLTs with mcount
-
Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 moreaffected: no fix available
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 10 kernelnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.21% chance of exploitation in the next 30 days, higher than 11% of all scored CVEs (FIRST EPSS, 2026-11-08).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/657de36c72f57fa172a66b06f826b3f5bc56f42e
- git.kernel.org /stable/c/6c93b683cedaef745884cb9d554d02ed6266b897
- git.kernel.org /stable/c/0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2
- git.kernel.org /stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3
- git.kernel.org /stable/c/8cfb08575c6d4585f1ce0deeb189e5c824776b04
Sources
- CVE List CVE-2022-50579
- NVD CVE-2022-50579
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.