Bugzilla – Bug 1192051
docker and podman block faccessat2 syscall
Last modified: 2024-05-22 12:30:21 UTC
This is basically the first iteration of bug 1182451 again, but for ppc64le and s390x this time. strace shows that faccessat2 is indeed getting blocked (again): [pid 49831] faccessat2(AT_FDCWD, "/bin/sh", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted) 15 SP3 s390x: s390vsl208:~/:[0]# docker run --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" broken s390vsl208:~/:[0]# podman run --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" broken Works without seccomp filtering: s390vsl208:~/:[0]# docker run --security-opt=seccomp=unconfined --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" s390vsl208:~/:[0]# podman run --security-opt=seccomp=unconfined --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" s390vsl208:~/:[0]# This is on 15 SP3 using docker-20.10.9_ce-156.1.s390x podman-2.1.1-4.28.1.s390x runc-1.0.2-23.1.s390x Also happens with podman + runc from TW in a chroot on the s390x host: podman-3.2.3-1.1.s390x runc-1.0.2-1.1.s390x Similar issue on 15 SP3 ppc64le: pinotage-1:~/:[0]# docker run --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" broken pinotage-1:~/:[0]# podman run --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" broken also works without seccomp: pinotage-1:~/:[0]# docker run --security-opt=seccomp=unconfined --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" pinotage-1:~/:[0]# podman run --security-opt=seccomp=unconfined --rm -it opensuse/tumbleweed bash -c "test -x /bin/sh || echo broken" pinotage-1:~/:[0]# 15 SP3 using: docker-19.03.15_ce-6.46.1.ppc64le podman-2.1.1-4.28.1.ppc64le runc-1.0.0~rc10-1.9.1.ppc64le as well as runc-1.0.2-23.1.ppc64le However, using podman from TW in a chroot works here: podman-3.2.1-1.1.ppc64le runc-1.0.0~rc95-1.2.ppc64le
This is very odd because Docker 20.10.9 has an explicit allow rule for faccessat2[1] (they added it more than a year ago in response to the first issue). I'm very confused why it's not working -- this seems unrelated to the general EPERM problem. [1]: https://github.com/moby/moby/blob/v20.10.9/profiles/seccomp/default_linux.go#L92
(In reply to Aleksa Sarai from comment #1) > This is very odd because Docker 20.10.9 has an explicit allow rule for > faccessat2[1] (they added it more than a year ago in response to the first > issue). I'm very confused why it's not working -- this seems unrelated to > the general EPERM problem. > > [1]: > https://github.com/moby/moby/blob/v20.10.9/profiles/seccomp/default_linux. > go#L92 SUSE:SLE-15-SP3:Update/libseccomp (2.4.1) doesn't mention "faccessat2" anywhere, so it's probably not recognized? The version in TW (2.5.2) has faccessat2 syscalls included.
(In reply to Fabian Vogt from comment #2) > (In reply to Aleksa Sarai from comment #1) > > This is very odd because Docker 20.10.9 has an explicit allow rule for > > faccessat2[1] (they added it more than a year ago in response to the first > > issue). I'm very confused why it's not working -- this seems unrelated to > > the general EPERM problem. > > > > [1]: > > https://github.com/moby/moby/blob/v20.10.9/profiles/seccomp/default_linux. > > go#L92 > > SUSE:SLE-15-SP3:Update/libseccomp (2.4.1) doesn't mention "faccessat2" > anywhere, so it's probably not recognized? > > The version in TW (2.5.2) has faccessat2 syscalls included. But then the fallback logic should work (libseccomp is updated in the same order as kernel versions so the syscall addition order should be monotonically increasing for all new syscalls). But then again, the syscall numbers on s390 and ppc64le are a bit fruity so I wouldn't be surprised if this isn't a good assumption except for the *incredibly* recent syscalls which now are guaranteed to have the same syscall values on every architecture (except alpha). (Unfortunately I think we just need to switch Docker to ENOSYS default profiles to fix this stupid problem that is refusing to die.)
(In reply to Aleksa Sarai from comment #3) > (In reply to Fabian Vogt from comment #2) > > (In reply to Aleksa Sarai from comment #1) > > > This is very odd because Docker 20.10.9 has an explicit allow rule for > > > faccessat2[1] (they added it more than a year ago in response to the first > > > issue). I'm very confused why it's not working -- this seems unrelated to > > > the general EPERM problem. > > > > > > [1]: > > > https://github.com/moby/moby/blob/v20.10.9/profiles/seccomp/default_linux. > > > go#L92 > > > > SUSE:SLE-15-SP3:Update/libseccomp (2.4.1) doesn't mention "faccessat2" > > anywhere, so it's probably not recognized? > > > > The version in TW (2.5.2) has faccessat2 syscalls included. > > But then the fallback logic should work (libseccomp is updated in the same > order as kernel versions so the syscall addition order should be > monotonically increasing for all new syscalls). Sorry, I posted mid-thought -- the point is that there shouldn't be a scenario where a libseccomp version has definitions for syscall_x but not for syscall_y where syscall_y is older than syscall_x (i.e. syscall_y < syscall_x -- but as I said it might not be a valid assumption to say that the < version of the statement is the same as the age statement).
I did some debugging. Updating just libseccomp2 did not help on either architecture. I think it's two separate bugs for s390x and ppc64le. With "runc --debug", the BPF for -ENOSYS looks like this: [ 0] ld [4] [ 1] jeq #22,2 [ 2] jeq #2147483670,4 [ 3] ja 8 [ 4] ld [0] [ 5] jgt #379,5 [ 6] ja 5 [ 7] ld [0] [ 8] jgt #379,2 [ 9] ja 2 [ 10] ja 1 [ 11] ret #327718 [....] --- original filter --- So for both s390 and s390x, it returns -ENOSYS for syscalls >379. faccessat2 is sycall 439, so definitely covered by that. (FTR, clone3 is 435, so added slightly earlier) However, I noticed that strace shows the "faccessat2" syscall as [pid 52384] setup(0xffffffffffffff9c, 0x2aa0e5d26c0, 0x1, 0x200, 0, 0x2aa0d90ef70) = -1 EPERM setup (== 0) is used for multiplexing syscalls, needed for numbers > 255. Maybe in the kernel this not demultiplexed for unknown syscalls? It might work on newer kernel versions. To confirm that it's a multiplexing issue, I wrote a test program: #include <seccomp.h> #include <fcntl.h> #include <unistd.h> int main() { scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_TRAP); seccomp_load(ctx); return syscall(439, AT_FDCWD, "asdf", X_OK, 0); } Build and run like this: gcc seccomptest.c -I /usr/include/libseccomp/ -lseccomp -o seccomp strace ./seccomp And the result shows indeed that the syscall is not set correctly in si_syscall, which is FWICT also passed to the seccomp filter. seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=4, filter=0x105a7b0}) = 0 setup(0xffffffffffffff9c, 0x1000858, 0x1, 0, 0x105a2a0, 0x3ffb3210684) = -1 ENETDOWN (Das Netzwerk ist nicht aktiv) --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x3ffb3006c22, si_syscall=__NR_setup, si_arch=AUDIT_ARCH_S390X} --- faccessat2 is allowed after adding a rule for the multiplex syscall itself: seccomp_rule_add(ctx, SCMP_ACT_ALLOW, 0, 0); This explains also why TW userspace did not work. On ppc64le, the patch looks like this: [ 0] ld [4] [ 1] ja 2 [ 2] ja 1 [ 3] ret #327718 [....] --- original filter --- Which looks like there is some arch-specific issue, and it never return -ENOSYS. In addition, it does not appear to include faccessat2 in the seccomp policy, it's not found in runc's state.json and it did not call seccomp_syscall_resolve_name_arch with faccessat2 either.
(In reply to Fabian Vogt from comment #5) > On ppc64le, the patch looks like this: > > [ 0] ld [4] > [ 1] ja 2 > [ 2] ja 1 > [ 3] ret #327718 > [....] --- original filter --- > > Which looks like there is some arch-specific issue, and it never return > -ENOSYS. The reason for that is that the state.json has: "sysctl": null, "seccomp": { "default_action": 2, "architectures": null, <-- "syscalls": [... So this loop isn't entered, and no lastSyscall is set: https://github.com/opencontainers/runc/blob/931eb942aa26074cf127e363bb7fcd9d15748795/libcontainer/seccomp/patchbpf/enosys_linux.go#L215 > In addition, it does not appear to include faccessat2 in the seccomp policy, > it's not found in runc's state.json and it did not call > seccomp_syscall_resolve_name_arch with faccessat2 either. And that is because the default seccomp profile provided by podman is overwritten by /etc/containers/seccomp.json resp. /usr/share/containers/seccomp.json, which are from SLE 15 SP1's libcontainers-common. The podman-2.0.3.tar.xz inside has a seccomp.json without faccessat2.
I created bug 1192594 for the s390x kernel issue. About ppc64le, what's the best way to proceed here? Simply update libcontainers-common which contains the whitelisting of the new syscalls or fix the BPF patching for -ENOSYS?
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/7728548 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/7814770 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/7897559 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/7946175 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/8003685 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
From my understanding the issue is that it's not possible to run container image using glibc 2.33 or later (TW, Fedora, any recent distro) on s390x and ppc64le, thus I'm setting this bug as P3
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/8157132 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
(In reply to Fabian Vogt from comment #7) > I created bug 1192594 for the s390x kernel issue. > > About ppc64le, what's the best way to proceed here? Simply update > libcontainers-common which contains the whitelisting of the new syscalls or > fix the BPF patching for -ENOSYS? Ping.
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/8311926 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` Expect the next reminder at the earliest in 36 days if nothing changes in this ticket.
This is an autogenerated message for openQA integration by the openqa_review script: This bug is still referenced in a failing openQA test: podman_tests https://openqa.suse.de/tests/8590725 To prevent further reminder comments one of the following options should be followed: 1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted 2. The openQA job group is moved to "Released" or "EOL" (End-of-Life) 3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234` Expect the next reminder at the earliest in 72 days if nothing changes in this ticket.
(In reply to Fabian Vogt from comment #7) > I created bug 1192594 for the s390x kernel issue. > > About ppc64le, what's the best way to proceed here? Simply update > libcontainers-common which contains the whitelisting of the new syscalls or > fix the BPF patching for -ENOSYS? It seems like we need to fix two separate issues, right? 1. Fix the seccomp profile to correctly set the architecture and include faccessat2 (the upstream containers-common repo appears to have already done this?). 2. Add setup(2) as a permitted syscall on s390x and ppc64le. I'm not sure why Docker doesn't have this issue (the Docker seccomp profile doesn't have "setup" in its allowlist either). Fixing the BPF patching is out of scope IMHO -- we need to have at least [1] and possibly more in order fulfill the requirements in [2] so that we can move away from the current BPF patching scheme. [1]: https://github.com/seccomp/libseccomp/pull/381 [2]: https://github.com/seccomp/libseccomp/issues/11
(In reply to Aleksa Sarai from comment #18) > (In reply to Fabian Vogt from comment #7) > > I created bug 1192594 for the s390x kernel issue. > > > > About ppc64le, what's the best way to proceed here? Simply update > > libcontainers-common which contains the whitelisting of the new syscalls or > > fix the BPF patching for -ENOSYS? > > It seems like we need to fix two separate issues, right? > > 1. Fix the seccomp profile to correctly set the architecture and include > faccessat2 (the upstream containers-common repo appears to have already done > this?). > 2. Add setup(2) as a permitted syscall on s390x and ppc64le. I'm not sure > why Docker doesn't have this issue (the Docker seccomp profile doesn't have > "setup" in its allowlist either). > > Fixing the BPF patching is out of scope IMHO -- we need to have at least [1] > and possibly more in order fulfill the requirements in [2] so that we can > move away from the current BPF patching scheme. > > [1]: https://github.com/seccomp/libseccomp/pull/381 > [2]: https://github.com/seccomp/libseccomp/issues/11 @Marcus, since you are the maintainer of libseccomp, can you deal with this bug? Especially in regard of what Aleksa suggest to retrieve this fix from upstream https://github.com/seccomp/libseccomp/pull/381 ?
(In reply to Vincent Moutoussamy from comment #19) > (In reply to Aleksa Sarai from comment #18) > > (In reply to Fabian Vogt from comment #7) > > > I created bug 1192594 for the s390x kernel issue. > > > > > > About ppc64le, what's the best way to proceed here? Simply update > > > libcontainers-common which contains the whitelisting of the new syscalls or > > > fix the BPF patching for -ENOSYS? > > > > It seems like we need to fix two separate issues, right? > > > > 1. Fix the seccomp profile to correctly set the architecture and include > > faccessat2 (the upstream containers-common repo appears to have already done > > this?). > > 2. Add setup(2) as a permitted syscall on s390x and ppc64le. I'm not sure > > why Docker doesn't have this issue (the Docker seccomp profile doesn't have > > "setup" in its allowlist either). > > > > Fixing the BPF patching is out of scope IMHO -- we need to have at least [1] > > and possibly more in order fulfill the requirements in [2] so that we can > > move away from the current BPF patching scheme. > > > > [1]: https://github.com/seccomp/libseccomp/pull/381 > > [2]: https://github.com/seccomp/libseccomp/issues/11 > > @Marcus, since you are the maintainer of libseccomp, can you deal with this > bug? Especially in regard of what Aleksa suggest to retrieve this fix from > upstream https://github.com/seccomp/libseccomp/pull/381 ? Sorry, to clarify -- that fix alone is not enough. More API work on libseccomp would be needed and I would need to rewrite how runc handles unknown syscalls. After testing this in an s390x VM, I suspect that the issue is that if the kernel doesn't know of a syscall, it will not demultiplex it and thus you end up with sys_no=0. It seems like the best solution would be to ENOSYS sys_no=0 (setup) since you should only ever get into this situation if the syscall is not known.
This patch[1] fixes the issue based on my testing (on s390x, I am not sure about the ppc64le issue). I'll send an MR. [1]: https://github.com/opencontainers/runc/pull/3474
(In reply to Aleksa Sarai from comment #21) > This patch[1] fixes the issue based on my testing (on s390x, I am not sure > about the ppc64le issue). I'll send an MR. > > [1]: https://github.com/opencontainers/runc/pull/3474 This patch requires a lot more work -- it turns out the setup(2) syscall has a different syscall number on every architecture so some deeper changes to the stub code will be needed.
(In reply to Aleksa Sarai from comment #18) > (In reply to Fabian Vogt from comment #7) > > I created bug 1192594 for the s390x kernel issue. > > > > About ppc64le, what's the best way to proceed here? Simply update > > libcontainers-common which contains the whitelisting of the new syscalls or > > fix the BPF patching for -ENOSYS? > > It seems like we need to fix two separate issues, right? > > 1. Fix the seccomp profile to correctly set the architecture and include > faccessat2 (the upstream containers-common repo appears to have already done > this?). Yep, plus maybe an update of libseccomp. > 2. Add setup(2) as a permitted syscall on s390x and ppc64le. I'm not sure > why Docker doesn't have this issue No idea either. > (the Docker seccomp profile doesn't have > "setup" in its allowlist either). (In reply to Aleksa Sarai from comment #20) > After testing this in an s390x VM, I suspect that the issue is that if the > kernel doesn't know of a syscall, it will not demultiplex it and thus you > end up with sys_no=0. It seems like the best solution would be to ENOSYS > sys_no=0 (setup) since you should only ever get into this situation if the > syscall is not known. Yes, exactly that is the kernel bug. (In reply to Aleksa Sarai from comment #22) > (In reply to Aleksa Sarai from comment #21) > > This patch[1] fixes the issue based on my testing (on s390x, I am not sure > > about the ppc64le issue). I'll send an MR. > > > > [1]: https://github.com/opencontainers/runc/pull/3474 > > This patch requires a lot more work -- it turns out the setup(2) syscall has > a different syscall number on every architecture so some deeper changes to > the stub code will be needed. FWICT at least for us the kernel bug is s390x specific, so the workaround could be s390x specific as well IMO.
Yeah I ended up making the patch s390(x)-specific. It's been merged. https://github.com/opencontainers/runc/pull/3474
With the update, the test now passed this step. Before: https://openqa.suse.de/tests/8944502#step/rootless_podman/36 Today: https://openqa.suse.de/tests/8956618#step/rootless_podman/31 However, we have a new failure probably not related: https://openqa.suse.de/tests/8956618#step/rootless_podman/167 > susetest systemd[31930]: Failed to start podman-2403.scope. I'll try to reproduce it a open a new bug report for it if applies. Thank you!
SUSE-SU-2022:2165-1: An update that solves two vulnerabilities and has three fixes is now available. Category: security (important) Bug References: 1192051,1199460,1199565,1200088,1200145 CVE References: CVE-2022-29162,CVE-2022-31030 JIRA References: Sources used: SUSE Linux Enterprise Module for Containers 12 (src): containerd-1.6.6-16.62.1, docker-20.10.17_ce-98.83.1, runc-1.1.3-16.21.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:2341-1: An update that solves two vulnerabilities and has three fixes is now available. Category: security (important) Bug References: 1192051,1199460,1199565,1200088,1200145 CVE References: CVE-2022-29162,CVE-2022-31030 JIRA References: Sources used: openSUSE Leap 15.4 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, docker-kubic-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 openSUSE Leap 15.3 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, docker-kubic-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Manager Server 4.1 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Manager Retail Branch Server 4.1 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Manager Proxy 4.1 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server for SAP 15-SP2 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server for SAP 15-SP1 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server for SAP 15 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server 15-SP2-LTSS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server 15-SP2-BCL (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server 15-SP1-LTSS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server 15-SP1-BCL (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Server 15-LTSS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP3 (src): containerd-1.6.6-150000.73.2 SUSE Linux Enterprise Module for Containers 15-SP4 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Module for Containers 15-SP3 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Micro 5.2 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise Micro 5.1 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise High Performance Computing 15-SP2-LTSS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise High Performance Computing 15-SP2-ESPOS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise High Performance Computing 15-LTSS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Linux Enterprise High Performance Computing 15-ESPOS (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1 SUSE Enterprise Storage 7.1 (src): runc-1.1.3-150000.30.1 SUSE Enterprise Storage 7 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE Enterprise Storage 6 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 SUSE CaaS Platform 4.0 (src): containerd-1.6.6-150000.73.2, docker-20.10.17_ce-150000.166.1, runc-1.1.3-150000.30.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Hi guys, so what's the status on this bug? Can we close it but we have another regression? please clarify.
(In reply to Vincent Moutoussamy from comment #31) > Hi guys, so what's the status on this bug? > Can we close it but we have another regression? please clarify. Ping? @Fabian @Aleksa?
(In reply to Vincent Moutoussamy from comment #32) > (In reply to Vincent Moutoussamy from comment #31) > > Hi guys, so what's the status on this bug? > > Can we close it but we have another regression? please clarify. > > Ping? @Fabian @Aleksa? FWICT it's fixed for s390x, but I'm not sure for ppc64le.
(In reply to Fabian Vogt from comment #33) > (In reply to Vincent Moutoussamy from comment #32) > > (In reply to Vincent Moutoussamy from comment #31) > > > Hi guys, so what's the status on this bug? > > > Can we close it but we have another regression? please clarify. > > > > Ping? @Fabian @Aleksa? > > FWICT it's fixed for s390x, but I'm not sure for ppc64le. It is fixed in s390x (with both a runc fix and a kernel fix). For ppc64le, I was never able to reproduce the issue on ppc64le and as per your comment in comment #24, it seemed like it was s390x-specific so we ended up with a s390x-only fix. If there still is an issue on ppc, I'll need to make a separate patch for it (and probably also open a kernel bug about the issue if it's also an unknown-syscall multiplexing issue).
(In reply to Aleksa Sarai from comment #34) > (In reply to Fabian Vogt from comment #33) > > (In reply to Vincent Moutoussamy from comment #32) > > > (In reply to Vincent Moutoussamy from comment #31) > > > > Hi guys, so what's the status on this bug? > > > > Can we close it but we have another regression? please clarify. > > > > > > Ping? @Fabian @Aleksa? > > > > FWICT it's fixed for s390x, but I'm not sure for ppc64le. > > It is fixed in s390x (with both a runc fix and a kernel fix). For ppc64le, I > was never able to reproduce the issue on ppc64le and as per your comment in > comment #24, it seemed like it was s390x-specific so we ended up with a > s390x-only fix. > > If there still is an issue on ppc, I'll need to make a separate patch for it > (and probably also open a kernel bug about the issue if it's also an > unknown-syscall multiplexing issue). I'm closing this bug then, this is starting to get old. Let's reopen if we have any proofs.
(In reply to Aleksa Sarai from comment #34) > (In reply to Fabian Vogt from comment #33) > > (In reply to Vincent Moutoussamy from comment #32) > > > (In reply to Vincent Moutoussamy from comment #31) > > > > Hi guys, so what's the status on this bug? > > > > Can we close it but we have another regression? please clarify. > > > > > > Ping? @Fabian @Aleksa? > > > > FWICT it's fixed for s390x, but I'm not sure for ppc64le. > > It is fixed in s390x (with both a runc fix and a kernel fix). For ppc64le, I > was never able to reproduce the issue on ppc64le and as per your comment in > comment #24, it seemed like it was s390x-specific so we ended up with a > s390x-only fix. > > If there still is an issue on ppc, I'll need to make a separate patch for it > (and probably also open a kernel bug about the issue if it's also an > unknown-syscall multiplexing issue). It turns out that bug 1221050 was caused by this. I believe https://github.com/opencontainers/runc/pull/4219 will fix it.
SUSE-RU-2024:0981-1: An update that has two fixes can now be installed. Category: recommended (important) Bug References: 1192051, 1221050 Maintenance Incident: [SUSE:Maintenance:33022](https://smelt.suse.de/incident/33022/) Sources used: Containers Module 12 (src): runc-1.1.12-16.49.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2024:0984-1: An update that has two fixes can now be installed. Category: recommended (important) Bug References: 1192051, 1221050 Maintenance Incident: [SUSE:Maintenance:33023](https://smelt.suse.de/incident/33023/) Sources used: SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): runc-1.1.12-150000.64.1 SUSE Enterprise Storage 7.1 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro 5.1 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro 5.2 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro for Rancher 5.2 (src): runc-1.1.12-150000.64.1 openSUSE Leap Micro 5.3 (src): runc-1.1.12-150000.64.1 openSUSE Leap Micro 5.4 (src): runc-1.1.12-150000.64.1 openSUSE Leap 15.5 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro for Rancher 5.3 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro 5.3 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro 5.4 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise Micro 5.5 (src): runc-1.1.12-150000.64.1 Containers Module 15-SP5 (src): runc-1.1.12-150000.64.1 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): runc-1.1.12-150000.64.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2024:0984-2: An update that has two fixes can now be installed. Category: recommended (important) Bug References: 1192051, 1221050 Maintenance Incident: [SUSE:Maintenance:33023](https://smelt.suse.de/incident/33023/) Sources used: openSUSE Leap 15.6 (src): runc-1.1.12-150000.64.1 Containers Module 15-SP6 (src): runc-1.1.12-150000.64.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.