{
  "cveId": "CVE-2022-50579",
  "url": "https://patchblox.com/security/cve/CVE-2022-50579",
  "summary": "CVE-2022-50579 is fixed in linux on 1 platform, first by DEBIAN-CVE-2022-50579, released October 22, 2025. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  arm64: ftrace: fix module PLTs with mcount  Li H...",
  "description": "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 (\u0022arm64: ftrace: consistently handle PLTs.\u0022)  When a module PLTs are used and a module is loaded sufficiently far away from the kernel, we\u0027ll 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\u0027t 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 \u0060_mcount\u0060 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 | [\u003Cffff800029180014\u003E] 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\u002B0x94/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\u002B0x94/0x270 | lr : ftrace_bug\u002B0x21c/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\u002B0x94/0x270 |  ftrace_process_locs\u002B0x308/0x430 |  ftrace_module_init\u002B0x44/0x60 |  load_module\u002B0x15b4/0x1ce8 |  __do_sys_init_module\u002B0x1ec/0x238 |  __arm64_sys_init_module\u002B0x24/0x30 |  invoke_syscall\u002B0x54/0x118 |  el0_svc_common.constprop.4\u002B0x84/0x100 |  do_el0_svc\u002B0x3c/0xd0 |  el0_svc\u002B0x1c/0x50 |  el0t_64_sync_handler\u002B0x90/0xb8 |  el0t_64_sync\u002B0x15c/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.",
  "published": "2025-10-22T14:15:42Z",
  "severity": "",
  "epss": 0.00214,
  "epssPercentile": 0.11765,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 12.15 (bookworm)",
      "fixedVersion": "6.0.3-1",
      "fix": "DEBIAN-CVE-2022-50579",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-50579",
      "released": "2025-10-22T14:15:42Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.0.3-1",
      "fix": "DEBIAN-CVE-2022-50579",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-50579",
      "released": "2025-10-22T14:15:42Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "6.0.3-1",
      "fix": "DEBIAN-CVE-2022-50579",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-50579",
      "released": "2025-10-22T14:15:42Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-09T01:18:40Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}