CVE-2022-50579
published 2025-10-22CVE-2022-50579: 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…
PriorityP422medium4.4
EPSS
0.20%
10.2th percentile
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
| [] 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: ffff800
Affected
19 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.3-1 (bookworm) | linux 6.0.3-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 5.10.124 < 5.10.150 | 5.10.150 |
| linux | linux | >= 5.15.49 < 5.15.75 | 5.15.75 |
| linux | linux | >= 5.18.6 < 5.19 | 5.19 |
| linux | linux | >= a6253579977e4c6f7818eeb05bf2bc65678a7187 < 0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2 | 0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2 |
| linux | linux | >= a6253579977e4c6f7818eeb05bf2bc65678a7187 < 985432303cf7d4804fb2c2fdfbf0466a796d68c3 | 985432303cf7d4804fb2c2fdfbf0466a796d68c3 |
| linux | linux | >= a6253579977e4c6f7818eeb05bf2bc65678a7187 < 8cfb08575c6d4585f1ce0deeb189e5c824776b04 | 8cfb08575c6d4585f1ce0deeb189e5c824776b04 |
| linux | linux | >= bc28fde90937a920f7714ec4408269cac744f796 < 657de36c72f57fa172a66b06f826b3f5bc56f42e | 657de36c72f57fa172a66b06f826b3f5bc56f42e |
| linux | linux | >= db73aa9466338ec821ed2a0b01721fe4d06876b1 < 6c93b683cedaef745884cb9d554d02ed6266b897 | 6c93b683cedaef745884cb9d554d02ed6266b897 |
| linux | linux_kernel | >= 0 < 5.10.158-1 | 5.10.158-1 |
| linux | linux_kernel | >= 0 < 6.0.3-1 | 6.0.3-1 |
| linux | linux_kernel | >= 0 < 6.0.3-1 | 6.0.3-1 |
| linux | linux_kernel | >= 0 < 6.0.3-1 | 6.0.3-1 |
| linux | linux_kernel | >= 0 < 5.10.150 | 5.10.150 |
| linux | linux_kernel | >= 5.11.0 < 5.15.75 | 5.15.75 |
| linux | linux_kernel | >= 5.16.0 < 5.19.17 | 5.19.17 |
| linux | linux_kernel | >= 5.19.0 < 6.0.3 | 6.0.3 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: arm64: ftrace: fix module PLTs with mcount
vendor_redhat·2025-10-22·CVSS 4.4
CVE-2022-50579 [MEDIUM] CWE-754 kernel: arm64: ftrace: fix module PLTs with mcount
kernel: arm64: ftrace: fix module PLTs with mcount
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
Debian
CVE-2022-50579: linux - In the Linux kernel, the following vulnerability has been resolved: arm64: ftra...
vendor_debian·2022
CVE-2022-50579 CVE-2022-50579: linux - In the Linux kernel, the following vulnerability has been resolved: arm64: ftra...
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 ftra
OSV
CVE-2022-50579: In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: fix module PLTs with mcount Li Huafei reports that mcount-based ftr
osv·2025-10-22
CVE-2022-50579 CVE-2022-50579: In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: fix module PLTs with mcount Li Huafei reports that mcount-based ftr
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 ftra
GHSA
GHSA-g367-xgmw-wp3r: In the Linux kernel, the following vulnerability has been resolved:
arm64: ftrace: fix module PLTs with mcount
Li Huafei reports that mcount-based f
ghsa_unreviewed·2025-10-22
CVE-2022-50579 GHSA-g367-xgmw-wp3r: In the Linux kernel, the following vulnerability has been resolved:
arm64: ftrace: fix module PLTs with mcount
Li Huafei reports that mcount-based f
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
OSV
arm64: ftrace: fix module PLTs with mcount
osv·2025-10-22
CVE-2022-50579 arm64: ftrace: fix module PLTs with mcount
arm64: ftrace: fix module PLTs with mcount
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 poi
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2https://git.kernel.org/stable/c/657de36c72f57fa172a66b06f826b3f5bc56f42ehttps://git.kernel.org/stable/c/6c93b683cedaef745884cb9d554d02ed6266b897https://git.kernel.org/stable/c/8cfb08575c6d4585f1ce0deeb189e5c824776b04https://git.kernel.org/stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3
2025-10-22
Published