Repository navigation
test: check that per-task restrictions survive exec - #1652
Merged
Merged
Conversation
Per-task io_uring restrictions must keep applying to rings created after
exec, also when the task used io_uring before exec. Kernels without
commit bc0e8faf90e7 ("io_uring: preserve task restrictions across exec")
free the restrictions with the task context on exec in that case, so the
new image can create unrestricted rings. task-restrict.t doesn't cover
exec, so it passes on those kernels.
Restrict a child to NOP, optionally use a ring, re-exec the test and
check that a fresh ring still denies a read. Cover both the opcode
allowlist and a BPF filter.
Skips on 6.18, fails on 7.0, passes on 7.2.9.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Eugene Gvozdetsky <gvozdet@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Per-task io_uring restrictions must keep applying to rings created after exec, including when the task used io_uring before the exec.
Kernels without bc0e8faf90e7 ("io_uring: preserve task restrictions across exec", CVE-2026-80713) drop the restrictions in that case. The new image can then create unrestricted rings.
task-restrict.tdoesn't exec, so it passes on those kernels.The new
task-restrict-exec.t:It covers both the opcode allowlist and a BPF filter, with and without using a ring before the exec. The re-exec'd image is told apart by an environment variable, because the test runner passes arguments.
Results (virtme-ng):
task-restrict-exec.ttask-restrict.tread after exec: 0 (expected -EACCES))Context: I'm adding task-restriction support to a container runtime (opencontainers/runtime-spec#1323, notes in https://github.com/gvozdetsky/iouring-lab).