[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m2h740zz1i.fsf@gmail.com>
Date: Fri, 01 Jul 2022 22:22:51 +0800
From: Schspa Shi <schspa@...il.com>
To: Marc Zyngier <maz@...nel.org>
Cc: james.morse@....com, alexandru.elisei@....com,
suzuki.poulose@....com, catalin.marinas@....com, will@...nel.org,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix 64 bit mmio handle
Marc Zyngier <maz@...nel.org> writes:
>>
>> I have running some static code analysis software upon Kernel
>> code.
>> Seeing there is possible overflow.
>>
>> maks << 1U << ((len * 8) -1);
>>
>> The AI don't know, len is only the value of 1, 2, 4, and make
>> this
>> a warnings
>>
>> I tring to analysis this, but didn't realize the real scenario
>> of
>> sign extension, and finally sent this problematic patch.
>>
>> I do see some uninitialized memory reads (the values are not
>> used
>> in the end, just as temporary space for API execution),
>> do we need to fix these?
>
> You need to be more descriptive here. What uninitialised reads?
> In
> general, pointing at the code and providing a full description
> of what
> you think is incorrect would really help...
>
> M.
One example is
int vgic_v3_has_attr_regs(struct kvm_device *dev, struct
kvm_device_attr *attr)
{
...
case KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS: {
u64 reg, id;
id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
}
}
The funcion vgic_v3_has_cpu_sysregs_attr will read reg's value to
params without initialization. There should have no problems,
because the register value never used.
--
BRs
Schspa Shi
Powered by blists - more mailing lists