linux-kernel - Re: PROBLEM: cryptsetup fails to unlock drive in 5.8-rc6 (regression)

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: <20200727160554.GG794331@ZenIV.linux.org.uk>
Date:   Mon, 27 Jul 2020 17:05:54 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Nick Bowler <nbowler@...conx.ca>
Cc:     linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: PROBLEM: cryptsetup fails to unlock drive in 5.8-rc6 (regression)

On Thu, Jul 23, 2020 at 11:51:01AM -0400, Nick Bowler wrote:
> Hi,
> 
> After installing Linux 5.8-rc6, it seems cryptsetup can no longer
> open LUKS volumes.  Regardless of the entered passphrase (correct
> or otherwise), the result is a very unhelpful "Keyslot open failed."
> message.
> 
> On the kernels which fail, I also noticed that the cryptsetup
> benchmark command appears to not be able to determine that any
> ciphers are available (output at end of message), possibly for
> the same reason.
> 
> Bisected to the following commit, which suggests a problem specific
> to compat userspace (this is amd64 kernel).  I tested both ia32 and
> x32 userspace to confirm the problem.  Reverting this commit on top
> of 5.8-rc6 resolves the issue.
> 
> Looking at strace output the failing syscall appears to be:
> 
>   sendmsg(8, {msg_name=NULL, msg_namelen=0, 
> 	     msg_iov=[{iov_base=..., iov_len=512}], msg_iovlen=1,
> 	     msg_control=[{cmsg_len=16, cmsg_level=SOL_ALG,
> 	     cmsg_type=0x3}, {cmsg_len=32, cmsg_level=SOL_ALG,
> 	     cmsg_type=0x2}], msg_controllen=48, msg_flags=0}, 0)
> 	     = -1 EINVAL (Invalid argument)

Huh?  Just in case - could you verify that on the kernel with that
commit reverted the same sendmsg() succeeds?