[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH glibc 25/34] hurd: Improve reply port handling when exiti
From: |
Samuel Thibault |
Subject: |
Re: [RFC PATCH glibc 25/34] hurd: Improve reply port handling when exiting signal handlers |
Date: |
Thu, 13 Apr 2023 00:54:30 +0200 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Hello,
Sergey Bugaev, le dim. 19 mars 2023 18:10:08 +0300, a ecrit:
> Also, use mach_port_mod_refs () and not mach_port_destroy () to destroy
> the receive right. mach_port_destroy () should *never* be used on
> mach_task_self (); this can easily lead to port use-after-free
> vulnerabilities if the task has any other references to the same port.
I had to revert the sigreturn part of this, it was making
signal/tst-signal signal/tst-raise signal/tst-minsigstksz-5
htl/tst-raise1 fail.
> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
> ---
>
> NOTE: I don't really understand why sigunwind wants to destroy both its
> current reply port and user's reply port. Prior to commit
> fb304035c41c7ee2afede51e5e8568974549ba5e, it was *restoring* the user's
> reply port, in which case it actually made sense to destroy the current
> reply port. Post-fb304035c41c7ee2afede51e5e8568974549ba5e, wouldn't it
> be better to just keep using the current reply port, destroying the
> user's one?
>
> hurd/sigunwind.c | 24 +++++++++++-------------
> sysdeps/mach/hurd/i386/sigreturn.c | 21 +++++----------------
> 2 files changed, 16 insertions(+), 29 deletions(-)
>
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index db1a01f3..29c9629f 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn.c
> +++ b/sysdeps/mach/hurd/i386/sigreturn.c
> @@ -101,20 +100,10 @@ __sigreturn (struct sigcontext *scp)
>
> /* Destroy the MiG reply port used by the signal handler, and restore the
> reply port in use by the thread when interrupted. */
[...]
> - __mach_port_destroy (__mach_task_self (), port);
> + __mach_port_mod_refs (__mach_task_self (), reply_port,
> + MACH_PORT_RIGHT_RECEIVE, -1);