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 <buga...@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);
