Re: [PATCH v4 16/16] riscv: hwprobe: Introduce rva23u64 base behavior

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] In hwprobe_get_cpus(), a stack-allocated cpumask_t is not fully initialized when cpusetsize is smaller than cpumask_size(), causing unpredictable logic failures and a kernel memory info leak.
--

commit 23f172deab06c9baa8c73280f488bc8016e4c474
Author: Guodong Xu <docular.xu@gmail.com>

riscv: hwprobe: Introduce rva23u64 base behavior

Provide a hwprobe base-behavior bit so userspace can check RVA23U64
support in one call. Most software treats RVA23U64 as a new base anyway, so
expose it directly.

> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index 3e80e5551ae0d..3f66f2e99d41a 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c

[ ... ]

> @@ -308,14 +319,12 @@ static void hwprobe_one_pair(struct riscv_hwprobe *pair,
>  	case RISCV_HWPROBE_KEY_MIMPID:
>  		hwprobe_arch_id(pair, cpus);
>  		break;
> -	/*
> -	 * The kernel already assumes that the base single-letter ISA
> -	 * extensions are supported on all harts, and only supports the
> -	 * IMA base, so just cheat a bit here and tell that to
> -	 * userspace.
> -	 */
>  	case RISCV_HWPROBE_KEY_BASE_BEHAVIOR:
> -		pair->value = RISCV_HWPROBE_BASE_BEHAVIOR_IMA;
> +		pair->value = 0;
> +		if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_IMA))
> +			pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_IMA;
> +		if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_RVA23U64))
> +			pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64;
>  		break;

[Severity: High]
This is a pre-existing issue, but could this code be used to infer
uninitialized kernel stack memory?

In hwprobe_get_cpus(), a stack-allocated cpumask_t is not fully initialized
when cpusetsize is smaller than cpumask_size():

arch/riscv/kernel/sys_hwprobe.c:hwprobe_get_cpus() {
    cpumask_t cpus, one_cpu;
    ...
    ret = copy_from_user(&cpus, cpus_user, cpusetsize);
    if (ret)
        return -EFAULT;

    if (cpumask_empty(&cpus))
        cpumask_copy(&cpus, cpu_online_mask);
    ...
}

If the user passes an empty mask, they expect the kernel to treat it as
cpu_online_mask. However, if the stack garbage contains non-zero bits,
cpumask_empty(&cpus) evaluates to false.

The kernel will skip substituting cpu_online_mask and instead process the
uninitialized bits.

Uninitialized bits corresponding to online CPUs will remain set after
cpumask_and(&cpus, &cpus, cpu_online_mask), and the kernel will iterate over
these garbage CPUs via for_each_cpu(), repeatedly calling hwprobe_one_pair():

arch/riscv/kernel/sys_hwprobe.c:hwprobe_get_cpus() {
    ...
    for_each_cpu(cpu, &cpus) {
        cpumask_set_cpu(cpu, &one_cpu);

        hwprobe_one_pair(&tmp, &one_cpu);

        if (!riscv_hwprobe_pair_cmp(&tmp, &pair))
            cpumask_clear_cpu(cpu, &cpus);

        cpumask_clear_cpu(cpu, &one_cpu);
    }
    ...
}

Does this execution time difference act as a timing side-channel, allowing
an attacker to infer the contents of uninitialized kernel stack memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com?part=16