David Laight writes:
> From: Oleg Nesterov [mailto:o...@redhat.com]
>> Sent: 11 June 2019 19:56
>> On 06/10, Eric W. Biederman wrote:
>> >
>> > Personally I don't think anyone sane would intentionally depend on this
>> > and I don't think ther
David Laight writes:
> From: David Laight
>> Sent: 11 June 2019 10:52
> ...
>> If I have an application that has a loop with a pselect call that
>> enables SIGINT (without a handler) and, for whatever reason,
>> one of the fd is always 'ready' then I'd expect a SIGINT
>> (from ^C) to terminate
David Laight writes:
> From: David Laight
>> Sent: 11 June 2019 10:52
> ...
>> FWIW is ERESTARTNOHAND actually sane here?
>> If I've used setitimer() to get SIGALARM generated every second I'd
>> expect select() to return EINTR every second even if I don't
>> have a SIGALARM handler?
>
>
Arseny Maslennikov writes:
> This complementary patch defines SIGINFO as a synonym for SIGPWR
> on every architecture supported by the kernel.
> The particular signal number chosen does not really matter and is only
> required for the related tty functionality to work properly,
> so if it does
baby in the house.
Eric W. Biederman (1):
signal/ptrace: Don't leak unitialized kernel memory with
PTRACE_PEEK_SIGINFO
Jann Horn (1):
ptrace: restore smp_rmb() in __ptrace_may_access()
kernel/cred.c | 9 +
kernel/ptrace.c | 20 ++--
2 files changed, 27
Oleg Nesterov writes:
> On 06/10, Eric W. Biederman wrote:
>>
>> Personally I don't think anyone sane would intentionally depend on this
>> and I don't think there is a sufficiently reliable way to depend on this
>> by accident that people would actually be depending
syzbot writes:
> syzbot has bisected this bug to:
>
> commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
> Author: John Fastabend
> Date: Sat Jun 30 13:17:47 2018 +
>
> bpf: sockhash fix omitted bucket lock in sock_close
>
> bisection log:
Oleg Nesterov writes:
> On 06/07, Eric W. Biederman wrote:
>>
>> +static int set_sigmask(sigset_t *kmask)
>> +{
>> +set_restore_sigmask();
>> +current->saved_sigmask = current->blocked;
>> +set_current_blocked(kmask);
>> +
>> +
before checking if there was a valid "user" at all
> (which would indicate that the calculations would be sane). Instead,
> delay this check to after seeing a valid "user".
>
> The overflow was real, but the results went unused, so while the flaw
> is harmless
to be used that always tested valid bits.
Now that real_blocked is alwasy valid there is no need
to test something different.
Signed-off-by: "Eric W. Biederman"
---
arch/arc/include/asm/thread_info.h | 1 -
arch/arm/include/asm/thread_info.h | 1 -
arch/arm64/include/asm/thr
We have real_sigmask that serves the same purpose and is always kept
uptodate. Remove a field from the task structure and a conditional
from the signal delivery code by removing this field.
Signed-off-by: "Eric W. Biederman"
---
include/linux/sched.h| 2 --
include/l
. That
should result in a massive simplification.
Signed-off-by: "Eric W. Biederman"
---
kernel/ptrace.c | 1 +
kernel/signal.c | 14 ++
virt/kvm/kvm_main.c | 8
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptra
-by: "Eric W. Biederman"
---
virt/kvm/kvm_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f0d13d9d125d..8575a1010bfc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2240,7 +2240,8 @@ void kvm_sigse
The sigsuspend system call overrides the signal mask just
like all of the other users of set_user_sigmask, so convert
it to use the same helpers.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 43 +++
1 file changed, 19 inserti
in cleaning up the code in this direction?
Eric W. Biederman (5):
signal: Teach sigsuspend to use set_user_sigmask
signal/kvm: Stop using sigprocmask in kvm_sigset_(activate|deactivate)
signal: Always keep real_blocked in sync with blocked
signal: Remove saved_sigmask
Linus Torvalds writes:
> On Fri, Jun 7, 2019 at 10:33 AM Linus Torvalds
> wrote:
>>
>> Are they actually nonrestartable? I think the current EINTR is just a
>> mistake.
>
> Oh, I guess they are, because of the relative timeout thing that
> shouldn't reset to the original value.
>
> And I don't
Linus Torvalds writes:
> On Tue, Jun 4, 2019 at 6:41 AM Oleg Nesterov wrote:
>>
>> This is the minimal fix for stable, I'll send cleanups later.
>
> Ugh. I htink this is correct, but I wish we had a better and more
> intuitive interface.
>
> In particular, since restore_user_sigmask() basically
Andrei Vagin writes:
> On Tue, May 28, 2019 at 6:22 PM Eric W. Biederman
> wrote:
>>
>>
>> Recently syzbot in conjunction with KMSAN reported that
>> ptrace_peek_siginfo can copy an uninitialized siginfo to userspace.
>> Inspecting ptrace_peek_sigi
e the callers.
>
> Reported-by: Eric Wong
> Fixes: 854a6ed56839a40f6b5d02a2962f48841482eec4 ("signal: Add
> restore_user_sigmask()")
> cc: sta...@vger.kernel.org (v5.0+)
> Signed-off-by: Oleg Nesterov
Acked-by: "Eric W. Biederman"
I have read through the patch and it looks good.
For clarity.
Oleg Nesterov writes:
> On 05/30, Eric W. Biederman wrote:
>>
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > Which means I believe we have a semantically valid change in behavior
>> > that is causing a regression.
>>
>>
ebied...@xmission.com (Eric W. Biederman) writes:
> Which means I believe we have a semantically valid change in behavior
> that is causing a regression.
I haven't made a survey of all of the functions yet but
fucntions return -ENORESTARTNOHAND will never return -EINTR and are
immun
Eric Wong writes:
> Agreed... I believe cmogstored has always had a bug in the way
> it uses epoll_pwait because it failed to check interrupts if:
>
> a) an FD is ready + interrupt
> b) epoll_pwait returns 0 on interrupt
>
> The bug remains in userspace for a), which I will fix by adding
> an
Oleg Nesterov writes:
> Al, Linus, Eric, please help.
>
> The previous discussion was very confusing, we simply can not understand each
> other.
>
> To me everything looks very simple and clear, but perhaps I missed something
> obvious? Please correct me.
If I have read this thread correctly
Stephen Rothwell writes:
> Hi Eric,
>
> After merging the userns tree, today's linux-next build (i386 defconfig)
> produced this warning:
>
> arch/x86/mm/fault.c: In function 'do_sigbus':
> arch/x86/mm/fault.c:1017:22: warning: unused variable 'tsk'
> [-Wunused-variable]
> struct task_struct
Arnd Bergmann writes:
> On Wed, May 29, 2019 at 6:12 PM Oleg Nesterov wrote:
>>
>> Al, Linus, Eric, please help.
>>
>> The previous discussion was very confusing, we simply can not understand each
>> other.
>>
>> To me everything looks very simple and clear, but perhaps I missed something
>>
Jann Horn writes:
> I'm actually trying to get rid of the ->mm access in
> __ptrace_may_access() entirely by moving the dumpability and the
> user_ns into the signal_struct, but I don't have patches for that
> ready (yet).
Do you have a plan for dealing with old linux-threads style threads
out what that barrier was
for, and it did not appear necessary.
Do you happen to know of any real world problems?
Reviewed-by: "Eric W. Biederman"
If no one else would prefer to pick this up I will grab it. I have
another bug fix I already queueing for 5.2-rcX.
Thank you,
Eric
>
"Eric W. Biederman" writes:
> Folks,
>
> If folks can look this over and see if I have missed something I would
> appreciate it.
>
> The force_sig_info interface is designed to handle synchronous exceptions
> like page faults. The locking in force_sig_info
Will Deacon writes:
> On Fri, May 24, 2019 at 05:36:41PM -0500, Eric W. Biederman wrote:
>> Will Deacon writes:
>>
>> > On Thu, May 23, 2019 at 03:59:20PM -0500, Eric W. Biederman wrote:
>> >> Will Deacon writes:
>> >>
>> >> > On
Sasha Levin writes:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 6588c1e3ff014 signals: SI_USER: Masquerade si_pid when
> crossing pid ns boundary.
>
> The bot has tested the following trees: v5.1.4, v5.0.18,
I am dropping this one for now, as there are no dependencies with
the other patches, and this probably deserves some discussion on it's
own.
Eric
"Eric W. Biederman" writes:
> Since PTRACE_KILL was introduced in 1.1.78 it has only worked if the
> process is stop
t we have a
type whose maximum value is easy to test for.
Cc: Andrei Vagin
Cc: sta...@vger.kernel.org
Reported-by: syzbot+0d602a1b0d8c95bdf...@syzkaller.appspotmail.com
Fixes: 84c751bd4aeb ("ptrace: add ability to retrieve signals without removing
from a queue (v4)")
Signed-
Andrew,
Didn't someone already provide a fix for this one?
I thought I saw that hit your tree a while ago. I am looking in
ptrace.c and I don't see anything that would have fixed this issue.
If there isn't a fix in the queue I will take a stab at it.
Thank you
Eric
syzbot writes:
>
Christian Brauner writes:
> This adds the clone6 system call.
>
> As mentioned several times already (cf. [7], [8]) here's the promised
> patchset for clone6().
>
> We recently merged the CLONE_PIDFD patchset (cf. [1]). It took the last
> free flag from clone().
>
> Independent of the
Oleg,
Any comments on this patchset?
Eric
Will Deacon writes:
> On Thu, May 23, 2019 at 03:59:20PM -0500, Eric W. Biederman wrote:
>> Will Deacon writes:
>>
>> > On Thu, May 23, 2019 at 11:11:19AM -0500, Eric W. Biederman wrote:
>> >> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/ker
Dave P Martin writes:
> On Thu, May 23, 2019 at 03:53:06PM +0100, Eric W. Biederman wrote:
>> Dave Martin writes:
>>
>> > On Thu, May 23, 2019 at 01:38:53AM +0100, Eric W. Biederman wrote:
>> >> It really only matters to debuggers but the SIGKILL does
Will Deacon writes:
> On Thu, May 23, 2019 at 11:11:19AM -0500, Eric W. Biederman wrote:
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index ade32046f3fe..e45d5b440fb1 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/t
Alan Stern writes:
> On Wed, 22 May 2019, Eric W. Biederman wrote:
>
>> Perhaps this will work as a diagram. I don't know if there is a better
>> way to say it in my patch description. In struct siginfo there are 3
>> fields in fixed positions:
>>
>>
is not misusing the generic code, which
could lead to maintenance problems later.
Cc: sta...@vger.kernel.org
Cc: Dave Martin
Cc: James Morse
Cc: Will Deacon
Fixes: af40ff687bc9 ("arm64: signal: Ensure si_code is valid for all fault
signals")
Signed-off-by: "Eric W. Biederman&quo
Will Deacon writes:
> On Wed, May 22, 2019 at 07:38:53PM -0500, Eric W. Biederman wrote:
>> It really only matters to debuggers but the SIGKILL does not have any
>> si_codes that use the fault member of the siginfo union. Correct this
>> the simple way and c
Dave Martin writes:
> On Thu, May 23, 2019 at 01:38:53AM +0100, Eric W. Biederman wrote:
>> It really only matters to debuggers but the SIGKILL does not have any
>> si_codes that use the fault member of the siginfo union. Correct this
>> the simple way and c
The do_trap function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This also makes it clear that do_trap calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/riscv/include/asm/bug.h | 2 +-
arch/riscv/kern
The __do_user_fault function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This makes it clear that __do_user_fault calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/unicore32/mm/fault.c | 11 ++---
The __do_user_fault function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This makes it clear that __do_user_fault calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/arm/mm/fault.c | 11 ++-
1 file
The send_sigtrap function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This also makes it clear that send_sigtrap always calls
force_sig_fault on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/nds32/kernel/traps.c | 7 -
The force_sig_info_fault function is always called with tsk == current.
Make that explicit by removing the tsk parameter.
This also makes it clear that the sh force_sig_info_fault passes
current into force_sig_fault.
Signed-off-by: "Eric W. Biederman"
---
arch/sh/mm/fault.c | 11
that includes si_uid and si_pid. Therefore we never need
to worry about forcing a signal when si_pid and si_uid are absent.
So handle the two special cases of info and the case when si_pid and
si_uid are present.
Signed-off-by: "Eric W. Biederman"
---
kernel/sig
Any time siginfo is not stored in the signal queue information is
lost. Therefore set TRACE_SIGNAL_LOSE_INFO every time the code does
not allocate a signal queue entry, and a queue overflow abort is not
triggered.
Fixes: ba005e1f4172 ("tracepoint: Add signal loss events")
Signed-off-b
Update the calls of force_sig_fault that pass in a variable that is
set to current earlier to explicitly use current.
This is to make the next change that removes the task parameter
from force_sig_fault easier to verify.
Signed-off-by: "Eric W. Biederman"
---
arch/arc/kernel/tra
can call.
This prepares the way for force_sig_info to have it's task and signal
parameters removed.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index d5
ion ptrace_request always calls
user_enable_single_step on a child that is stopped for tracing. The
child being traced and not reaped ensures that child->sighand is not
NULL, and that the child will not change child->sighand.
Signed-off-by: "Eric W. Biederman"
---
arch/mips/kern
[)]
->
force_sig_fault(\1,\2,\3)
Signed-off-by: "Eric W. Biederman"
---
arch/alpha/kernel/traps.c | 2 +-
arch/alpha/mm/fault.c | 4 +--
arch/arc/kernel/traps.c | 2 +-
arch/arc/mm/fault.c | 4 +--
arch/arm/ke
The send_sigtrap function is always called with task == current. Make
that explicit by removing the task parameter.
This also makes it clear that the uml send_sigtrap passes current
into force_sig_fault.
Signed-off-by: "Eric W. Biederman"
---
arch/um/kernel/ptrace.c | 8 --
In preparation for removing the special case in force_sig_info for
only having a signal number generate an appropriate siginfo in
force_sig the last caller of force_sig_info that does not
pass a filled out siginfo.
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 10
All of the callers pass current into force_sig_mceer so remove the
task parameter to make this obvious.
This also makes it clear that force_sig_mceerr passes current
into force_sig_info.
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/kernel/traps.c| 2 +-
arch/parisc/
The send_sigtrap function is always called with task == current. Make
that explicit by removing the task parameter.
This also makes it clear that the x86 send_sigtrap passes current
into force_sig_fault.
Signed-off-by: "Eric W. Biederman"
---
arch/x86/include/asm/ptrace.h | 3 +--
will not grow any new buggy
callers that attempt to call force_sig on a non-current task, or that
pass an signal number that does not match info.si_signo.
Signed-off-by: "Eric W. Biederman"
---
include/linux/ptrace.h | 2 +-
include/linux/sched/signal.h | 2 +-
kernel
The ptrace_break function is always called with tsk == current.
Make that obvious by removing the tsk parameter.
This also makes it clear that ptrace_break calls force_sig_fault
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/arm/include/asm/traps.h | 2 +-
arch/
All of the remaining callers pass current into force_sig so
remove the task parameter to make this obvious and to make
misuse more difficult in the future.
This also makes it clear force_sig passes current into force_sig_info.
Signed-off-by: "Eric W. Biederman"
---
arch/alpha/kerne
The function force_sigsegv is always called on the current task
so passing in current is redundant and not passing in current
makes this fact obvious.
This also makes it clear force_sigsegv always calls force_sig
on the current task.
Signed-off-by: "Eric W. Biederman"
---
arch/
: Will Deacon
Fixes: af40ff687bc9 ("arm64: signal: Ensure si_code is valid for all fault
signals")
Signed-off-by: "Eric W. Biederman"
---
arch/arm64/kernel/traps.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.
rbd to use force_sig it is
semantically wrong.
With drbd using send_sig it becomes easier to maintain force_sig as only
synchronous signals need to be considered.
Cc: Philipp Reisner
Cc: Lars Ellenberg
Cc: drbd-...@lists.linbit.com
Signed-off-by: "Eric W. Biederman"
---
drive
last force_sig_info
only takes a struct siginfo.
Eric W. Biederman (26):
signal: Correct namespace fixups of si_pid and si_uid
signal/ptrace: Simplify and fix PTRACE_KILL
signal/arm64: Use force_sig not force_sig_fault for SIGKILL
signal/drbd: Use send_sig not force_sig
signal/bpfilter
ignals: SI_USER: Masquerade si_pid when crossing pid ns
boundary")
Fixes: 6b550f949594 ("user namespace: make signal.c respect user namespaces")
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 67 +
1 file changed,
it won't impact the sending of the signal and and because
using force_sig is wrong, replace force_sig with send_sig.
Cc: Daniel Lezcano
Cc: Serge Hallyn
Cc: Oleg Nesterov
Fixes: cf3f89214ef6 ("pidns: add reboot_pid_ns() to handle the reboot syscall")
Signed-off-by: "Eric W. Biederma
37e7 ("cifs: disable sharing session and tcon and add new TCP
sharing code")
Signed-off-by: "Eric W. Biederman"
---
fs/cifs/connect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 8c4121da624e..ed22bffb3fcc 1006
using force_sig is wrong, replace force_sig with send_sig.
Cc: Alexei Starovoitov
Cc: David S. Miller
Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
Signed-off-by: "Eric W. Biederman"
---
net/bpfilter/bpfilter_kern.c | 2 +-
1 file changed, 1 insertion(+),
t;ptrace: fix race between ptrace_resume() and
wait_task_stopped()")
Signed-off-by: "Eric W. Biederman"
---
kernel/ptrace.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 6f3
Alan Stern writes:
> On Tue, 21 May 2019, Eric W. Biederman wrote:
>
>> The usb support for asyncio encoded one of it's values in the wrong
>> field. It should have used si_value but instead used si_addr which is
>> not present in the _rt union member of struct sigin
Alan Stern writes:
> On Tue, 21 May 2019, Eric W. Biederman wrote:
>
>> The usb support for asyncio encoded one of it's values in the wrong
>> field. It should have used si_value but instead used si_addr which is
>> not present in the _rt union member of struct sigin
quot;Waiting for usb disconnect\n");
while (!done) {
sleep(1);
}
close(fd);
return 0;
}
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: Alan Stern
Cc: Oliver Neukum
Fixes: v2.3.39
Cc: sta...@vger.kernel.org
Signed-off-by: "Eric
Jann Horn writes:
>
> In my opinion, CVE-2019-5736 points out two different problems:
>
> The big problem: The __ptrace_may_access() logic has a special-case
> short-circuit for "introspection" that you can't opt out of;
Once upon a time in a galaxy far far away I fixed a bug where we missing
Jeff Mahoney writes:
> On 4/24/18 10:14 AM, Eric W. Biederman wrote:
>> je...@suse.com writes:
>>
>>> From: Jeff Mahoney
>>>
>>> Hi all -
>>>
>>> I recently encountered a customer issue where, on a machine with many TiB
>>>
commit 4ad769f3c346ec3d458e255548dec26ca5284cf6
> Author: Eric W. Biederman
> Date: Tue May 29 14:04:46 2018 +
>
> fuse: Allow fully unprivileged mounts
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16b4518b20
> start commit: 0238df64 Linux 4.19-rc7
Linus Torvalds writes:
> On Wed, Mar 6, 2019 at 5:29 AM Petr Mladek wrote:
>>
>> I wonder if it is "normal" to get panic() when the system is rebooted
>> using "reboot -f". I looks a bit weird to me.
>
> No, a panic is never normal (except possibly for test modules etc, of course).
>
>> Now,
David Howells writes:
The container id details are ludicrous and will break practically
every use case. This completely unacceptable.
Nacked-by: "Eric W. Biederman"
> diff --git a/include/linux/container.h b/include/linux/container.h
> new file mode 100644
> index 000
er in
> case container_chroot() and/or container_pivot_root() are implemented.
If this is desirable we can do this without a ``container''. We already
have mount namespaces.
Nacked-by: "Eric W. Biederman"
In fact if you take care to use a path that starts with '/' the normal
d
ain, int type, int protocol);
>
Nacked-by: "Eric W. Biederman"
Use a namespace file descriptor if you need this. So far we have not
added this system call as it is just a performance optimization. And it
has been too niche to matter.
If this that has changed we can add this sepa
Further attempts to fork into the container will be rejected.
So you are breaking nsenter, and it's like.
There are no technical reasons to disallow this, and may good practical
reasons to allow this.
Nacked-by: "Eric W. Biederman"
> Signed-off-by: David Howells
> ---
>
>
in.
Without the container id living in a container this breaks
nested containers and process migration aka CRIU.
So based on the your description.
Nacked-by: "Eric W. Biederman"
David Howells writes:
> Here's a collection of patches that containerises the kernel keys and makes
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-linus
HEAD:cf43a757fd49442bc38f76088b70c2299eed2c2f signal: Restore the stop
PTRACE_EVENT_EXIT
This includes just a single patch that restores
Oleg Nesterov writes:
> sorry for noise, but after I read the changelog I have a minor nit,
> feel free to ignore...
>
> On 02/12, Eric W. Biederman wrote:
>>
>> Skipping past dequeue_signal when we know a fatal signal has already
>> been delivered resulte
a per thread SIGKILL, by removing SIGKILL
from the per thread signal mask and clearing TIF_SIGPENDING.
Reported-by: Oleg Nesterov
Reported-by: Ivan Delalande
Cc: sta...@vger.kernel.org
Fixes: 35634ffa1751 ("signal: Always notice exiting tasks")
Signed-off-by: "Eric W. Biederman"
--
Oleg Nesterov writes:
> On 02/12, Eric W. Biederman wrote:
>>
>> > Here I was trying for the simple minimal change and I hit this landmine.
>> > Which leaves me with the question of what should be semantics of signal
>> > handling after exit.
>
ebied...@xmission.com (Eric W. Biederman) writes:
> Oleg Nesterov writes:
>
>> sorry again for delay...
>>
>> On 02/07, Eric W. Biederman wrote:
>>>
>>> --- a/kernel/signal.c
>>> +++ b/kernel/signal.c
>>> @@ -2393,6 +2393,11 @@ bool
gt;
> Link: http://lkml.kernel.org/r/20181030180012.232896-1-bmgor...@google.com
> Signed-off-by: Benjamin Gordon
> Acked-by: "Eric W. Biederman"
> Cc: John Stultz
> Cc: "Eric W. Biederman"
> Cc: Kees Cook
> Cc: "Serge E. Hallyn"
> Cc:
Oleg Nesterov writes:
> sorry again for delay...
>
> On 02/07, Eric W. Biederman wrote:
>>
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
>> goto relock;
>> }
>
Oleg Nesterov writes:
> Eric, I'll try to finally read the whole thread later, probably I missed
> something, but...
>
> On 02/07, Eric W. Biederman wrote:
>>
>> Recently syzkaller was able to create unkillablle processes by
>> creating a timer that is deli
Ivan Delalande writes:
> Hi Eric,
>
> On Thu, Feb 07, 2019 at 11:13:59PM -0600, Eric W. Biederman wrote:
>> I just noticed this. From my patch queue that I intend to send to
>> Linus tomorrow. I think this change fixes your issue of getting
>> the SIGSEGV instead o
. Resulting
in an unkillable process in an infinite loop instead of a SIGSEGV and
core dump.
Eric W. Biederman (4):
signal: Make siginmask safe when passed a signal of 0
signal: Always attempt to allocate siginfo for SIGSTOP
signal: Always notice exiting tasks
signal: Better detection
Ivan Delalande writes:
> On Tue, Feb 05, 2019 at 01:11:19PM -0800, Andrew Morton wrote:
>> On Mon, 4 Feb 2019 18:53:08 -0800 Ivan Delalande wrote:
>> > --- a/fs/exec.c
>> > +++ b/fs/exec.c
>> > @@ -1660,7 +1660,12 @@ int search_binary_handler(struct linux_binprm *bprm)
>> >if
space. To allow a proper conversion
of the addresses.
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: Alan Stern
Cc: Oliver Neukum
Fixes: v2.3.39
Cc: sta...@vger.kernel.org
Signed-off-by: "Eric W. Biederman"
---
Can I get someone to test this code? I just discovered th
ugh to prevent all known ways for someone
sending a process signals fast enough to cause unexpected and
arguably incorrect behavior.
Cc: sta...@vger.kernel.org
Fixes: a27341cd5fcb ("Prioritize synchronous signals over 'normal' signals")
Signed-off-by: "Eric W. Biederman"
--
uot;)
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 9ca8e5278c8e..5424cb0006bc 100644
--- a/kerne
before SIGHUP.
Eric W. Biederman (2):
signal: Always notice exiting tasks
signal: Better detection of synchronous signals
signal issue with this change.
> On 02/05, Eric W. Biederman wrote:
>>
>> @@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
>> goto relock;
>> }
>>
>> +/* Has this task already been flagged for death? */
>> +ksig->
Dmitry Vyukov writes:
> On Tue, Feb 5, 2019 at 4:26 PM Eric W. Biederman
> wrote:
>>
>>
>> Recently syzkaller was able to create unkillablle processes by
>> creating a timer that is delivered as a thread local signal on SIGHUP,
>> and receiving SIGHUP SA_N
Stephen Rothwell writes:
> Hi Eric,
>
> In commit
>
> a692933a8769 ("signal: Always attempt to allocate siginfo for SIGSTOP")
>
> Fixes tag
>
> Fixes: 6dfc88977e42 ("[PATCH] shared thread signals")
>
> has these problem(s):
>
> - Target SHA1 does not exist
The SHA1 tag does exist and I
history.git
Signed-off-by: "Eric W. Biederman"
---
Oleg, can you give this a quick review and see if I am missing anything?
Dmitry, can you verify this runs cleanly in your test setups?
fs/coredump.c| 2 +-
include/linux/sched/jobctl.h | 1 +
include/linux/sched/s
601 - 700 of 10702 matches
Mail list logo
