cryptsetup tcryptOpen doesn't work anymore

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1558079

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Exact same problem here. cryptsetup with tcrypt volume stopped working since update to 3.19.0-56. (-51was fine).

Seems the reporter did not not run apport-collect. Should I open another bug then?

Booted up previous version, 3.19.0-51 and I confirm cryptsetup works fine with tcrypt volume. So the bug has been introduced in 3.19.0-56 it seems.
Can always open volume with other tools, like truecrypt. So the problem is not in the volume either.

Any info I could provide to help?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.5 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/

I tried the latest kernel (4.5.0-040500-generic) in a VM, and cryptsetup does open fine a truecrypt disk.

With Ubuntu 14.04 and linux-image-3.13.0-83 it is caused by a kernel<->userland breakage. See:
https://lkml.org/lkml/2015/12/29/383
It is caused by [crypto: af_alg - Disallow bind/setkey/... after accept(2)] added to 3.13.0-80.124 with [ Upstream Kernel Changes ].

I've patched cryptsetup-1.6.1 to handle it. See attached patch.

The cryptsetup bundled with Ubuntu 14.04 tries to change the socket after accepting it while the newer kernel doesn't allow changes after accepting the connection.

Se6 seems using a newer Ubuntu version, so maybe it's a different cause there. Or maybe the newer 4.5 kernel reverts those upstream patches!?

The attachment "do not alter the cryptd-socket after accepting it" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Status changed to 'Confirmed' because the bug affects multiple users.

I also received the error message, but with 3.19.0-58-generic. I'm unable to revert back to 3.19.0-51 because some of drivers don't work with it anymore.
 Required kernel crypto interface not available.
 Ensure you have algif_skcipher kernel module loaded.

Let me know if there are are logs I can provide.

No further logs are needed, the cause and several solution are known.

The error is caused by the fact that newer Kernels do not allow to modify the cryptographic interface "kernel<->userspace" via bind/setkey/... after accept(2) has been called. But the old cryptsetup in trusty tahr is doing definitely that: calling accept(2) first and then setkey to the file descriptor.

There are various possible solutions to the problem.

The simple one:

I've created a ppa. Use cryptsetup from there:
https://launchpad.net/~michael-heide/+archive/ubuntu/test2

(btw: I've created some packages in the past but these were unsigned and I've incremented the version number a little awkward. So I created some new packages with cleaner versioning for the ppa)

Other possible solutions:

- Manually patching cryptsetup. The patch I've added (see above) changes the order of accept/setkey.

- Using some newer cryptsetup - the one in ubuntu trusty (14.04) is outdated - newer versions from newer ubuntu or debian releases (using compiled .deb) should work.

- Manually Reverting back the corresponding patch to the Kernel: [crypto: af_alg - Disallow bind/setkey/... after accept(2)]
  * added to [linux (3.19.0-52.58) vivid; urgency=low] with [ Upstream Kernel Changes ]
  * added to [linux (3.13.0-80.124) trusty; urgency=low] with [ Upstream Kernel Changes ]
  (i.e. manually unpatching those patches within the linux sources)

- installing some older kernel versions <3.19.0-52.58 / <3.13.0-80.124

- wait for the original ubuntu cryptsetup maintainer to fix his package

New 3.19 and 3.13 upstream stable kernel should have patches that should allow old cryptsetup to run again, just backport these patches on top of accept fixes (instead of revert).

Thankfully linux-image-3.19.0-59 was part of the updates today, I am able to access my volumes now. Thanks for the other advice, I'll keep it handy.

jduck on irc reports that he needs to use a locally-built cryptsetup package with https://launchpadlibrarian.net/249460666/10_no_setkey_after_accept.patch included for it to function on 3.13.0-91-generic.

Foundations team, is there a chance for an SRU for this?

Thanks

I'm on 14.04 (Trusty) and am still experiencing the same issue. I took the patch from #7 and it fixes the issue for me. Unfortunately, without you guys rolling updated libcryptsetup4 packages, I keep getting rolled back to an unfixed version on every update. Subsequent kernel releases (3.13.0-80 and later) do not seem to fix the problem for me. I'm currently experiencing the issue with 3.10.0-91-generic.

What is the source of the referenced patch?

ok I see that appears to be the same patch as in comment #7. Michael, has this 10_no_setkey_after_accept.patch patch been accepted upstream?

AFAIK there was no need for my patch to be included because the trusty kernel maintainer reverted the upstream kernel.org changes to the kernel which caused this bad behavior.

It seems like newer trusty kernels are affected again. (I'm not running trusty with tcrypt-devices anymore, to test this by my own.)

Like in the past it's possible either to revert those changes to the kernel (like referenced in #12) or patch cryptsetup (like with #7). You can ask either the Ubuntu cryptsetup or kernel maintainers for fixes. In past AFAIR it got fixed inside the kernel package but I'd prefer to patch cryptsetup, if there's any good reason for kernel.org guys to add those changes to their old-stable kernel releases... *my2ct*

btw: the patch is not needed with current upstream kernels or upstream cryptsetup, since newer cryptsetup versions are not affected. It's the combination of newer kernels (or older kernels with backported security patches) with older cryptsetup which is problematic in case of Ubuntu trusty.