https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 09:46:13 +0000 https://vulnerability.circl.lu/vuln/cve-2022-49721 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arm64: ftrace: consistently handle PLTs.</p> <p>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:</p> <p>3b23e4991fb66f6d (&#34;arm64: implement ftrace with regs&#34;)</p> <p>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:</p> <p>a) If the old addr requires a trampoline, ftrace_modify_call() will use an out-of-range address to generate the &#39;old&#39; 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.</p> <p>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 &#39;new&#39; branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace the &#39;old&#39; branch with a BRK. This will result in a kernel panic when this BRK is later executed.</p> <p>Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don&#39;t necessarily affect the rest of t…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arm64: ftrace: consistently handle PLTs.</p> <p>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:</p> <p>3b23e4991fb66f6d (&#34;arm64: implement ftrace with regs&#34;)</p> <p>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:</p> <p>a) If the old addr requires a trampoline, ftrace_modify_call() will use an out-of-range address to generate the &#39;old&#39; 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.</p> <p>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 &#39;new&#39; branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace the &#39;old&#39; branch with a BRK. This will result in a kernel panic when this BRK is later executed.</p> <p>Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don&#39;t necessarily affect the rest of t…</p> https://vulnerability.circl.lu/vuln/cve-2022-49721