Re: [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+
From: sashiko-bot@kernel.org
Date: 2026-08-07 22:00:30
Also in:
linux-arm-kernel, lkml
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Direct assignment to read-only memory in `module_emit_plt_entry()` and `module_emit_veneer_for_adrp()` causes a Data Abort kernel panic when resolving livepatch delayed relocations, and misses instruction cache flushing. --
--- Patch [1]: [PATCH] arm64/module: Fix livepatch BTI exceptions with Clang 21+ ---commit b15500d2c41dfd08d4a46e3f6cffc977c910f40a Author: Josh Poimboeuf [off-list ref] arm64/module: Fix livepatch BTI exceptions with Clang 21+ This commit fixes a BTI exception during livepatch module loading by using RET instead of BR when branching to static functions that lack a BTI landing pad. It introduces a check for landing pads and adjusts the branch instruction emitted by get_plt_entry().
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c index 7afd370da9f48..4249b477daa8b 100644 --- a/arch/arm64/kernel/module-plts.c +++ b/arch/arm64/kernel/module-plts.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -23,14 +26,45 @@ static struct plt_entry __get_adrp_add_pair(u64 dst, u64 pc, return (struct plt_entry){ cpu_to_le32(adrp), cpu_to_le32(add) }; } +static bool plt_target_has_landing_pad(u64 dst) +{
[Severity: High]
This is a pre-existing issue, but does direct assignment to the PLT memory
region cause a Data Abort when livepatch resolves delayed relocations?
When a target module is loaded after a livepatch is active,
apply_relocate_add() calls module_emit_plt_entry() on the livepatch module.
Because the livepatch module is already in a live state, its .plt section
has been marked read-only via strict_module_rwx().
Looking at module_emit_plt_entry() in arch/arm64/kernel/module-plts.c:
module_emit_plt_entry() {
...
plt[i] = get_plt_entry(val, &plt[i]);
...
}
And similarly in module_emit_veneer_for_adrp():
module_emit_veneer_for_adrp() {
...
plt[i] = __get_adrp_add_pair(val, (u64)&plt[i], rd);
plt[i].br = cpu_to_le32(br);
...
}
Since this direct assignment bypasses __text_poke() or aarch64_insn_copy(),
does it trigger a panic due to writing to read-only memory, and also fail
to flush the instruction cache for the newly emitted PLT entry?
--
Sashiko AI review · https://sashiko.dev/#/patchset/ed4fe1f95071897859ec7fbe9176246cbd4962bf.1786138806.git.jpoimboe@kernel.org?part=1