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: <CADyTPEx=Y5KxYRV0JXgeH6njJMObTOFpAc4wmha0uUfO8yQfxQ@mail.gmail.com>
Date:   Mon, 27 Jul 2020 12:26:35 -0400
From:   Nick Bowler <nbowler@...conx.ca>
To:     Al Viro <viro@...iv.linux.org.uk>
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 2020-07-27, Al Viro <viro@...iv.linux.org.uk> wrote:
> 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?

Seems so; with commit 547ce4cfb34c reverted on top of 5.8-rc6 there is
no such error in the strace output.  This particular syscall seems
to be succeeding:

  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) = 512

Cheers,
  Nick