Skip to content
Heist/ feed
Back to feed
UnratedFix available

arm64: ftrace: consistently handle PLTs.

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: consistently handle PLTs. Sometimes it is necessary to use a PLT entry to call an ftrace trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(), with each having *almost* identical logic, but this is not handled by ftrace_modify_call() since its introduction in commit: 3b23e4991fb66f6d ("arm64: implement ftrace with regs") Due to this, if we ever were to call ftrace_modify_call() for a callsite which requires a PLT entry for a trampoline, then either: a) If the old addr requires a trampoline, ftrace_modify_call() will use an out-of-range address to generate the 'old' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm() and ftrace_modify_code(), and no instructions will be modified. As ftrace_modify_call() will return an error, this will result in subsequent internal ftrace errors. b) If the old addr does not require a trampoline, but the new addr does, ftrace_modify_call() will use an out-of-range address to generate the 'new' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace the 'old' branch with a BRK. This will result in a kernel panic when this BRK is later executed. Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don't necessarily affect the rest of the system. This can be demonstrated with

Products
Kernel
Affected versions
Not specified
Fixed versions
5.10.124, 5.15.49, 5.18.6
CVEs
CVE-2022-49721
Confirmed fixed CVEs
Not specified
Updated in this feed
3 Nov 2026, 17:32 UTC · Revision 1

Source evidence

arm64: ftrace: consistently handle PLTs.

core-osv · Original source

Published 26 Feb 2025, 02:24 UTC

In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: consistently handle PLTs. Sometimes it is necessary to use a PLT entry to call an ftrace trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(), with each having *almost* identical logic, but this is not handled by ftrace_modify_call() since its introduction in commit: 3b23e4991fb66f6d ("arm64: implement ftrace with regs") Due to this, if we ever were to call ftrace_modify_call() for a callsite which requires a PLT entry for a trampoline, then either: a) If the old addr requires a trampoline, ftrace_modify_call() will use an out-of-range address to generate the 'old' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm() and ftrace_modify_code(), and no instructions will be modified. As ftrace_modify_call() will return an error, this will result in subsequent internal ftrace errors. b) If the old addr does not require a trampoline, but the new addr does, ftrace_modify_call() will use an out-of-range address to generate the 'new' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace the 'old' branch with a BRK. This will result in a kernel panic when this BRK is later executed. Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don't necessarily affect the rest of the system. This can be demonstrated with

osv:CVE-2022-49721

Kernel

Fixed versions: 5.10.124, 5.15.49, 5.18.6

Complete source record
{
  "id": "9e8575f3e8ace0ae88ea8666611190192bc3633b69bc9d7ad7a6b548c5d1b795",
  "url": "https://osv.dev/vulnerability/CVE-2022-49721",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "arm64: ftrace: consistently handle PLTs.",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: consistently handle PLTs. Sometimes it is necessary to use a PLT entry to call an ftrace trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(), with each having *almost* identical logic, but this is not handled by ftrace_modify_call() since its introduction in commit: 3b23e4991fb66f6d (\"arm64: implement ftrace with regs\") Due to this, if we ever were to call ftrace_modify_call() for a callsite which requires a PLT entry for a trampoline, then either: a) If the old addr requires a trampoline, ftrace_modify_call() will use an out-of-range address to generate the 'old' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm() and ftrace_modify_code(), and no instructions will be modified. As ftrace_modify_call() will return an error, this will result in subsequent internal ftrace errors. b) If the old addr does not require a trampoline, but the new addr does, ftrace_modify_call() will use an out-of-range address to generate the 'new' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace the 'old' branch with a BRK. This will result in a kernel panic when this BRK is later executed. Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don't necessarily affect the rest of the system. This can be demonstrated with",
    "evidence": "osv:CVE-2022-49721",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.10.124",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "5.15.49",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "5.18.6",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2022-49721",
      "aliases": [
        "CVE-2022-49721"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "3b23e4991fb66f6d152f9055ede271a726ef9f21"
                },
                {
                  "fixed": "bc28fde90937a920f7714ec4408269cac744f796"
                },
                {
                  "fixed": "db73aa9466338ec821ed2a0b01721fe4d06876b1"
                },
                {
                  "fixed": "dcecc96ed16f73417de5550f384e348c9d56f279"
                },
                {
                  "fixed": "a6253579977e4c6f7818eeb05bf2bc65678a7187"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-49721.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.5.0"
                },
                {
                  "fixed": "5.10.124"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.11.0"
                },
                {
                  "fixed": "5.15.49"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "5.18.6"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-49721.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:31.102566750Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/a6253579977e4c6f7818eeb05bf2bc65678a7187",
        "https://git.kernel.org/stable/c/bc28fde90937a920f7714ec4408269cac744f796",
        "https://git.kernel.org/stable/c/db73aa9466338ec821ed2a0b01721fe4d06876b1",
        "https://git.kernel.org/stable/c/dcecc96ed16f73417de5550f384e348c9d56f279",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49721.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2022-49721",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/49xxx/CVE-2022-49721.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2022-49721",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 497866,
  "published_at": "2025-02-26T02:24:34.685+00:00"
}