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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241025100516.7541-B-hca@linux.ibm.com>
Date: Fri, 25 Oct 2024 12:05:16 +0200
From: Heiko Carstens <hca@...ux.ibm.com>
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, Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: arch/s390/mm/fault.c:566 do_secure_storage_access() warn:
 inconsistent returns '&mm->mmap_lock'.

On Fri, Oct 25, 2024 at 10:35:47AM +0300, Dan Carpenter wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   c2ee9f594da826bea183ed14f2cc029c719bf4da
> commit: 7c194d84a9ce662426b2ecb59da54bb80c6b1d91 s390/mm,fault: remove VM_FAULT_BADMAP and VM_FAULT_BADACCESS
> config: s390-randconfig-r072-20241024 (https://download.01.org/0day-ci/archive/20241025/202410250552.XsMLl1sx-lkp@intel.com/config)
> compiler: s390-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/202410250552.XsMLl1sx-lkp@intel.com/
> 
> smatch warnings:
> arch/s390/mm/fault.c:566 do_secure_storage_access() warn: inconsistent returns '&mm->mmap_lock'.
...
> 084ea4d611a3d0 Vasily Gorbik     2020-01-21  540  	case USER_FAULT:
> 084ea4d611a3d0 Vasily Gorbik     2020-01-21  541  		mm = current->mm;
> d8ed45c5dcd455 Michel Lespinasse 2020-06-08  542  		mmap_read_lock(mm);
> 084ea4d611a3d0 Vasily Gorbik     2020-01-21  543  		vma = find_vma(mm, addr);
> 7c194d84a9ce66 Heiko Carstens    2023-10-12  544  		if (!vma)
> 7c194d84a9ce66 Heiko Carstens    2023-10-12  545  			return handle_fault_error(regs, SEGV_MAPERR);
> 
> mmap_read_unlock() before returning?

This is a false positive: handle_fault_error() contains an unconditional
mmap_read_unlock() call. I would wish the __acquires() and __releases()
annotations would work better (or maybe I just can't figure out to use them
properly.

In any case: do_secure_storage_access() will very likely go away with the next
merge window and its functionality will be implemented differently.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ