[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
Launchpad has imported 7 comments from the remote bug at https://bugzilla.kernel.org/show_bug.cgi?id=195453. If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. On 2017-04-18T13:22:33+00:00 colin.king wrote: There is a race condition on the fs->users counter and fs->in_exec flag that impacts exec() on a suid program when there are multiple threads being created and destroyed by a parent process. This in_exec flag was introduced way back in 2009 with commit: commit 498052bba55ecaff58db6a1436b0e25bfd75a7ff Author: Al Viro Date: Mon Mar 30 07:20:30 2009 -0400 When performing an exec() on a suid program, check_unsafe_exec() checks to see we have more f->fs->users than the count of child threads that share the same fs with the parent. However, there are two race conditions that this seems to fail on: 1. The parent may be creating a new thread and copy_fs in kernel/fork.c bumps the fs->users count before the thread is attached to the parent hence causing the check p->fs->users > n_fs in check_unsafe_exec() to be true in check_unsafe_exec() and cause the execution a the suid program by the parent to fail to marked as unsafe and so it executes as a non- suid executable. The crux of the matter is that the fs->user count temporarily ahead by 1 with the number of threads linked to the process and we don't have any locking mechanism to protect us from this in the exec phase. 2. A thread my be dying and the associated fs pointer is nullified before it is removed from the parent and this also causes issues in the check_unsafe_exec() fs sanity check. I believe this can be fixed checking for t->fs being NULL, e.g.: diff --git a/fs/exec.c b/fs/exec.c index 72934df68471..ebfd9b76b69f 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1447,7 +1447,7 @@ static void check_unsafe_exec(struct linux_binprm *bprm) spin_lock(&p->fs->lock); rcu_read_lock(); while_each_thread(p, t) { - if (t->fs == p->fs) + if (t->fs == p->fs || !t->fs) n_fs++; } rcu_read_unlock(); The reproducer is quite simple and always easy to reproduce: $ cat Makefile ALL=a b all: $(ALL) a: LDFLAGS=-pthread b: b.c $(CC) b.c -o b sudo chown root:root b sudo chmod u+s b test: for I in $$(seq 1000); do echo $I; ./a ; done clean: rm -vf $(ALL) $ cat a.c #include #include #include #include void *nothing(void *p) { return NULL; } void *target(void *p) { for (;;) { pthread_t t; if (pthread_create(&t, NULL, nothing, NULL) == 0) pthread_join(t, NULL); } return NULL; } int main(void) { struct timespec tv; int i; for (i = 0; i < 10; i++) { pthread_t t; pthread_create(&t, NULL, target, NULL); } tv.tv_sec = 0; tv.tv_nsec = 10; nanosleep(&tv, NULL); if (execl("./b", "./b", NULL) < 0) perror("execl"); return 0; } $ cat b.c #include #include #include int main(void) { const uid_t euid = geteuid(); if (euid != 0) { printf("Failed, got euid %d (expecting 0)\n", euid); return 1; } return 0; } To reproduce: make make test You will see "Failed, got euid 1000 (expecting 0)" errors whenever the suid program being exec'd fails to exec as a suid process because of the race and failure in check_unsafe_exec() Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/comments/12 On 2017-04-21T00:36:08+00:00 dev.jongy wrote: I don't think the second condition you gave is relevant, because once the task_struct->fs pointer is nullified, this thread is not accounted in fs->users anymore. Since this thread doesn't count for neither fs->count nor n_fs, it is okay. The first condition is indeed a problem. I'm not sure of the wanted fix (probably some kind of locking in copy_process, that while_each_thread could use too), but currently this race is bad. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/comments/14 On 2017-04-21T09:47:07+00:00 colin.king wrote: Thanks for looking at this. The locking on copy_process concerns me as I didn't want to introduce a locking fix that caused a serious performance regression on the copy and exec paths. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/comments/15 On 2017-05-03T10:55:47+00:00 colin.king wrot
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux Status: Unknown => Confirmed ** Changed in: linux Importance: Unknown => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Confirmed Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Released Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio Cu
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
submitted https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1876856 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Released Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
Guys, your commit d6572202d986 ("UBUNTU:SAUCE: exec: ensure file system accounting in check_unsafe_exec is correct") looks wrong for me, it leads to endless cycle in check_unsafe_exec(). fs/exec.c:: check_unsafe_exec() ... recheck: fs_recheck = false; t = p; n_fs = 1; spin_lock(&p->fs->lock); rcu_read_lock(); while_each_thread(p, t) { if (t->fs == p->fs) n_fs++; if (t->flags & (PF_EXITING | PF_FORKNOEXEC)) fs_recheck = true; } rcu_read_unlock(); if (p->fs->users > n_fs) { if (fs_recheck) { spin_unlock(&p->fs->lock); goto recheck; << cycles forever } bprm->unsafe |= LSM_UNSAFE_SHARE; } else p->fs->in_exec = 1; spin_unlock(&p->fs->lock); We have few Soft lockups inside VMs with ubuntu 16.04, where process was cyceled here. Should I submit you separate bug for this problem? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Released Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static bi
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug was fixed in the package golang-1.6 - 1.6.2-0ubuntu5~16.04.3 --- golang-1.6 (1.6.2-0ubuntu5~16.04.3) xenial; urgency=medium * Backport workaround for execve issue that causes the setuid bit to be ignored when losing a race in the kernel. (LP: #1672819) -- Michael Hudson-Doyle Mon, 03 Jul 2017 11:53:56 +1200 ** Changed in: golang-1.6 (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Released Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname:
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
I've verified the fix in the way I suspected I'd have to, with one extra wrinkle. 1) In a trusty VM, I verified that the C test case from the gist failed. (It did). 2) I launched a xenial lxd container on the VM and built the Go test case with version 1.6.2-0ubuntu5~16.04.2 of golang-1.6-go. 3) It did not fail in the lxd container for reasons I couldn't understand but it did fail when copied out of the container on to the trusty VM (failed 563 times out of 100k) 4) I then installed golang-1.6-go version 1.6.2-0ubuntu5~16.04.3 in the container and rebuilt the Go test case with the new compiler. 5) This did not fail when run directly on the trusty VM (0 failures out of 100k runs) So I'm confident the fix has helped. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Committed Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't g
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
Hello John, or anyone else affected, Accepted golang-1.6 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/golang-1.6/1.6.2-0ubuntu5~16.04.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: golang-1.6 (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags removed: verification-done-xenial ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: Fix Committed Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* rep
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: golang-1.6 (Ubuntu Xenial) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: In Progress Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU template for golang-1.6 == [Impact] The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. [Test case] This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. [Regression potential] If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 1
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Description changed: + == SRU template for golang-1.6 == + + [Impact] + The kernel bug reported below means that occasionally (maybe 1 in 1000 times) the snapd -> snap-confine exec that is part of a snap execution fails to take the setuid bit on the snap-confine binary into account which means that the execution fails. This is extremely confusing for the user of the snap who just sees a permission denied error with no explanation. + + The kernel bug has been fixed in Xenial+ but not all users of snapd are on xenial+ kernels (they might be on trusty or another distribution entirely). + Backporting this fix will mean that the snapd in the core snap will get the workaround next time it is built and because the snapd in trusty or the other distro will re-exec into the snapd in the core snap before execing snap-confine, users should not see the above behaviour. + + [Test case] + This will be a bit tricky as the kernel bug has been fixed. A xenial container on a trusty host/VM should do the trick. The test case from https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded from proposed, the fix. + + [Regression potential] + If there is a bug in the patch it could cause deadlocks in currently working programs. But the patch is pretty simple and has passed review upstream so I think it should be OK. + == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed w
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Also affects: golang-1.6 (Ubuntu) Importance: Undecided Status: New ** Changed in: golang-1.6 (Ubuntu) Status: New => Invalid ** Changed in: golang-1.6 (Ubuntu Yakkety) Status: New => Invalid ** Changed in: golang-1.6 (Ubuntu Zesty) Status: New => Invalid ** Changed in: golang-1.6 (Ubuntu Xenial) Assignee: (unassigned) => Michael Hudson-Doyle (mwhudson) ** Changed in: golang-1.6 (Ubuntu Xenial) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in golang-1.6 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in golang-1.6 source package in Xenial: New Status in linux source package in Xenial: Fix Released Status in golang-1.6 source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Released Status in golang-1.6 source package in Zesty: Invalid Status in linux source package in Zesty: Fix Released Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias:
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug was fixed in the package linux - 4.10.0-26.30 --- linux (4.10.0-26.30) zesty; urgency=low * linux: 4.10.0-26.30 -proposed tracker (LP: #1700528) * CVE-2017-1000364 - Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit" - Revert "mm: do not collapse stack gap into THP" - Revert "mm: enlarge stack guard gap" - mm: larger stack guard gap, between vmas - mm: fix new crash in unmapped_area_topdown() - Allow stack to grow up to address space limit linux (4.10.0-25.29) zesty; urgency=low * linux: 4.10.0-25.29 -proposed tracker (LP: #1699028) * CVE-2017-1000364 - SAUCE: mm: Only expand stack if guard area is hit * CVE-2017-9074 - ipv6: Prevent overrun when parsing v6 header options - ipv6: Check ip6_find_1stfragopt() return value properly. * [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s! (LP: #1680549) - iommu/dma: Stop getting dma_32bit_pfn wrong - iommu/dma: Implement PCI allocation optimisation - iommu/dma: Convert to address-based allocation - iommu/dma: Clean up MSI IOVA allocation - iommu/dma: Plumb in the per-CPU IOVA caches - iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range * Zesty update to 4.10.17 stable release (LP: #1692898) - xen: adjust early dom0 p2m handling to xen hypervisor behavior - target: Fix compare_and_write_callback handling for non GOOD status - target/fileio: Fix zero-length READ and WRITE handling - iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement - usb: xhci: bInterval quirk for TI TUSB73x0 - usb: host: xhci: print correct command ring address - USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit - USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously - USB: Revert "cdc-wdm: fix "out-of-sync" due to missing notifications" - staging: vt6656: use off stack for in buffer USB transfers. - staging: vt6656: use off stack for out buffer USB transfers. - staging: gdm724x: gdm_mux: fix use-after-free on module unload - staging: wilc1000: Fix problem with wrong vif index - staging: comedi: jr3_pci: fix possible null pointer dereference - staging: comedi: jr3_pci: cope with jiffies wraparound - usb: misc: add missing continue in switch - usb: gadget: legacy gadgets are optional - usb: Make sure usb/phy/of gets built-in - usb: hub: Fix error loop seen after hub communication errors - usb: hub: Do not attempt to autosuspend disconnected devices - x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup - selftests/x86/ldt_gdt_32: Work around a glibc sigaction() bug - x86, pmem: Fix cache flushing for iovec write < 8 bytes - um: Fix PTRACE_POKEUSER on x86_64 - perf/x86: Fix Broadwell-EP DRAM RAPL events - KVM: x86: fix user triggerable warning in kvm_apic_accept_events() - KVM: arm/arm64: fix races in kvm_psci_vcpu_on - arm64: KVM: Fix decoding of Rt/Rt2 when trapping AArch32 CP accesses - block: fix blk_integrity_register to use template's interval_exp if not 0 - crypto: s5p-sss - Close possible race for completed requests - crypto: algif_aead - Require setkey before accept(2) - crypto: ccp - Use only the relevant interrupt bits - crypto: ccp - Disable interrupts early on unload - crypto: ccp - Change ISR handler method for a v3 CCP - crypto: ccp - Change ISR handler method for a v5 CCP - dm crypt: rewrite (wipe) key in crypto layer using random data - dm era: save spacemap metadata root after the pre-commit - dm rq: check blk_mq_register_dev() return value in dm_mq_init_request_queue() - dm thin: fix a memory leak when passing discard bio down - vfio/type1: Remove locked page accounting workqueue - iov_iter: don't revert iov buffer if csum error - IB/core: Fix sysfs registration error flow - IB/core: For multicast functions, verify that LIDs are multicast LIDs - IB/IPoIB: ibX: failed to create mcg debug file - IB/mlx4: Fix ib device initialization error flow - IB/mlx4: Reduce SRIOV multicast cleanup warning message to debug level - IB/hfi1: Prevent kernel QP post send hard lockups - perf auxtrace: Fix no_size logic in addr_filter__resolve_kernel_syms() - perf annotate s390: Fix perf annotate error -95 (4.10 regression) - perf annotate s390: Implement jump types for perf annotate - jbd2: fix dbench4 performance regression for 'nobarrier' mounts - ext4: evict inline data when writing to memory map - orangefs: fix bounds check for listxattr - orangefs: clean up oversize xattr validation - orangefs: do not set getattr_time on orangefs_lookup - orangefs: do not check possibly stale size on truncate - fs/xattr.c: zero out memory copied to userspace in getxattr - ceph: fix memory leak
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug was fixed in the package linux - 4.10.0-26.30 --- linux (4.10.0-26.30) zesty; urgency=low * linux: 4.10.0-26.30 -proposed tracker (LP: #1700528) * CVE-2017-1000364 - Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit" - Revert "mm: do not collapse stack gap into THP" - Revert "mm: enlarge stack guard gap" - mm: larger stack guard gap, between vmas - mm: fix new crash in unmapped_area_topdown() - Allow stack to grow up to address space limit linux (4.10.0-25.29) zesty; urgency=low * linux: 4.10.0-25.29 -proposed tracker (LP: #1699028) * CVE-2017-1000364 - SAUCE: mm: Only expand stack if guard area is hit * CVE-2017-9074 - ipv6: Prevent overrun when parsing v6 header options - ipv6: Check ip6_find_1stfragopt() return value properly. * [Zesty] QDF2400 ARM64 server - NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s! (LP: #1680549) - iommu/dma: Stop getting dma_32bit_pfn wrong - iommu/dma: Implement PCI allocation optimisation - iommu/dma: Convert to address-based allocation - iommu/dma: Clean up MSI IOVA allocation - iommu/dma: Plumb in the per-CPU IOVA caches - iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range * Zesty update to 4.10.17 stable release (LP: #1692898) - xen: adjust early dom0 p2m handling to xen hypervisor behavior - target: Fix compare_and_write_callback handling for non GOOD status - target/fileio: Fix zero-length READ and WRITE handling - iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement - usb: xhci: bInterval quirk for TI TUSB73x0 - usb: host: xhci: print correct command ring address - USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit - USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously - USB: Revert "cdc-wdm: fix "out-of-sync" due to missing notifications" - staging: vt6656: use off stack for in buffer USB transfers. - staging: vt6656: use off stack for out buffer USB transfers. - staging: gdm724x: gdm_mux: fix use-after-free on module unload - staging: wilc1000: Fix problem with wrong vif index - staging: comedi: jr3_pci: fix possible null pointer dereference - staging: comedi: jr3_pci: cope with jiffies wraparound - usb: misc: add missing continue in switch - usb: gadget: legacy gadgets are optional - usb: Make sure usb/phy/of gets built-in - usb: hub: Fix error loop seen after hub communication errors - usb: hub: Do not attempt to autosuspend disconnected devices - x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup - selftests/x86/ldt_gdt_32: Work around a glibc sigaction() bug - x86, pmem: Fix cache flushing for iovec write < 8 bytes - um: Fix PTRACE_POKEUSER on x86_64 - perf/x86: Fix Broadwell-EP DRAM RAPL events - KVM: x86: fix user triggerable warning in kvm_apic_accept_events() - KVM: arm/arm64: fix races in kvm_psci_vcpu_on - arm64: KVM: Fix decoding of Rt/Rt2 when trapping AArch32 CP accesses - block: fix blk_integrity_register to use template's interval_exp if not 0 - crypto: s5p-sss - Close possible race for completed requests - crypto: algif_aead - Require setkey before accept(2) - crypto: ccp - Use only the relevant interrupt bits - crypto: ccp - Disable interrupts early on unload - crypto: ccp - Change ISR handler method for a v3 CCP - crypto: ccp - Change ISR handler method for a v5 CCP - dm crypt: rewrite (wipe) key in crypto layer using random data - dm era: save spacemap metadata root after the pre-commit - dm rq: check blk_mq_register_dev() return value in dm_mq_init_request_queue() - dm thin: fix a memory leak when passing discard bio down - vfio/type1: Remove locked page accounting workqueue - iov_iter: don't revert iov buffer if csum error - IB/core: Fix sysfs registration error flow - IB/core: For multicast functions, verify that LIDs are multicast LIDs - IB/IPoIB: ibX: failed to create mcg debug file - IB/mlx4: Fix ib device initialization error flow - IB/mlx4: Reduce SRIOV multicast cleanup warning message to debug level - IB/hfi1: Prevent kernel QP post send hard lockups - perf auxtrace: Fix no_size logic in addr_filter__resolve_kernel_syms() - perf annotate s390: Fix perf annotate error -95 (4.10 regression) - perf annotate s390: Implement jump types for perf annotate - jbd2: fix dbench4 performance regression for 'nobarrier' mounts - ext4: evict inline data when writing to memory map - orangefs: fix bounds check for listxattr - orangefs: clean up oversize xattr validation - orangefs: do not set getattr_time on orangefs_lookup - orangefs: do not check possibly stale size on truncate - fs/xattr.c: zero out memory copied to userspace in getxattr - ceph: fix memory leak
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug was fixed in the package linux - 4.4.0-83.106 --- linux (4.4.0-83.106) xenial; urgency=low * linux: 4.4.0-83.106 -proposed tracker (LP: #1700541) * CVE-2017-1000364 - Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit" - Revert "mm: do not collapse stack gap into THP" - Revert "mm: enlarge stack guard gap" - mm: vma_adjust: remove superfluous confusing update in remove_next == 1 case - mm: larger stack guard gap, between vmas - mm: fix new crash in unmapped_area_topdown() - Allow stack to grow up to address space limit linux (4.4.0-82.105) xenial; urgency=low * linux: 4.4.0-82.105 -proposed tracker (LP: #1699064) * CVE-2017-1000364 - SAUCE: mm: Only expand stack if guard area is hit * linux-aws/linux-gke incorrectly producing and using linux-*-tools- common/linux-*-cloud-tools-common (LP: #1688579) - [Config] make linux-tools-common and linux-cloud-tools-common protection consistent * CVE-2017-9242 - ipv6: fix out of bound writes in __ip6_append_data() * CVE-2017-9075 - sctp: do not inherit ipv6_{mc|ac|fl}_list from parent * CVE-2017-9074 - ipv6: Prevent overrun when parsing v6 header options * CVE-2017-9076 - ipv6/dccp: do not inherit ipv6_mc_list from parent * CVE-2017-9077 - ipv6/dccp: do not inherit ipv6_mc_list from parent * CVE-2017-8890 - dccp/tcp: do not inherit mc_list from parent * Module signing exclusion for staging drivers does not work properly (LP: #1690908) - SAUCE: Fix module signing exclusion in package builds * extend-diff-ignore should use exact matches (LP: #1693504) - [Packaging] exact extend-diff-ignore matches * Dell XPS 9360 wifi 5G performance is poor (LP: #1692836) - SAUCE: ath10k: fix the wifi speed issue for kill 1535 * Upgrade Redpine WLAN/BT driver to ver. 1.2.RC12 (LP: #1694607) - SAUCE: Redpine: Upgrade to ver. 1.2.RC12 * [DP MST] No audio output through HDMI/DP/mDP ports in Dell WD15 and TB15 docking stations (LP: #1694665) - drm/i915: Store port enum in intel_encoder - drm/i915: Eliminate redundant local variable definition - drm/i915: Switch to using port stored in intel_encoder - drm/i915: Move audio_connector to intel_encoder - drm/i915/dp: DP audio API changes for MST - drm/i915: abstract ddi being audio enabled - drm/i915/audio: extend get_saved_enc() to support more scenarios - drm/i915: enable dp mst audio * Xenial update to 4.4.70 stable release (LP: #1694621) - usb: misc: legousbtower: Fix buffers on stack - usb: misc: legousbtower: Fix memory leak - USB: ene_usb6250: fix DMA to the stack - watchdog: pcwd_usb: fix NULL-deref at probe - char: lp: fix possible integer overflow in lp_setup() - USB: core: replace %p with %pK - ARM: tegra: paz00: Mark panel regulator as enabled on boot - tpm_crb: check for bad response size - infiniband: call ipv6 route lookup via the stub interface - dm btree: fix for dm_btree_find_lowest_key() - dm raid: select the Kconfig option CONFIG_MD_RAID0 - dm bufio: avoid a possible ABBA deadlock - dm bufio: check new buffer allocation watermark every 30 seconds - dm cache metadata: fail operations if fail_io mode has been established - dm bufio: make the parameter "retain_bytes" unsigned long - dm thin metadata: call precommit before saving the roots - dm space map disk: fix some book keeping in the disk space map - md: update slab_cache before releasing new stripes when stripes resizing - rtlwifi: rtl8821ae: setup 8812ae RFE according to device type - mwifiex: pcie: fix cmd_buf use-after-free in remove/reset - ima: accept previously set IMA_NEW_FILE - KVM: x86: Fix load damaged SSEx MXCSR register - KVM: X86: Fix read out-of-bounds vulnerability in kvm pio emulation - regulator: tps65023: Fix inverted core enable logic. - s390/kdump: Add final note - s390/cputime: fix incorrect system time - ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device - ath9k_htc: fix NULL-deref at probe - drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations. - drm/amdgpu: Make display watermark calculations more accurate - drm/nouveau/therm: remove ineffective workarounds for alarm bugs - drm/nouveau/tmr: ack interrupt before processing alarms - drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm - drm/nouveau/tmr: avoid processing completed alarms when adding a new one - drm/nouveau/tmr: handle races with hw when updating the next alarm time - cdc-acm: fix possible invalid access when processing notification - proc: Fix unbalanced hard link numbers - of: fix sparse warning in of_pci_range_parser_one - iio: dac: ad7303: fix channel description - pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes - pid_ns: Fix race
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug was fixed in the package linux - 4.4.0-83.106 --- linux (4.4.0-83.106) xenial; urgency=low * linux: 4.4.0-83.106 -proposed tracker (LP: #1700541) * CVE-2017-1000364 - Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit" - Revert "mm: do not collapse stack gap into THP" - Revert "mm: enlarge stack guard gap" - mm: vma_adjust: remove superfluous confusing update in remove_next == 1 case - mm: larger stack guard gap, between vmas - mm: fix new crash in unmapped_area_topdown() - Allow stack to grow up to address space limit linux (4.4.0-82.105) xenial; urgency=low * linux: 4.4.0-82.105 -proposed tracker (LP: #1699064) * CVE-2017-1000364 - SAUCE: mm: Only expand stack if guard area is hit * linux-aws/linux-gke incorrectly producing and using linux-*-tools- common/linux-*-cloud-tools-common (LP: #1688579) - [Config] make linux-tools-common and linux-cloud-tools-common protection consistent * CVE-2017-9242 - ipv6: fix out of bound writes in __ip6_append_data() * CVE-2017-9075 - sctp: do not inherit ipv6_{mc|ac|fl}_list from parent * CVE-2017-9074 - ipv6: Prevent overrun when parsing v6 header options * CVE-2017-9076 - ipv6/dccp: do not inherit ipv6_mc_list from parent * CVE-2017-9077 - ipv6/dccp: do not inherit ipv6_mc_list from parent * CVE-2017-8890 - dccp/tcp: do not inherit mc_list from parent * Module signing exclusion for staging drivers does not work properly (LP: #1690908) - SAUCE: Fix module signing exclusion in package builds * extend-diff-ignore should use exact matches (LP: #1693504) - [Packaging] exact extend-diff-ignore matches * Dell XPS 9360 wifi 5G performance is poor (LP: #1692836) - SAUCE: ath10k: fix the wifi speed issue for kill 1535 * Upgrade Redpine WLAN/BT driver to ver. 1.2.RC12 (LP: #1694607) - SAUCE: Redpine: Upgrade to ver. 1.2.RC12 * [DP MST] No audio output through HDMI/DP/mDP ports in Dell WD15 and TB15 docking stations (LP: #1694665) - drm/i915: Store port enum in intel_encoder - drm/i915: Eliminate redundant local variable definition - drm/i915: Switch to using port stored in intel_encoder - drm/i915: Move audio_connector to intel_encoder - drm/i915/dp: DP audio API changes for MST - drm/i915: abstract ddi being audio enabled - drm/i915/audio: extend get_saved_enc() to support more scenarios - drm/i915: enable dp mst audio * Xenial update to 4.4.70 stable release (LP: #1694621) - usb: misc: legousbtower: Fix buffers on stack - usb: misc: legousbtower: Fix memory leak - USB: ene_usb6250: fix DMA to the stack - watchdog: pcwd_usb: fix NULL-deref at probe - char: lp: fix possible integer overflow in lp_setup() - USB: core: replace %p with %pK - ARM: tegra: paz00: Mark panel regulator as enabled on boot - tpm_crb: check for bad response size - infiniband: call ipv6 route lookup via the stub interface - dm btree: fix for dm_btree_find_lowest_key() - dm raid: select the Kconfig option CONFIG_MD_RAID0 - dm bufio: avoid a possible ABBA deadlock - dm bufio: check new buffer allocation watermark every 30 seconds - dm cache metadata: fail operations if fail_io mode has been established - dm bufio: make the parameter "retain_bytes" unsigned long - dm thin metadata: call precommit before saving the roots - dm space map disk: fix some book keeping in the disk space map - md: update slab_cache before releasing new stripes when stripes resizing - rtlwifi: rtl8821ae: setup 8812ae RFE according to device type - mwifiex: pcie: fix cmd_buf use-after-free in remove/reset - ima: accept previously set IMA_NEW_FILE - KVM: x86: Fix load damaged SSEx MXCSR register - KVM: X86: Fix read out-of-bounds vulnerability in kvm pio emulation - regulator: tps65023: Fix inverted core enable logic. - s390/kdump: Add final note - s390/cputime: fix incorrect system time - ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device - ath9k_htc: fix NULL-deref at probe - drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations. - drm/amdgpu: Make display watermark calculations more accurate - drm/nouveau/therm: remove ineffective workarounds for alarm bugs - drm/nouveau/tmr: ack interrupt before processing alarms - drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm - drm/nouveau/tmr: avoid processing completed alarms when adding a new one - drm/nouveau/tmr: handle races with hw when updating the next alarm time - cdc-acm: fix possible invalid access when processing notification - proc: Fix unbalanced hard link numbers - of: fix sparse warning in of_pci_range_parser_one - iio: dac: ad7303: fix channel description - pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes - pid_ns: Fix race
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug was fixed in the package linux - 4.8.0-58.63 --- linux (4.8.0-58.63) yakkety; urgency=low * linux: 4.8.0-58.63 -proposed tracker (LP: #1700533) * CVE-2017-1000364 - Revert "UBUNTU: SAUCE: mm: Only expand stack if guard area is hit" - Revert "mm: do not collapse stack gap into THP" - Revert "mm: enlarge stack guard gap" - mm: vma_adjust: remove superfluous confusing update in remove_next == 1 case - mm: larger stack guard gap, between vmas - mm: fix new crash in unmapped_area_topdown() - Allow stack to grow up to address space limit linux (4.8.0-57.62) yakkety; urgency=low * linux: 4.8.0-57.62 -proposed tracker (LP: #1699035) * CVE-2017-1000364 - SAUCE: mm: Only expand stack if guard area is hit * CVE-2017-7374 - fscrypt: remove broken support for detecting keyring key revocation * CVE-2017-100363 - char: lp: fix possible integer overflow in lp_setup() * CVE-2017-9242 - ipv6: fix out of bound writes in __ip6_append_data() * CVE-2017-9075 - sctp: do not inherit ipv6_{mc|ac|fl}_list from parent * CVE-2017-9074 - ipv6: Prevent overrun when parsing v6 header options * CVE-2017-9076 - ipv6/dccp: do not inherit ipv6_mc_list from parent * CVE-2017-9077 - ipv6/dccp: do not inherit ipv6_mc_list from parent * CVE-2017-8890 - dccp/tcp: do not inherit mc_list from parent * extend-diff-ignore should use exact matches (LP: #1693504) - [Packaging] exact extend-diff-ignore matches * APST quirk needed for Intel NVMe (LP: #1686592) - nvme: Quirk APST on Intel 600P/P3100 devices * regression: the 4.8 hwe kernel does not create the /sys/block/*/device/enclosure_device:* symlinks (LP: #1691899) - scsi: ses: Fix SAS device detection in enclosure * datapath: Add missing case OVS_TUNNEL_KEY_ATTR_PAD (LP: #1676679) - openvswitch: Add missing case OVS_TUNNEL_KEY_ATTR_PAD * connection flood to port 445 on mounting cifs volume under kernel (LP: #1686099) - cifs: Do not send echoes before Negotiate is complete * Support IPMI system interface on Cavium ThunderX (LP: #1688132) - i2c: octeon: Rename driver to prepare for split - i2c: octeon: Split the driver into two parts - [Config] CONFIG_I2C_THUNDERX=m - i2c: thunderx: Add i2c driver for ThunderX SOC - i2c: thunderx: Add SMBUS alert support - i2c: octeon,thunderx: Move register offsets to struct - i2c: octeon: Sort include files alphabetically - i2c: octeon: Use booleon values for booleon variables - i2c: octeon: thunderx: Add MAINTAINERS entry - i2c: octeon: Fix set SCL recovery function - i2c: octeon: Avoid sending STOP during recovery - i2c: octeon: Fix high-level controller status check - i2c: octeon: thunderx: TWSI software reset in recovery - i2c: octeon: thunderx: Remove double-check after interrupt - i2c: octeon: thunderx: Limit register access retries - i2c: thunderx: Enable HWMON class probing * CVE-2017-5577 - drm/vc4: Return -EINVAL on the overflow checks failing. * Merlin SGMII fail on Ubuntu Xenial HWE kernel (LP: #1686305) - net: phy: marvell: fix Marvell 88E1512 used in SGMII mode - drivers: net: phy: xgene: Fix mdio write * Keyboard backlight control does not work on some dell laptops. (LP: #1693126) - platform/x86: dell-laptop: Add Latitude 7480 and others to the DMI whitelist - platform/x86: dell-laptop: Add keyboard backlight timeout AC settings * exec'ing a setuid binary from a threaded program sometimes fails to setuid (LP: #1672819) - SAUCE: exec: ensure file system accounting in check_unsafe_exec is correct * CVE-2017-7294 - drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl() -- Stefan Bader Mon, 26 Jun 2017 17:31:13 +0200 ** Changed in: linux (Ubuntu Yakkety) Status: Fix Committed => Fix Released ** CVE added: https://cve.mitre.org/cgi- bin/cvename.cgi?name=2017-1000364 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-100363 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5577 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-7294 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-7374 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-8890 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9074 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9075 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9076 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9077 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9242 ** Changed in: linux (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary f
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
tested on zesty, 4.10.0-23-generic #25-Ubuntu, passed the test. ** Tags removed: verification-needed-zesty ** Tags added: verification-done-zesty -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
tested on xenial, 4.4.0-80-generic #101-Ubuntu, passed the test. ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
tested on yakkety, 4.8.0-55-generic #58-Ubuntu, passed the test. ** Tags removed: verification-needed-yakkety ** Tags added: verification-done-yakkety -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu) Assignee: (unassigned) => Colin Ian King (colin-king) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- yakkety' to 'verification-done-yakkety'. If the problem still exists, change the tag 'verification-needed-yakkety' to 'verification-failed- yakkety'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-zesty -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:s
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- zesty' to 'verification-done-zesty'. If the problem still exists, change the tag 'verification-needed-zesty' to 'verification-failed-zesty'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rv
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial ** Tags added: verification-needed-yakkety -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalia
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu Yakkety) Assignee: (unassigned) => Colin Ian King (colin-king) ** Changed in: linux (Ubuntu Zesty) Assignee: (unassigned) => Colin Ian King (colin-king) ** Changed in: linux (Ubuntu Zesty) Importance: Undecided => High ** Changed in: linux (Ubuntu Yakkety) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu Zesty) Status: New => Fix Committed ** Changed in: linux (Ubuntu Yakkety) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Committed Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Also affects: linux (Ubuntu Yakkety) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Zesty) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: New Status in linux source package in Zesty: New Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: In Progress Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html This fix re-executes the unsafe check if there is a discrepancy between the expected fs count and the found count during the racy window during thread exec or exit. This re-check occurs very infrequently and saves a lot of addition locking on per thread structures that would make performance of fork/exec/exit prohibitively expensive. == Test case == See the example C code in the patch, https://lists.ubuntu.com/archives /kernel-team/2017-May/084102.html Run the test code as follows: for i in $(seq 1000); do ./a; done With the patch, no messages are emitted, without the patch, one sees a message: "Failed, got euid 1000 (expecting 0)" ..which shows the setuid program failed the check_unsafe_exec() because of the race. == Regression potential == breaking existing safe exec semantics. This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Description changed: + == SRU REQUEST XENIAL, YAKKETY, ZESTY == + + Due to two race conditions in check_unsafe_exec(), exec'ing a setuid + binary from a threaded program sometimes fails to setuid. + + == Fix == + + Sauce patch for Xenial, Yakkety + Zesty: + + https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html + + This fix re-executes the unsafe check if there is a discrepancy between + the expected fs count and the found count during the racy window during + thread exec or exit. This re-check occurs very infrequently and saves a + lot of addition locking on per thread structures that would make + performance of fork/exec/exit prohibitively expensive. + + == Test case == + + See the example C code in the patch, https://lists.ubuntu.com/archives + /kernel-team/2017-May/084102.html + + Run the test code as follows: for i in $(seq 1000); do ./a; done + + With the patch, no messages are emitted, without the patch, one sees a + message: + + "Failed, got euid 1000 (expecting 0)" + + ..which shows the setuid program failed the check_unsafe_exec() because + of the race. + + == Regression potential == + + breaking existing safe exec semantics. + + + This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: - USERPID ACCESS COMMAND - /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio - /dev/snd/controlC0: john 2354 F pulseaudio + USERPID ACCESS COMMAND + /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio + /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: - linux-restricted-modules-4.4.0-64-generic N/A - linux-backports-modules-4.4.0-64-generic N/A - linux-firmware1.157.8 + linux-restricted-modules-4.4.0-64-generic N/A + linux-backports-modules-4.4.0-64-generic N/A + linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: == SRU REQUEST XENIAL, YAKKETY, ZESTY == Due to two race conditions in check_unsafe_exec(), exec'ing a setuid binary from a threaded program sometimes fails to setuid. == Fix == Sauce patch for Xenial, Yakkety + Zesty: https:/
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu Xenial) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
With the kernel from #16 I am no longer able to reproduce the issue, not with the simplified reproducers described in this bug, nor with the original (slower and more convoluted) snapd reproducer. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Incomplete Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
I think I've found the simplest solution that avoids costly locking overhead and seems to work in my tests. I've uploaded the debs for Xenial in: http://kernel.ubuntu.com/~cking/lp-1672819/ Would you mind testing these and seeing if it helps. ** Changed in: linux (Ubuntu Xenial) Status: In Progress => Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Incomplete Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
Re: [Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
On 8 May 2017 at 10:32, Colin Ian King <1672...@bugs.launchpad.net> wrote: > exec'ing from a thread is an interesting problem; the semantics of exec > should be to terminal all the threads before the exec occurs according > to http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_44.html > > The normal idiom would be to do: > fork() > child exec's > parent waits for child > > I'm not sure in your case if you desire all the threads to terminate > after the exec, so the wait() may be in fact be replaced by pthread > termination calls on all the threads for your implementation. > The original bug report was about a process calling execve directly, not a fork/exec situation. So yes, the expectation is that all threads are gone. > Unfortunately there is an issue with fork'ing in a thread; any mutex > held by another thread at the moment of fork becomes locked forever > since we have once mutex locked by the parent and one by the child. > Normally one would therefore use pthread_atfork() to help workaround > this issue, see https://stackoverflow.com/questions/14407544/mixing- > threads-fork-and-mutexes-what-should-i-watch-out-for Go doesn't support forking (except for some very careful code that calls exec in the child), for exactly this sort of reason. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
exec'ing from a thread is an interesting problem; the semantics of exec should be to terminal all the threads before the exec occurs according to http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_44.html The normal idiom would be to do: fork() child exec's parent waits for child I'm not sure in your case if you desire all the threads to terminate after the exec, so the wait() may be in fact be replaced by pthread termination calls on all the threads for your implementation. Unfortunately there is an issue with fork'ing in a thread; any mutex held by another thread at the moment of fork becomes locked forever since we have once mutex locked by the parent and one by the child. Normally one would therefore use pthread_atfork() to help workaround this issue, see https://stackoverflow.com/questions/14407544/mixing- threads-fork-and-mutexes-what-should-i-watch-out-for -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
"to terminal all the threads" should read "to terminate all the threads" -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Tags removed: kernel-key ** Tags added: kernel-da-key -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Bug watch added: Linux Kernel Bug Tracker #195453 http://bugzilla.kernel.org/195453 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This bug has been around since at least 2009. Kernel Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195453 ** Bug watch added: Linux Kernel Bug Tracker #195453 http://bugzilla.kernel.org/195453 ** Also affects: linux via http://bugzilla.kernel.org/195453 Importance: Unknown Status: Unknown ** Bug watch added: Linux Kernel Bug Tracker #195453 http://bugzilla.kernel.org/195453 ** Bug watch added: Linux Kernel Bug Tracker #195453 http://bugzilla.kernel.org/195453 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in Linux: Unknown Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
This also happens on Fedora 25 running 4.10.8-200.fc25.x64_64 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
With the change mentioned in comment #8 I now cannot reproduce the issue. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
Might this be related to https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=857909 ? ** Bug watch added: Debian Bug tracker #857909 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
So the thread fs has been torn down and so t->fs is null which then triggers the miscounting of n_fs; so I'm sspeculating we may need to try: while_each_thread(p, t) { if (t->fs == p->fs || !t->fs) n_fs++; } -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
Nope, that fails too. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
The following seems to fix it, but I need to exercise this a bit more to be 100% certain it is rock solid: diff --git a/fs/fs_struct.c b/fs/fs_struct.c index 7dca743..cd7175e2 100644 --- a/fs/fs_struct.c +++ b/fs/fs_struct.c @@ -98,8 +98,10 @@ void exit_fs(struct task_struct *tsk) int kill; task_lock(tsk); spin_lock(&fs->lock); + rcu_read_lock(); tsk->fs = NULL; kill = !--fs->users; + rcu_read_unlock(); spin_unlock(&fs->lock); task_unlock(tsk); if (kill) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Colin Ian King (colin-king) ** Changed in: linux (Ubuntu Xenial) Status: Triaged => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: In Progress Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Tags removed: kernel-da-key ** Tags added: kernel-key -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Tags removed: kernel-key ** Tags added: kernel-da-key -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
I had a bit of a stare at the kernel source and suspected that the downgrade of uid is happening here: https://github.com/torvalds/linux/blob/v4.4/security/commoncap.c#L547-L548 I added a "WARN(1, "downgrading in subprocess %d %d\n", bprm->unsafe, (int)capable(CAP_SETUID))" which revealed that bprm->unsafe is 1 aka LSM_UNSAFE_SHARE. The only place (I can find) that bprm->unsafe is set to LSM_UNSAFE_SHARE is this check in check_unsafe_exec here (from https://github.com/torvalds/linux/blob/v4.4/fs/exec.c#L1281): t = p; n_fs = 1; spin_lock(&p->fs->lock); rcu_read_lock(); while_each_thread(p, t) { if (t->fs == p->fs) n_fs++; } rcu_read_unlock(); if (p->fs->users > n_fs) bprm->unsafe |= LSM_UNSAFE_SHARE; else p->fs->in_exec = 1; spin_unlock(&p->fs->lock); So I think (and here it gets a bit sketchy) we're racing with copy_process in kernel/fork.c: that calls copy_fs (which is what increments p->fs->users) some way before it does the stuff necessary to make the new thread be included in the while_each_thread(p, t) loop. So n_fs is too low, the check triggers and the setuid bits get ignored. No idea at all how to fix this of course. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
An AWS instance (t2.xlarge with 4 vCPU's) running 4.4.0-1001-aws reproduces the problem: $ for i in `seq 1`; do ./a_p; done | wc -l 124 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
I can reproduce this with the simple pthreads-only reproducer (loop of ./a_p running setuid binary ./b) running 4.4.0-57-generic on bare metal. $ for i in `seq 10`; do ./a_p; done GOT 1000 GOT 1000 $ for i in `seq 1000`; do ./a_p; done | wc -l 117 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
** Changed in: linux (Ubuntu) Status: New => Triaged ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Xenial) Status: New => Triaged ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Tags added: kernel-key -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid
I also tried this in 4.10.0-11-generic, same results. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1672819 Title: exec'ing a setuid binary from a threaded program sometimes fails to setuid Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: This can be reproduced with https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 With that, and go 1.8, if you run “make” and then for i in `seq 99`; do ./a_go; done you'll see a variable number of ”GOT 1000” (or whatever your user id is). If you don't, add one or two more 9s on there. That's a simple go reproducer. You can also use “a_p” instead of “a_go” to see one that only uses pthreads. “a_c” is a C version that does *not* reproduce the issue. But it's not pthreads: if in a_go.go you comment out the “import "C"”, you'll still see the “GOT 1000” messages, in a static binary that uses no pthreads, just clone(2). You'll also see a bunch of warnings because it's not properly handling an EAGAIN from clone, but that's unrelated. If you pin the process to a single thread using taskset, you don't get the issue from a_go; a_p continues to reproduce the issue. In some virtualized environments we haven't been able to reproduce the issue either (e.g. some aws instances), but kvm works (you need -smp to see the issue from a_go). ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-64-generic 4.4.0-64.85 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: john 2354 F...m pulseaudio /dev/snd/controlC0: john 2354 F pulseaudio CurrentDesktop: Unity Date: Tue Mar 14 17:17:23 2017 HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf InstallationDate: Installed on 2014-04-27 (1051 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Latitude E6510 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash RelatedPackageVersions: linux-restricted-modules-4.4.0-64-generic N/A linux-backports-modules-4.4.0-64-generic N/A linux-firmware1.157.8 SourcePackage: linux SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit code 2: UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago) dmi.bios.date: 12/05/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A16 dmi.board.vendor: Dell Inc. dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E6510 dmi.product.version: 0001 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp