VERSION: Release runc v1.5.1

[rata]

Let's release 1.5.1. The first one affects ubuntu (a very specific base, as 20.04 is EOL unless you pay) and the second bug fix is an issue for Kubernetes CI, in k8s we can't upgrade to runc 1.5.

I set the date to today. Let's remember to change the date if we don't cut it today.

I put the changelog here as plain text, so the issue/PR links work and are easy to verify :)

I omitted on purpose the CI fixes, I don't think it's very relevant for users. It seems like a quite internal thing to me. We didn't stopped testing in any major distro nor that, just fix some race in tests.

---

[1.5.1] - 2026-07-10

El lujo es vulgaridad, dijo, y me conquistó.

Fixed

• Fix starting containers on Ubuntu Focal (20.04) with a 5.4 kernel. That kernel
  has a downstream patch to forbid tmpfs mounts with the option nr_inodes=1.
  (Recent update to moby-runc causes execution failures on Ubuntu:Focal (20.04) #5348, libct: Enforce nr_inodes=2 to fix Focal mount errors #5353, [release-1.5 backport] libct: Enforce nr_inodes=2 to fix Focal mount errors #5355)
• Properly handle EINVAL for seccomp SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV
  when trying to rewrite the filter that might not need it. Allegedly, this
  happens only when you compile runc with a libseccomp >= 2.6.0 and then run it
  with an < 2.6.0 libseccomp. (seccomp: ignore unsupported wait-kill flag probe #5347, [release-1.5 backport] seccomp: ignore unsupported wait-kill flag probe #5354)

[thaJeztah]

For the EINVAL one (missed that one I think); I would've somewhat preferred the error-type check to be nested;

if waitKill, err := filter.GetWaitKill(); err != nil {
	if !errors.Is(err, unix.EINVAL) {
		return 0, false, fmt.Errorf("unable to fetch SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV bit: %w", err)
	}
} else if waitKill {
	flags |= uint(C.C_FILTER_FLAG_WAIT_KILLABLE_RECV)
}

Current approach is correct, but for these, i've been bitten at times where the "else" would be called without proper checks.

[thaJeztah]

Basically currently we're trusting the waitKill output from a function that produced an error (EINVAL); I'm usually in the camp "if it produced an error, then none of the other results should be consumed"

[thaJeztah]

LGTM

[rata]

@thaJeztah heh, I've asked to change it to how it is now :-D. But it's a good point, wanna open a PR about it? I don't think it's worth a backport, though :)

[thaJeztah]

heh, I've asked to change it to how it is now :-D.

Yeah, these are tricky; current one looks cleaner for sure! And probably we'd never get a "true" if it returns an error, but it's always a tricky trade-off; "most correct" is "don't consume output if there's an error" in most cases.

Definitely not needed for a backport; I may open a PR if I have time.

[lifubang]

but for these, i've been bitten at times where the "else" would be called without proper checks.

I'm usually in the camp "if it produced an error, then none of the other results should be consumed"

Thanks for sharing your scars from the battlefield!
We'll go with the nested version to stay safe. Appreciate getting this experience for free!

There is a PR link error.

[lifubang]

It should be (#5348, #5358, #5359), it's not necessary to link #5353 and #5355 because they have been reverted.

[lifubang]

Definitely not needed for a backport; I may open a PR if I have time.

Opened #5369