lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <864j533s88.wl-maz@kernel.org>
Date: Wed, 23 Oct 2024 13:43:03 +0100
From: Marc Zyngier <maz@...nel.org>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: oe-kbuild@...ts.linux.dev,
	lkp@...el.com,
	oe-kbuild-all@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: arch/arm64/kvm/at.c:71 at_s1e1p_fast() error: uninitialized symbol 'fail'.

On Mon, 21 Oct 2024 08:29:41 +0100,
Dan Carpenter <dan.carpenter@...aro.org> wrote:
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   3d5ad2d4eca337e80f38df77de89614aa5aaceb9
> commit: be0135bde1df5e80cffacd2ed6f952e6d38d6f71 KVM: arm64: nv: Add basic emulation of AT S1E1{R,W}P
> date:   7 weeks ago
> config: arm64-randconfig-r071-20241015 (https://download.01.org/0day-ci/archive/20241020/202410200209.bAXXL58Q-lkp@intel.com/config)
> compiler: aarch64-linux-gcc (GCC) 14.1.0
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@...el.com>
> | Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> | Closes: https://lore.kernel.org/r/202410200209.bAXXL58Q-lkp@intel.com/
> 
> smatch warnings:
> arch/arm64/kvm/at.c:71 at_s1e1p_fast() error: uninitialized symbol 'fail'.
> 
> vim +/fail +71 arch/arm64/kvm/at.c
> 
> be0135bde1df5e Marc Zyngier 2024-07-14  52  static bool at_s1e1p_fast(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
> be0135bde1df5e Marc Zyngier 2024-07-14  53  {
> be0135bde1df5e Marc Zyngier 2024-07-14  54  	u64 host_pan;
> be0135bde1df5e Marc Zyngier 2024-07-14  55  	bool fail;
> be0135bde1df5e Marc Zyngier 2024-07-14  56  
> be0135bde1df5e Marc Zyngier 2024-07-14  57  	host_pan = read_sysreg_s(SYS_PSTATE_PAN);
> be0135bde1df5e Marc Zyngier 2024-07-14  58  	write_sysreg_s(*vcpu_cpsr(vcpu) & PSTATE_PAN, SYS_PSTATE_PAN);
> be0135bde1df5e Marc Zyngier 2024-07-14  59  
> be0135bde1df5e Marc Zyngier 2024-07-14  60  	switch (op) {
> be0135bde1df5e Marc Zyngier 2024-07-14  61  	case OP_AT_S1E1RP:
> be0135bde1df5e Marc Zyngier 2024-07-14  62  		fail = __kvm_at(OP_AT_S1E1RP, vaddr);
> be0135bde1df5e Marc Zyngier 2024-07-14  63  		break;
> be0135bde1df5e Marc Zyngier 2024-07-14  64  	case OP_AT_S1E1WP:
> be0135bde1df5e Marc Zyngier 2024-07-14  65  		fail = __kvm_at(OP_AT_S1E1WP, vaddr);
> be0135bde1df5e Marc Zyngier 2024-07-14  66  		break;
> 
> default case?

There is no bug here, as evidenced by the *only* caller of this
function (__kvm_at_s1e01_fast()):

	switch (op) {
	case OP_AT_S1E1RP:
	case OP_AT_S1E1WP:
		fail = at_s1e1p_fast(vcpu, op, vaddr);
		break;

So 'op' can only be one of these two values, and at_s1e1p_fast()
always initialises 'fail'.

I guess this is a case of smatch not seeing beyond function scope.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ