fkie_cve-2022-50579
Vulnerability from fkie_nvd
Published
2025-10-22 14:15
Modified
2025-10-22 21:12
Severity ?
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/657de36c72f57fa172a66b06f826b3f5bc56f42e
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6c93b683cedaef745884cb9d554d02ed6266b897
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8cfb08575c6d4585f1ce0deeb189e5c824776b04
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: ftrace: fix module PLTs with mcount\n\nLi Huafei reports that mcount-based ftrace with module PLTs was broken\nby commit:\n\n  a6253579977e4c6f (\"arm64: ftrace: consistently handle PLTs.\")\n\nWhen a module PLTs are used and a module is loaded sufficiently far away\nfrom the kernel, we\u0027ll create PLTs for any branches which are\nout-of-range. These are separate from the special ftrace trampoline\nPLTs, which the module PLT code doesn\u0027t directly manipulate.\n\nWhen mcount is in use this is a problem, as each mcount callsite in a\nmodule will be initialized to point to a module PLT, but since commit\na6253579977e4c6f ftrace_make_nop() will assume that the callsite has\nbeen initialized to point to the special ftrace trampoline PLT, and\nftrace_find_callable_addr() rejects other cases.\n\nThis means that when ftrace tries to initialize a callsite via\nftrace_make_nop(), the call to ftrace_find_callable_addr() will find\nthat the `_mcount` stub is out-of-range and is not handled by the ftrace\nPLT, resulting in a splat:\n\n| ftrace_test: loading out-of-tree module taints kernel.\n| ftrace: no module PLT for _mcount\n| ------------[ ftrace bug ]------------\n| ftrace failed to modify\n| [\u003cffff800029180014\u003e] 0xffff800029180014\n|  actual:   44:00:00:94\n| Initializing ftrace call sites\n| ftrace record flags: 2000000\n|  (0)\n|  expected tramp: ffff80000802eb3c\n| ------------[ cut here ]------------\n| WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270\n| Modules linked in:\n| CPU: 3 PID: 157 Comm: insmod Tainted: G           O       6.0.0-rc6-00151-gcd722513a189-dirty #22\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : ftrace_bug+0x94/0x270\n| lr : ftrace_bug+0x21c/0x270\n| sp : ffff80000b2bbaf0\n| x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000\n| x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00\n| x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8\n| x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff\n| x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118\n| x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666\n| x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030\n| x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4\n| x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001\n| x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022\n| Call trace:\n|  ftrace_bug+0x94/0x270\n|  ftrace_process_locs+0x308/0x430\n|  ftrace_module_init+0x44/0x60\n|  load_module+0x15b4/0x1ce8\n|  __do_sys_init_module+0x1ec/0x238\n|  __arm64_sys_init_module+0x24/0x30\n|  invoke_syscall+0x54/0x118\n|  el0_svc_common.constprop.4+0x84/0x100\n|  do_el0_svc+0x3c/0xd0\n|  el0_svc+0x1c/0x50\n|  el0t_64_sync_handler+0x90/0xb8\n|  el0t_64_sync+0x15c/0x160\n| ---[ end trace 0000000000000000 ]---\n| ---------test_init-----------\n\nFix this by reverting to the old behaviour of ignoring the old\ninstruction when initialising an mcount callsite in a module, which was\nthe behaviour prior to commit a6253579977e4c6f."
    }
  ],
  "id": "CVE-2022-50579",
  "lastModified": "2025-10-22T21:12:48.953",
  "metrics": {},
  "published": "2025-10-22T14:15:42.927",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/657de36c72f57fa172a66b06f826b3f5bc56f42e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6c93b683cedaef745884cb9d554d02ed6266b897"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8cfb08575c6d4585f1ce0deeb189e5c824776b04"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/985432303cf7d4804fb2c2fdfbf0466a796d68c3"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • 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.