LWN: Comments on "Two new stable kernels"

Two new stable kernels

job — Thu, 25 Feb 2016 11:41:59 +0000

Apparently the 4.4.2 and 4.3.6 kernels contain backwards compatibility fixes so cryptsetup 1.6 doesn't break. These fell out along the way when backporting since they were dependent on other changes in the crypto code, but we'll probably see them in a future update.

Two new stable kernels

hmh — Sun, 21 Feb 2016 11:54:57 +0000

It will render cryptsetup useless (not just inside the initramfs), and it is on a few other stable kernels as well already (such as 3.18.27)...

If this change is really important (for security/stability/whatever), it looks like it will need a two-step approach. For example, the kernel might hide it behind a kconfig option defaulting to disabled, which distros would enable after they fixed userspace.

Argh.

Two new stable kernels

alonz — Sat, 20 Feb 2016 16:33:22 +0000

Interesting… the code in cryptsetup indeed breaks the assumptions enforced by this commit (it closed the "tfmfd" before the "opfd", while the code always assumed the opposite and now enforces it). So it has always been "buggy but working" – which is no excuse for breaking userspace.

I wonder how this one will play out.

Two new stable kernels

hmh — Sat, 20 Feb 2016 13:32:14 +0000

Uh, beware any stable kernels that contains a backport of:
commit c840ac6af3f8713a71b4d2363419145760bd6044: crypto: af_alg - Disallow bind/setkey/... after accept(2)

It seems to not always work out with encrypted rootfs userland:
https://bugzilla.kernel.org/show_bug.cgi?id=112631

So far, reported only in 4.1.18, but since said commit IS present in the v4.3.6 and v3.10.97 releases, ensure you have a fallback kernel+initramfs.