Re: [PATCH] kexec: Select ima_get/free_kexec_buffer() with CONFIG_HAVE_IMA_KEXEC(_OF)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ima: off-by-one in ima_validate_range bypasses memory boundary check
--

commit 7ddca2cd41824acc187deeda05f385f27ac90508
Author: Roberto Sassu <roberto.sassu@huawei.com>

kexec: Select ima_get/free_kexec_buffer() with CONFIG_HAVE_IMA_KEXEC(_OF)

This commit introduces CONFIG_HAVE_IMA_KEXEC_OF and selects it for
architectures using the device tree implementation for IMA kexec buffers.
It also modifies x86 to use its own setup_data-based implementation
regardless of CONFIG_OF_FLATTREE.

> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index cda6adb9f69c4..bc17e353c0992 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
[ ... ]
> @@ -421,7 +421,7 @@ static void __init add_early_ima_buffer(u64 phys_addr)
>  #endif
>  }
>  
> -#if defined(CONFIG_HAVE_IMA_KEXEC) && !defined(CONFIG_OF_FLATTREE)
> +#ifdef CONFIG_HAVE_IMA_KEXEC
>  int __init ima_free_kexec_buffer(void)
>  {

[Severity: High]
Does enabling this on x86 expose an off-by-one regression in how IMA validates
the memory range?

In security/integrity/ima/ima_kexec.c:ima_validate_range(), the end_pfn is
calculated inclusively:

    end_phys = phys + size - 1;
    end_pfn = PHYS_PFN(end_phys);

However, on x86, this inclusive end_pfn is passed to pfn_range_is_mapped():

    if (!pfn_range_is_mapped(start_pfn, end_pfn))

Looking at arch/x86/mm/init.c:pfn_range_is_mapped(), it expects an exclusive
end_pfn boundary, checking if the region is within pfn_mapped[i]:

    if ((start_pfn >= pfn_mapped[i].start) &&
        (end_pfn <= pfn_mapped[i].end))

Because ima_validate_range() passes an inclusive PFN, the validated range is
effectively one page smaller than the actual buffer. If the actual buffer
extends exactly one page beyond the valid mapped memory, could
pfn_range_is_mapped() incorrectly return true?

Would the subsequent direct map access via __va(ima_kexec_buffer_phys) up
to size hit the unmapped page, resulting in an out-of-bounds access
during boot?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261014150005.138309-1-roberto.sassu@huaweicloud.com?part=1