On 11/02/2025 06:43, Deepak Gupta wrote:
>> +static int kvm_sbi_fwft_get(struct kvm_vcpu *vcpu, unsigned long
>> feature,
>> + unsigned long *value)
>> +{
>> + int ret;
>> + struct kvm_sbi_fwft_config *conf;
>> +
>> + ret = kvm_fwft_get_feature(vcpu, feature, &conf);
>> + if (ret)
>> + return ret;
>> +
>> + return conf->feature->get(vcpu, conf, value);
>> +}
>> +
>> +static int kvm_sbi_ext_fwft_handler(struct kvm_vcpu *vcpu, struct
>> kvm_run *run,
>> + struct kvm_vcpu_sbi_return *retdata)
>> +{
>> + int ret = 0;
>> + struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
>> + unsigned long funcid = cp->a6;
>> +
>> + switch (funcid) {
>> + case SBI_EXT_FWFT_SET:
>> + ret = kvm_sbi_fwft_set(vcpu, cp->a0, cp->a1, cp->a2);
>> + break;
>> + case SBI_EXT_FWFT_GET:
>> + ret = kvm_sbi_fwft_get(vcpu, cp->a0, &retdata->out_val);
>> + break;
>> + default:
>> + ret = SBI_ERR_NOT_SUPPORTED;
>> + break;
>> + }
>> +
>> + retdata->err_val = ret;
>> +
>> + return 0;
>> +}
>> +
>> +static int kvm_sbi_ext_fwft_init(struct kvm_vcpu *vcpu)
>> +{
>> + struct kvm_sbi_fwft *fwft = vcpu_to_fwft(vcpu);
>> + const struct kvm_sbi_fwft_feature *feature;
>> + struct kvm_sbi_fwft_config *conf;
>> + int i;
>> +
>> + fwft->configs = kcalloc(ARRAY_SIZE(features), sizeof(struct
>> kvm_sbi_fwft_config),
>> + GFP_KERNEL);
> nit:
>
> I understand that in next patch you grow the static array`features`. But
> in this patch
> `ARRAY_SIZE(features)` evaluates to 0, thus kcalloc will be returning a
> pointer
> to some slab block (IIRC, kcalloc will not return NULL if size
> eventually evals to 0)
>
> This probably won't result in some bad stuff. But still there is a
> pointer in
> fwft->configs which is pointing to some random stuff if `features` turns
> out to be
> empty.
>
> Let me know if I got that right or missing something.
So I actually searched into the kmalloc code to see what hapopens with a
zero size allocation and it actually return ZERO_SIZE_PTR:
/*
* ZERO_SIZE_PTR will be returned for zero sized kmalloc requests.
*
* Dereferencing ZERO_SIZE_PTR will lead to a distinct access fault.
*
* ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL
can.
* Both make kfree a no-op.
*/
Which seems like it's not really random and will fault if accessed. I
think that's enough for that commit (which will be bisectable if needed
then).
Clément
