Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
On Mon, Aug 17, 2026 at 02:11:26PM +0300, Ard Biesheuvel wrote:
> On Sat, 15 Aug 2026, at 21:57, Josh Poimboeuf wrote:
> > On Sat, Aug 15, 2026 at 12:56:11PM +0300, Ard Biesheuvel wrote:
> >> On Sat, 15 Aug 2026, at 07:45, Josh Poimboeuf wrote:
> >> > The following BTI exception was seen when loading a livepatch module:
> >> >
> >> > Internal error: Oops - BTI: 3601 [#1] SMP
> >> > pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
> >> > pc : kill_orphaned_pgrp+0x0/0x150
> >> > lr : do_exit+0x498/0xaf0 [livepatch_combined]
> >> >
> >> > The problem is that the patch module's do_exit() is branching to a
> >> > static function in vmlinux using a module PLT veneer (indirect branch),
> >> > but the target function doesn't have a BTI landing pad.
> >> >
> >> > Clang 21+ omits the landing pad for static functions which can only be
> >> > reached by a direct branch. But livepatch modules use klp relocations
> >> > to reference arbitrary kernel symbols, and with
> >> > CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that
> >> > every call to vmlinux needs a PLT.
> >> >
> >> > Note this problem is actually not specific to livepatch. It's possible
> >> > for any module's .init section to be allocated > 128MB away from its
> >> > .text section. So calls from .init to .text via a PLT can trigger a BTI
> >> > exception when the target function doesn't have a landing pad.
> >> >
> >> > GCC has always omitted the landing pad when possible, so kernel BTI is
> >> > already considered incompatible with GCC since commit c0a454b9044f
> >> > ("arm64/bti: Disable in kernel BTI when cross section thunks are
> >> > broken").
> >> >
> >> > When missing landing pads are detected, allocate a page close to the
> >> > target which can be used to hold BTI veneers which receive PLT veneer
> >> > indirect branches and direct branch to the final target:
> >> >
> >>
> >> This does not work for cross-section calls from .init.text to .text.
> >>
> >> If .init.text is far away from .text, it is likely because .text
> >> ended up in the 128M 'near' module region, and .init.text did not.
> >> (They tend to end up in direct branching range of each otherwise.)
> >>
> >> Given that the module init code is typically small, I don't think
> >> it is safe to assume that allocating a single page close enough to
> >> .text is going to be possible if allocating the space for .init.*
> >> was not.
> >>
> >> IOW, the fix I proposed for cross-section calls is still needed
> >> with this approach.
> >
> > But the BTI veneer page is allocated from a *256MB* window, of which the
> > near region is only a 128MB subset.
> >
>
> OK, so this window would be [_etext - 128M, _text + 128M), right? Or
> whichever the equivalent is for a kernel module?
>
> I agree that this considerably reduces the likelihood of running out
> of veneer space within direct branching range.
It's a *moving* 256M window centered around a given branch target:
[target - 128M, target + 128M). The window always fully contains the
near region, *plus* another 128MB: 128M - (target - base) below the
region and (target - base) above, which always adds up to an extra
128MB. So it has a much bigger pool to choose from than module text
does.
It does try to allocate inside the region, or right after it, so the
page can be shared by other branches in the same module if possible.
But it can allocate more above or below as needed.
> > There is a theoretical case where the 256MB window around the target is
> > completely full without any fragmentation, but I would think that there
> > would almost always be some fragmentation. If that window is modules
> > stacked together, most modules have at least .init.plt and .init.text,
> > and many have .init.data.
> >
>
> Are you saying these are freed again once the module is initialized, and
> therefore there is fragmentation? Not sure if it works like that if modules
> are loaded one after the other.
Not sure I understand your question, but yes, the module init mem is
allocated from the same pool as other module memory, and freed once
module init is done, able to be reused, causing fragmentation.
If multiple modules get loaded all at the same time before any module
init memory has a chance to get freed, presumably fragmentation wouldn't
be much of an issue yet and the given module's .init.text would get
allocated close to .text in the first place.
> > Right now it needs two pages (because of the default guard page) but we
> > could maybe fall back to VM_NO_GUARD in case of emergency.
> >
>
> I like the advantage of only allocating veneers if they are really needed,
> as opposed to allocating the space unconditionally, which is what my
> solution does. But I need more convincing that this will actually cover
> all these cases, given that the cross-section call issue only occurs when
> running out of direct branching space to begin with.
Right, so if .text fits in the near region, and a
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
On Sat, 15 Aug 2026, at 21:57, Josh Poimboeuf wrote:
> On Sat, Aug 15, 2026 at 12:56:11PM +0300, Ard Biesheuvel wrote:
>> Hi Josh,
>>
>> On Sat, 15 Aug 2026, at 07:45, Josh Poimboeuf wrote:
>> > The following BTI exception was seen when loading a livepatch module:
>> >
>> > Internal error: Oops - BTI: 3601 [#1] SMP
>> > pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
>> > pc : kill_orphaned_pgrp+0x0/0x150
>> > lr : do_exit+0x498/0xaf0 [livepatch_combined]
>> >
>> > The problem is that the patch module's do_exit() is branching to a
>> > static function in vmlinux using a module PLT veneer (indirect branch),
>> > but the target function doesn't have a BTI landing pad.
>> >
>> > Clang 21+ omits the landing pad for static functions which can only be
>> > reached by a direct branch. But livepatch modules use klp relocations
>> > to reference arbitrary kernel symbols, and with
>> > CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that
>> > every call to vmlinux needs a PLT.
>> >
>> > Note this problem is actually not specific to livepatch. It's possible
>> > for any module's .init section to be allocated > 128MB away from its
>> > .text section. So calls from .init to .text via a PLT can trigger a BTI
>> > exception when the target function doesn't have a landing pad.
>> >
>> > GCC has always omitted the landing pad when possible, so kernel BTI is
>> > already considered incompatible with GCC since commit c0a454b9044f
>> > ("arm64/bti: Disable in kernel BTI when cross section thunks are
>> > broken").
>> >
>> > When missing landing pads are detected, allocate a page close to the
>> > target which can be used to hold BTI veneers which receive PLT veneer
>> > indirect branches and direct branch to the final target:
>> >
>>
>> This does not work for cross-section calls from .init.text to .text.
>>
>> If .init.text is far away from .text, it is likely because .text
>> ended up in the 128M 'near' module region, and .init.text did not.
>> (They tend to end up in direct branching range of each otherwise.)
>>
>> Given that the module init code is typically small, I don't think
>> it is safe to assume that allocating a single page close enough to
>> .text is going to be possible if allocating the space for .init.*
>> was not.
>>
>> IOW, the fix I proposed for cross-section calls is still needed
>> with this approach.
>
> But the BTI veneer page is allocated from a *256MB* window, of which the
> near region is only a 128MB subset.
>
OK, so this window would be [_etext - 128M, _text + 128M), right? Or
whichever the equivalent is for a kernel module?
I agree that this considerably reduces the likelihood of running out
of veneer space within direct branching range.
> There is a theoretical case where the 256MB window around the target is
> completely full without any fragmentation, but I would think that there
> would almost always be some fragmentation. If that window is modules
> stacked together, most modules have at least .init.plt and .init.text,
> and many have .init.data.
>
Are you saying these are freed again once the module is initialized, and
therefore there is fragmentation? Not sure if it works like that if modules
are loaded one after the other.
> Right now it needs two pages (because of the default guard page) but we
> could maybe fall back to VM_NO_GUARD in case of emergency.
>
I like the advantage of only allocating veneers if they are really needed,
as opposed to allocating the space unconditionally, which is what my
solution does. But I need more convincing that this will actually cover
all these cases, given that the cross-section call issue only occurs when
running out of direct branching space to begin with.
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
On Sun, Aug 16, 2026 at 04:49:59PM +0300, Ard Biesheuvel wrote: > On Sun, 16 Aug 2026, at 12:41, Will Deacon wrote: > > Overall, it seems to me like there are three cases we need to consider > > for re-enabling BTI in the kernel: > > > > 1. A cross-section call that spans beyond the 128M range and therefore > >needs a veneer. I think the static linker should resolve this, probably > >by emitting a second veneer with the landing pad. Do we know if LLD > >gets this right? > > > > There are two variants here: > > A cross-section call .init.text to .text that spans beyond the 128M range: > > 1a. inside vmlinux, which should be dealt with by the linker, but which might > be unreliable in practice due to the lack of BTI annotations in asm files, > missing exec permissions on ELF sections etc. This is addressed by this > series, > but is only an issue for unusually large kernel images (e.g., allyesconfig). Right, and if we don't care about the >128MB kernel case (I have no idea if anybody actually uses that big of a kernel?), then we can basically just drop patches 3-11 in favor of a simple linker assertion (similar to patches 5 and 6) which just *always* triggers a build error on a large kernel + BTI + !COMPILE_TEST. -- Josh
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
On Sun, 16 Aug 2026, at 12:41, Will Deacon wrote:
> Hi Josh, Ard,
>
> On Sat, Aug 15, 2026 at 12:56:11PM +0300, Ard Biesheuvel wrote:
>> On Sat, 15 Aug 2026, at 07:45, Josh Poimboeuf wrote:
>> > The following BTI exception was seen when loading a livepatch module:
>> >
>> > Internal error: Oops - BTI: 3601 [#1] SMP
>> > pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
>> > pc : kill_orphaned_pgrp+0x0/0x150
>> > lr : do_exit+0x498/0xaf0 [livepatch_combined]
>> >
>> > The problem is that the patch module's do_exit() is branching to a
>> > static function in vmlinux using a module PLT veneer (indirect branch),
>> > but the target function doesn't have a BTI landing pad.
>> >
>> > Clang 21+ omits the landing pad for static functions which can only be
>> > reached by a direct branch. But livepatch modules use klp relocations
>> > to reference arbitrary kernel symbols, and with
>> > CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that
>> > every call to vmlinux needs a PLT.
>> >
>> > Note this problem is actually not specific to livepatch. It's possible
>> > for any module's .init section to be allocated > 128MB away from its
>> > .text section. So calls from .init to .text via a PLT can trigger a BTI
>> > exception when the target function doesn't have a landing pad.
>> >
>> > GCC has always omitted the landing pad when possible, so kernel BTI is
>> > already considered incompatible with GCC since commit c0a454b9044f
>> > ("arm64/bti: Disable in kernel BTI when cross section thunks are
>> > broken").
>> >
>> > When missing landing pads are detected, allocate a page close to the
>> > target which can be used to hold BTI veneers which receive PLT veneer
>> > indirect branches and direct branch to the final target:
>> >
>>
>> This does not work for cross-section calls from .init.text to .text.
>>
>> If .init.text is far away from .text, it is likely because .text
>> ended up in the 128M 'near' module region, and .init.text did not.
>> (They tend to end up in direct branching range of each otherwise.)
>>
>> Given that the module init code is typically small, I don't think
>> it is safe to assume that allocating a single page close enough to
>> .text is going to be possible if allocating the space for .init.*
>> was not.
>>
>> IOW, the fix I proposed for cross-section calls is still needed
>> with this approach.
>
> Sorry to jump in here, but I couldn't figure out a better place to get
> involved as we have a few threads on this now.
>
> Overall, it seems to me like there are three cases we need to consider
> for re-enabling BTI in the kernel:
>
> 1. A cross-section call that spans beyond the 128M range and therefore
>needs a veneer. I think the static linker should resolve this, probably
>by emitting a second veneer with the landing pad. Do we know if LLD
>gets this right?
>
There are two variants here:
A cross-section call .init.text to .text that spans beyond the 128M range:
1a. inside vmlinux, which should be dealt with by the linker, but which might
be unreliable in practice due to the lack of BTI annotations in asm files,
missing exec permissions on ELF sections etc. This is addressed by this series,
but is only an issue for unusually large kernel images (e.g., allyesconfig).
1b. inside a module, which the toolchains's static linker cannot be expected to
deal with, given that modules are not fully linked executables. Therefore, the
module loader should deal with this, which is what my patch [0] implements. Note
that this only occurs when .init.text ends up far away from the .text section of
the same module, which occurs rarely in practice.
> 2. Calls from modules to exported symbols that end up going via a PLT
>due to module placement. Exported symbols shouldn't be static, so we
>should have the correct BTI landing pad in this case (and if we don't,
>we should fix EXPORT_SYMBOL() to add it).
>
This is not an issue today as far as I am aware.
> 3. The livepatch case where a module appears to branch directly to
>static functions in the kernel. For this, I frankly think we should
>either make in-kernel BTI depend on !LIVEPATCH _or_ pass some compiler
>option (tbd) when livepatch is enabled so that we get landing pads
>for static functions (which is what I believe Clang/GCC used to do?).
>
The livepatch practice of lifting code out of vmlinux at function
granularity and copying it into KLP modules in order to patch a running
kernel is so far removed from the typical usage expected by the toolchain
that it is justified to treat it as a separate case. Working with the
compiler folks to allow this optimization to be disabled would be one way
to deal with this (and disabling kernel mode BTI for compilers that do
not implement it)
That said, my patch [0] only fixes case 1b., which is quite rare in
practice, and could perhaps be eliminated entirely if we manage to tweak
the module loader so that it always
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
Hi Josh, Ard,
On Sat, Aug 15, 2026 at 12:56:11PM +0300, Ard Biesheuvel wrote:
> On Sat, 15 Aug 2026, at 07:45, Josh Poimboeuf wrote:
> > The following BTI exception was seen when loading a livepatch module:
> >
> > Internal error: Oops - BTI: 3601 [#1] SMP
> > pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
> > pc : kill_orphaned_pgrp+0x0/0x150
> > lr : do_exit+0x498/0xaf0 [livepatch_combined]
> >
> > The problem is that the patch module's do_exit() is branching to a
> > static function in vmlinux using a module PLT veneer (indirect branch),
> > but the target function doesn't have a BTI landing pad.
> >
> > Clang 21+ omits the landing pad for static functions which can only be
> > reached by a direct branch. But livepatch modules use klp relocations
> > to reference arbitrary kernel symbols, and with
> > CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that
> > every call to vmlinux needs a PLT.
> >
> > Note this problem is actually not specific to livepatch. It's possible
> > for any module's .init section to be allocated > 128MB away from its
> > .text section. So calls from .init to .text via a PLT can trigger a BTI
> > exception when the target function doesn't have a landing pad.
> >
> > GCC has always omitted the landing pad when possible, so kernel BTI is
> > already considered incompatible with GCC since commit c0a454b9044f
> > ("arm64/bti: Disable in kernel BTI when cross section thunks are
> > broken").
> >
> > When missing landing pads are detected, allocate a page close to the
> > target which can be used to hold BTI veneers which receive PLT veneer
> > indirect branches and direct branch to the final target:
> >
>
> This does not work for cross-section calls from .init.text to .text.
>
> If .init.text is far away from .text, it is likely because .text
> ended up in the 128M 'near' module region, and .init.text did not.
> (They tend to end up in direct branching range of each otherwise.)
>
> Given that the module init code is typically small, I don't think
> it is safe to assume that allocating a single page close enough to
> .text is going to be possible if allocating the space for .init.*
> was not.
>
> IOW, the fix I proposed for cross-section calls is still needed
> with this approach.
Sorry to jump in here, but I couldn't figure out a better place to get
involved as we have a few threads on this now.
Overall, it seems to me like there are three cases we need to consider
for re-enabling BTI in the kernel:
1. A cross-section call that spans beyond the 128M range and therefore
needs a veneer. I think the static linker should resolve this, probably
by emitting a second veneer with the landing pad. Do we know if LLD
gets this right?
2. Calls from modules to exported symbols that end up going via a PLT
due to module placement. Exported symbols shouldn't be static, so we
should have the correct BTI landing pad in this case (and if we don't,
we should fix EXPORT_SYMBOL() to add it).
3. The livepatch case where a module appears to branch directly to
static functions in the kernel. For this, I frankly think we should
either make in-kernel BTI depend on !LIVEPATCH _or_ pass some compiler
option (tbd) when livepatch is enabled so that we get landing pads
for static functions (which is what I believe Clang/GCC used to do?).
What am I missing?
Will
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
On Sat, Aug 15, 2026 at 12:56:11PM +0300, Ard Biesheuvel wrote:
> Hi Josh,
>
> On Sat, 15 Aug 2026, at 07:45, Josh Poimboeuf wrote:
> > The following BTI exception was seen when loading a livepatch module:
> >
> > Internal error: Oops - BTI: 3601 [#1] SMP
> > pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
> > pc : kill_orphaned_pgrp+0x0/0x150
> > lr : do_exit+0x498/0xaf0 [livepatch_combined]
> >
> > The problem is that the patch module's do_exit() is branching to a
> > static function in vmlinux using a module PLT veneer (indirect branch),
> > but the target function doesn't have a BTI landing pad.
> >
> > Clang 21+ omits the landing pad for static functions which can only be
> > reached by a direct branch. But livepatch modules use klp relocations
> > to reference arbitrary kernel symbols, and with
> > CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that
> > every call to vmlinux needs a PLT.
> >
> > Note this problem is actually not specific to livepatch. It's possible
> > for any module's .init section to be allocated > 128MB away from its
> > .text section. So calls from .init to .text via a PLT can trigger a BTI
> > exception when the target function doesn't have a landing pad.
> >
> > GCC has always omitted the landing pad when possible, so kernel BTI is
> > already considered incompatible with GCC since commit c0a454b9044f
> > ("arm64/bti: Disable in kernel BTI when cross section thunks are
> > broken").
> >
> > When missing landing pads are detected, allocate a page close to the
> > target which can be used to hold BTI veneers which receive PLT veneer
> > indirect branches and direct branch to the final target:
> >
>
> This does not work for cross-section calls from .init.text to .text.
>
> If .init.text is far away from .text, it is likely because .text
> ended up in the 128M 'near' module region, and .init.text did not.
> (They tend to end up in direct branching range of each otherwise.)
>
> Given that the module init code is typically small, I don't think
> it is safe to assume that allocating a single page close enough to
> .text is going to be possible if allocating the space for .init.*
> was not.
>
> IOW, the fix I proposed for cross-section calls is still needed
> with this approach.
But the BTI veneer page is allocated from a *256MB* window, of which the
near region is only a 128MB subset.
There is a theoretical case where the 256MB window around the target is
completely full without any fragmentation, but I would think that there
would almost always be some fragmentation. If that window is modules
stacked together, most modules have at least .init.plt and .init.text,
and many have .init.data.
Right now it needs two pages (because of the default guard page) but we
could maybe fall back to VM_NO_GUARD in case of emergency.
--
Josh
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
Hi Josh,
On Sat, 15 Aug 2026, at 07:45, Josh Poimboeuf wrote:
> The following BTI exception was seen when loading a livepatch module:
>
> Internal error: Oops - BTI: 3601 [#1] SMP
> pstate: 634004c9 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=jc)
> pc : kill_orphaned_pgrp+0x0/0x150
> lr : do_exit+0x498/0xaf0 [livepatch_combined]
>
> The problem is that the patch module's do_exit() is branching to a
> static function in vmlinux using a module PLT veneer (indirect branch),
> but the target function doesn't have a BTI landing pad.
>
> Clang 21+ omits the landing pad for static functions which can only be
> reached by a direct branch. But livepatch modules use klp relocations
> to reference arbitrary kernel symbols, and with
> CONFIG_RANDOMIZE_MODULE_REGION_FULL the module is far enough away that
> every call to vmlinux needs a PLT.
>
> Note this problem is actually not specific to livepatch. It's possible
> for any module's .init section to be allocated > 128MB away from its
> .text section. So calls from .init to .text via a PLT can trigger a BTI
> exception when the target function doesn't have a landing pad.
>
> GCC has always omitted the landing pad when possible, so kernel BTI is
> already considered incompatible with GCC since commit c0a454b9044f
> ("arm64/bti: Disable in kernel BTI when cross section thunks are
> broken").
>
> When missing landing pads are detected, allocate a page close to the
> target which can be used to hold BTI veneers which receive PLT veneer
> indirect branches and direct branch to the final target:
>
This does not work for cross-section calls from .init.text to .text.
If .init.text is far away from .text, it is likely because .text
ended up in the 128M 'near' module region, and .init.text did not.
(They tend to end up in direct branching range of each otherwise.)
Given that the module init code is typically small, I don't think
it is safe to assume that allocating a single page close enough to
.text is going to be possible if allocating the space for .init.*
was not.
IOW, the fix I proposed for cross-section calls is still needed
with this approach.
Re: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
Thank you for your contribution! Sashiko AI review found 2 potential issue(s)
to consider:
Pre-existing issues:
- [High] Direct memory assignment to the PLT section bypasses text patching,
causing a Data Abort when a livepatch module applies relocations to a newly
loaded target module.
- [High] The `aarch64_insn_set()` function incorrectly writes A64 instructions
in host byte order, causing BTI veneer pages to be filled with corrupt
instruction encodings on Big Endian systems.
--
--- Patch [2]: [PATCH 02/12] arm64/module: Fix BTI exceptions caused by omitted
landing pads in Clang 21 ---
commit 74ebe0a6ff8b7ada8b741ca9247269a7b1b55fb6
Author: Josh Poimboeuf
arm64/module: Fix BTI exceptions caused by omitted landing pads in Clang 21
This commit fixes BTI exceptions caused by Clang 21+ omitting landing pads
for static functions. It allocates a page close to the target to hold BTI
veneers which receive PLT indirect branches and direct branch to the final
target.
> diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
> index 7afd370da9f48..4ba31e336deb6 100644
> --- a/arch/arm64/kernel/module-plts.c
> +++ b/arch/arm64/kernel/module-plts.c
[ ... ]
> @@ -66,6 +72,180 @@ static bool plt_entries_equal(const struct plt_entry *a,
[ ... ]
> +static struct bti_veneer_page *bti_veneer_page_alloc(struct module *mod,
> + u64 target)
> +{
[ ... ]
> + if (!p) {
> + pr_err("%s: no address space within branch range of %pS for a
> BTI veneer\n",
> +mod->name, (void *)target);
> + return NULL;
> + }
> +
> + /* Don't leave unused slots executable */
> + aarch64_insn_set(p, AARCH64_BREAK_FAULT, PAGE_SIZE);
[Severity: High]
This is a pre-existing issue with aarch64_insn_set(), but does this new
usage write the AARCH64_BREAK_FAULT instruction in the wrong byte order on
Big Endian systems?
Looking at aarch64_insn_set(), it passes the host-endian integer to
memset32(), which performs native 32-bit stores without cpu_to_le32()
conversion:
arch/arm64/kernel/patching.c:aarch64_insn_set() {
...
return __text_poke(text_poke_memset, dst, &insn, len);
}
Since ARMv8 instruction fetches are architecturally always Little Endian,
wouldn't the CPU fetch a byte-reversed, corrupt instruction (reading
0x20d4) on Big Endian systems, resulting in a fatal Unknown instruction
exception rather than a BRK exception if an unused slot is executed?
> +
> + page = kzalloc_obj(*page, GFP_KERNEL);
> + if (!page) {
[ ... ]
> @@ -77,6 +257,12 @@ u64 module_emit_plt_entry(struct module *mod, Elf64_Shdr
> *sechdrs,
> void *loc, const Elf64_Rela *rela,
> Elf64_Sym *sym)
> {
[ ... ]
> u64 val = sym->st_value + rela->r_addend;
>
> + if (!plt_target_has_landing_pad(val)) {
> + val = module_emit_bti_veneer(mod, val);
> + if (!val)
> + return 0;
> + }
> +
> if (is_forbidden_offset_for_adrp(&plt[i].adrp))
> i++;
>
> plt[i] = get_plt_entry(val, &plt[i]);
[Severity: High]
This isn't a bug introduced by this patch, but can this direct memory
assignment cause a Data Abort kernel panic when a livepatch module applies
relocations to a newly loaded target module?
If a livepatch module is already loaded and active, its sections (including
the PLT) are marked ROX. When a new target module loads,
klp_module_coming() calls apply_relocate_add() to apply the patch module's
relocations for this new target.
If an out-of-range jump requires a new PLT entry, it seems this direct
assignment to the ROX plt memory array bypasses text patching mechanisms
like patch_map() or aarch64_insn_copy().
--
Sashiko AI review ยท
https://sashiko.dev/#/patchset/[email protected]?part=2
