On Tue, Feb 11, 2025 at 11:31:28AM +0100, Clément Léger wrote:
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).
Awesome. Thanks for looking into it.
Clément