[PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Sourabh Jain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1970 bytes --]

KASAN instrumentation is intended to be disabled for the kexec core
code, but the existing Makefile entry misses the object suffix. As a
result, the flag is not applied correctly to core_$(BITS).o.

So when KASAN is enabled, kexec_copy_flush and copy_segments in
kexec/core_64.c are instrumented, which can result in accesses to
shadow memory via normal address translation paths. Since these run
with the MMU disabled, such accesses may trigger page faults
(bad_page_fault) that cannot be handled in the kdump path, ultimately
causing a hang and preventing the kdump kernel from booting. The same
is true for kexec as well, since the same functions are used there.

Update the entry to include the “.o” suffix so that KASAN
instrumentation is properly disabled for this object file.

Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
Cc: Aditya Gupta <adityag@linux.ibm.com>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
 arch/powerpc/kexec/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
index 470eb0453e17..ec7a0eed75dc 100644
--- a/arch/powerpc/kexec/Makefile
+++ b/arch/powerpc/kexec/Makefile
@@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
 KCOV_INSTRUMENT_core_$(BITS).o := n
 UBSAN_SANITIZE_core_$(BITS).o := n
 KASAN_SANITIZE_core.o := n
-KASAN_SANITIZE_core_$(BITS) := n
+KASAN_SANITIZE_core_$(BITS).o := n
-- 
2.52.0

[PATCH 2/2] powerpc/kexec: Disable KASAN for VMX helpers used in MMU-off path

[Sourabh Jain]

The kexec sequence invokes enter_vmx_ops() and exit_vmx_ops() with the
MMU disabled. In this context, code must not rely on normal virtual
address translations or trigger page faults.

With KASAN enabled, these functions get instrumented and may access
shadow memory using regular address translation. When executed with
the MMU off, this can lead to page faults (bad_page_fault) from which
the kernel cannot recover in the kexec path, resulting in a hang.

Mark enter_vmx_ops() and exit_vmx_ops() with __no_sanitize_address to
avoid KASAN instrumentation and ensure kexec boots fine with KASAN
enabled.

Cc: Aditya Gupta <adityag@linux.ibm.com>
Cc: Daniel Axtens <dja@axtens.net>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
 arch/powerpc/lib/vmx-helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4..c01b2d856650 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,7 @@ int exit_vmx_usercopy(void)
 }
 EXPORT_SYMBOL(exit_vmx_usercopy);
 
-int enter_vmx_ops(void)
+int __no_sanitize_address enter_vmx_ops(void)
 {
 	if (in_interrupt())
 		return 0;
@@ -69,7 +69,7 @@ int enter_vmx_ops(void)
  * passed a pointer to the destination which we return as required by a
  * memcpy implementation.
  */
-void *exit_vmx_ops(void *dest)
+void __no_sanitize_address *exit_vmx_ops(void *dest)
 {
 	disable_kernel_altivec();
 	preempt_enable();
-- 
2.52.0

Re: [PATCH 2/2] powerpc/kexec: Disable KASAN for VMX helpers used in MMU-off path

[Ritesh Harjani]

Sourabh Jain <sourabhjain@linux.ibm.com> writes:

> The kexec sequence invokes enter_vmx_ops() and exit_vmx_ops() with the
> MMU disabled. In this context, code must not rely on normal virtual
> address translations or trigger page faults.
> With KASAN enabled, these functions get instrumented and may access
> shadow memory using regular address translation. When executed with
> the MMU off, this can lead to page faults (bad_page_fault) from which
> the kernel cannot recover in the kexec path, resulting in a hang.

Right, so with mmu off, kernel can't access KASAN shadow memory.

So, let me trace down the path a bit... you skipped an important detail
i.e. preempt_count() is always inline, and we play a few tricks in kexec
path to tell enter_vmx_ops() that we are in HARDIRQ mode.

default_machine_kexec(image)
    current_thread_info()->preempt_count = HARDIRQ_OFFSET

    kexec_sequence(..., copy_with_mmu_off = 1)
        if (copy_with_mmu_off) bl real_mode

        bl kexec_copy_flush(image)
            memcpy(ranges, image->segment, ...)

            copy_segments()
                copy_page(dest, addr)

                    bl enter_vmx_ops()
                        if (in_interrupt() == true) return 0 // preempt_count == HARDIRQ_OFFSET
                    beq .Lnonvmx_copy

>
> Mark enter_vmx_ops() and exit_vmx_ops() with __no_sanitize_address to
> avoid KASAN instrumentation and ensure kexec boots fine with KASAN
> enabled.
>

IIUC, preempt_count() is always inline, and since you are disabling kasan
instrumentation on enter_vmx_ops(), hence it just works for this reason.  
But you missed adding that detail here.

enter_vmx_ops()
    if (in_interrupt()) // return 0
           preempt_count() & ... | HARDIRQ_OFFSET   // preempt_count() is this is __always_inline 

static __always_inline int preempt_count(void)
{
	return READ_ONCE(current_thread_info()->preempt_count);
}

> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
>  arch/powerpc/lib/vmx-helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
> index 554b248002b4..c01b2d856650 100644
> --- a/arch/powerpc/lib/vmx-helper.c
> +++ b/arch/powerpc/lib/vmx-helper.c
> @@ -52,7 +52,7 @@ int exit_vmx_usercopy(void)
>  }
>  EXPORT_SYMBOL(exit_vmx_usercopy);
>  
> -int enter_vmx_ops(void)

In that case, should we should add a comment here saying:

/*
 * Can be called from kexec copy_page() path with MMU off. The kexec
 * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
 * Since in_interrupt() is always inline, __no_sanitize_address on this
 * function is sufficient to avoid KASAN shadow memory accesses in real
 * mode.
 */
> +int __no_sanitize_address enter_vmx_ops(void)
>  {
>  	if (in_interrupt())
>  		return 0;
> @@ -69,7 +69,7 @@ int enter_vmx_ops(void)
>   * passed a pointer to the destination which we return as required by a
>   * memcpy implementation.
>   */
> -void *exit_vmx_ops(void *dest)
> +void __no_sanitize_address *exit_vmx_ops(void *dest)

I am assuming since we never enter into VMX in kexec path, so kexec path
must not be calling exit_vmx_ops anyways? So do we need __no_sanitize_address here?

-ritesh


>  {
>  	disable_kernel_altivec();
>  	preempt_enable();
> -- 
> 2.52.0

Re: [PATCH 2/2] powerpc/kexec: Disable KASAN for VMX helpers used in MMU-off path

[Ritesh Harjani]

Ritesh Harjani (IBM) <ritesh.list@gmail.com> writes:

> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> The kexec sequence invokes enter_vmx_ops() and exit_vmx_ops() with the
>> MMU disabled. In this context, code must not rely on normal virtual
>> address translations or trigger page faults.
>> With KASAN enabled, these functions get instrumented and may access

You said "may access", so just curious that, do you see an issue always
with KASAN + Kexec or is it only with a specific configuration?

-ritesh

Re: [PATCH 2/2] powerpc/kexec: Disable KASAN for VMX helpers used in MMU-off path

[Sourabh Jain]

On 29/03/26 06:48, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> The kexec sequence invokes enter_vmx_ops() and exit_vmx_ops() with the
>> MMU disabled. In this context, code must not rely on normal virtual
>> address translations or trigger page faults.
>> With KASAN enabled, these functions get instrumented and may access
>> shadow memory using regular address translation. When executed with
>> the MMU off, this can lead to page faults (bad_page_fault) from which
>> the kernel cannot recover in the kexec path, resulting in a hang.
> Right, so with mmu off, kernel can't access KASAN shadow memory.
>
> So, let me trace down the path a bit... you skipped an important detail
> i.e. preempt_count() is always inline, and we play a few tricks in kexec
> path to tell enter_vmx_ops() that we are in HARDIRQ mode.
>
> default_machine_kexec(image)
>      current_thread_info()->preempt_count = HARDIRQ_OFFSET
>
>      kexec_sequence(..., copy_with_mmu_off = 1)
>          if (copy_with_mmu_off) bl real_mode
>
>          bl kexec_copy_flush(image)
>              memcpy(ranges, image->segment, ...)
>
>              copy_segments()
>                  copy_page(dest, addr)
>
>                      bl enter_vmx_ops()
>                          if (in_interrupt() == true) return 0 // preempt_count == HARDIRQ_OFFSET
>                      beq .Lnonvmx_copy

Yes since preempt_count for the current thread is set to HARDIRQ_OFFSET 
we return early from copy_page() -> copypage_power7 -> enter_vmx_ops() 
and call to exit_vmx_ops is skipped.
>
>> Mark enter_vmx_ops() and exit_vmx_ops() with __no_sanitize_address to
>> avoid KASAN instrumentation and ensure kexec boots fine with KASAN
>> enabled.
>>
> IIUC, preempt_count() is always inline, and since you are disabling kasan
> instrumentation on enter_vmx_ops(), hence it just works for this reason.
> But you missed adding that detail here.

Yeah it is worth adding that in commit message. I will add it in v2.

>
> enter_vmx_ops()
>      if (in_interrupt()) // return 0
>             preempt_count() & ... | HARDIRQ_OFFSET   // preempt_count() is this is __always_inline
>
> static __always_inline int preempt_count(void)
> {
> 	return READ_ONCE(current_thread_info()->preempt_count);
> }
>
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: Daniel Axtens <dja@axtens.net>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
>> Cc: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>>   arch/powerpc/lib/vmx-helper.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
>> index 554b248002b4..c01b2d856650 100644
>> --- a/arch/powerpc/lib/vmx-helper.c
>> +++ b/arch/powerpc/lib/vmx-helper.c
>> @@ -52,7 +52,7 @@ int exit_vmx_usercopy(void)
>>   }
>>   EXPORT_SYMBOL(exit_vmx_usercopy);
>>   
>> -int enter_vmx_ops(void)
> In that case, should we should add a comment here saying:
>
> /*
>   * Can be called from kexec copy_page() path with MMU off. The kexec
>   * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
>   * Since in_interrupt() is always inline, __no_sanitize_address on this
>   * function is sufficient to avoid KASAN shadow memory accesses in real
>   * mode.
>   */

Thanks for the write up, I will add it in v2.

>> +int __no_sanitize_address enter_vmx_ops(void)
>>   {
>>   	if (in_interrupt())
>>   		return 0;
>> @@ -69,7 +69,7 @@ int enter_vmx_ops(void)
>>    * passed a pointer to the destination which we return as required by a
>>    * memcpy implementation.
>>    */
>> -void *exit_vmx_ops(void *dest)
>> +void __no_sanitize_address *exit_vmx_ops(void *dest)
> I am assuming since we never enter into VMX in kexec path, so kexec path
> must not be calling exit_vmx_ops anyways? So do we need __no_sanitize_address here?

Agree in copypage_power7() we jump to  .Lnonvmx_copy label and do
not call exit_vmx_ops. I will remove __no_sanitize_address from 
exit_vmx_ops().

Thanks for the detailed review Ritesh.

- Soruabh Jain

Re: [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Mahesh J Salgaonkar]

On 2026-03-21 11:01:17 Sat, Sourabh Jain wrote:
> KASAN instrumentation is intended to be disabled for the kexec core
> code, but the existing Makefile entry misses the object suffix. As a
> result, the flag is not applied correctly to core_$(BITS).o.
> 
> So when KASAN is enabled, kexec_copy_flush and copy_segments in
> kexec/core_64.c are instrumented, which can result in accesses to
> shadow memory via normal address translation paths. Since these run
> with the MMU disabled, such accesses may trigger page faults
> (bad_page_fault) that cannot be handled in the kdump path, ultimately
> causing a hang and preventing the kdump kernel from booting. The same
> is true for kexec as well, since the same functions are used there.
> 
> Update the entry to include the “.o” suffix so that KASAN
> instrumentation is properly disabled for this object file.
> 
> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
> Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
>  arch/powerpc/kexec/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
> index 470eb0453e17..ec7a0eed75dc 100644
> --- a/arch/powerpc/kexec/Makefile
> +++ b/arch/powerpc/kexec/Makefile
> @@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
>  KCOV_INSTRUMENT_core_$(BITS).o := n
>  UBSAN_SANITIZE_core_$(BITS).o := n
>  KASAN_SANITIZE_core.o := n
> -KASAN_SANITIZE_core_$(BITS) := n
> +KASAN_SANITIZE_core_$(BITS).o := n

Nice catch. Thakns for fixing.

Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>

Thanks,
-Mahesh.

-- 
Mahesh J Salgaonkar

Re: [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Sourabh Jain]

On 23/03/26 11:41, Mahesh J Salgaonkar wrote:
> On 2026-03-21 11:01:17 Sat, Sourabh Jain wrote:
>> KASAN instrumentation is intended to be disabled for the kexec core
>> code, but the existing Makefile entry misses the object suffix. As a
>> result, the flag is not applied correctly to core_$(BITS).o.
>>
>> So when KASAN is enabled, kexec_copy_flush and copy_segments in
>> kexec/core_64.c are instrumented, which can result in accesses to
>> shadow memory via normal address translation paths. Since these run
>> with the MMU disabled, such accesses may trigger page faults
>> (bad_page_fault) that cannot be handled in the kdump path, ultimately
>> causing a hang and preventing the kdump kernel from booting. The same
>> is true for kexec as well, since the same functions are used there.
>>
>> Update the entry to include the “.o” suffix so that KASAN
>> instrumentation is properly disabled for this object file.
>>
>> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
>> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
>> Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: Daniel Axtens <dja@axtens.net>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>>   arch/powerpc/kexec/Makefile | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
>> index 470eb0453e17..ec7a0eed75dc 100644
>> --- a/arch/powerpc/kexec/Makefile
>> +++ b/arch/powerpc/kexec/Makefile
>> @@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
>>   KCOV_INSTRUMENT_core_$(BITS).o := n
>>   UBSAN_SANITIZE_core_$(BITS).o := n
>>   KASAN_SANITIZE_core.o := n
>> -KASAN_SANITIZE_core_$(BITS) := n
>> +KASAN_SANITIZE_core_$(BITS).o := n
> Nice catch. Thakns for fixing.
>
> Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Thanks for the Ack Mahesh.

- Sourabh Jain

Re: [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Venkat Rao Bagalkote]

On 21/03/26 11:01 am, Sourabh Jain wrote:
> KASAN instrumentation is intended to be disabled for the kexec core
> code, but the existing Makefile entry misses the object suffix. As a
> result, the flag is not applied correctly to core_$(BITS).o.
>
> So when KASAN is enabled, kexec_copy_flush and copy_segments in
> kexec/core_64.c are instrumented, which can result in accesses to
> shadow memory via normal address translation paths. Since these run
> with the MMU disabled, such accesses may trigger page faults
> (bad_page_fault) that cannot be handled in the kdump path, ultimately
> causing a hang and preventing the kdump kernel from booting. The same
> is true for kexec as well, since the same functions are used there.
>
> Update the entry to include the “.o” suffix so that KASAN
> instrumentation is properly disabled for this object file.
>
> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
> Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Cc: Aditya Gupta <adityag@linux.ibm.com>
> Cc: Daniel Axtens <dja@axtens.net>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---


This patch fixes the reported issue. Please add below tag.


Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>


Regards,

Venkat.


>   arch/powerpc/kexec/Makefile | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
> index 470eb0453e17..ec7a0eed75dc 100644
> --- a/arch/powerpc/kexec/Makefile
> +++ b/arch/powerpc/kexec/Makefile
> @@ -16,4 +16,4 @@ GCOV_PROFILE_core_$(BITS).o := n
>   KCOV_INSTRUMENT_core_$(BITS).o := n
>   UBSAN_SANITIZE_core_$(BITS).o := n
>   KASAN_SANITIZE_core.o := n
> -KASAN_SANITIZE_core_$(BITS) := n
> +KASAN_SANITIZE_core_$(BITS).o := n

Re: [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Ritesh Harjani]

Sourabh Jain <sourabhjain@linux.ibm.com> writes:

> KASAN instrumentation is intended to be disabled for the kexec core
> code, but the existing Makefile entry misses the object suffix. As a
> result, the flag is not applied correctly to core_$(BITS).o.
>
> So when KASAN is enabled, kexec_copy_flush and copy_segments in
> kexec/core_64.c are instrumented, which can result in accesses to
> shadow memory via normal address translation paths. Since these run
> with the MMU disabled, such accesses may trigger page faults
> (bad_page_fault) that cannot be handled in the kdump path, ultimately
> causing a hang and preventing the kdump kernel from booting. The same
> is true for kexec as well, since the same functions are used there.
>
> Update the entry to include the “.o” suffix so that KASAN
> instrumentation is properly disabled for this object file.
>
> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/

Nice catch. Indeed seems to be missed in the Fixes patch.

I think you might want to Cc: stable too, so that it is auto backported
to previous stable kernel releases too. The Fixes patch was added in
v5.19 kernel, maybe we weren't testing KASAN + Kdump, but it's worth
backporting to all stable kernel releases, IMO.

LGTM, please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

Re: [PATCH 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o

[Sourabh Jain]

On 29/03/26 07:26, Ritesh Harjani (IBM) wrote:
> Sourabh Jain <sourabhjain@linux.ibm.com> writes:
>
>> KASAN instrumentation is intended to be disabled for the kexec core
>> code, but the existing Makefile entry misses the object suffix. As a
>> result, the flag is not applied correctly to core_$(BITS).o.
>>
>> So when KASAN is enabled, kexec_copy_flush and copy_segments in
>> kexec/core_64.c are instrumented, which can result in accesses to
>> shadow memory via normal address translation paths. Since these run
>> with the MMU disabled, such accesses may trigger page faults
>> (bad_page_fault) that cannot be handled in the kdump path, ultimately
>> causing a hang and preventing the kdump kernel from booting. The same
>> is true for kexec as well, since the same functions are used there.
>>
>> Update the entry to include the “.o” suffix so that KASAN
>> instrumentation is properly disabled for this object file.
>>
>> Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address sanitization in kexec paths")
>> Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
>> Closes: https://lore.kernel.org/all/1dee8891-8bcc-46b4-93f3-fc3a774abd5b@linux.ibm.com/
> Nice catch. Indeed seems to be missed in the Fixes patch.
>
> I think you might want to Cc: stable too, so that it is auto backported
> to previous stable kernel releases too. The Fixes patch was added in
> v5.19 kernel, maybe we weren't testing KASAN + Kdump, but it's worth
> backporting to all stable kernel releases, IMO.

Yes, it is worth backporting this to the stable trees. I will update it 
in v2.

>
> LGTM, please feel free to add:
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>

Thanks for the review Ritesh.

- Sourabh Jain