bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

port leak in select


From: Samuel Thibault
Subject: port leak in select
Date: Fri, 2 Dec 2016 08:41:21 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Hello,

About the port leak in select discussed on IRC, I checked history a bit,
this (000ef460744786571f51604e6de631b7168e239a):

-      if (d[i].type)
+      if (d[i].type & ~SELECT_ERROR)
        __mach_port_destroy (__mach_task_self (), d[i].reply_port);

was added when handling EBADF , for which there is no reply port to
destroy. Then I added this (099f8d2b7ecedc4f6fc895d2c35912f995289c24):

-      if (d[i].type & ~SELECT_ERROR)
+      if (d[i].type & ~(SELECT_ERROR | SELECT_RETURNED))
        __mach_port_destroy (__mach_task_self (), d[i].reply_port);

For the case where io_select returns an error.  Yesterday evening I
didn't remember which case this was, but IIRC that's when a tty gets
io_revoke()d, in which case the RPC doesn't happen at all since the
target port was destroyed.


I guess we could simply do this:

      for (i = firstfd; i <= lastfd; ++i)
-             if (d[i].type & ~SELECT_ERROR)
+             if (d[i].type & SELECT_ERROR)
+               {
+                 d[i].reply_port = MACH_PORT_NULL;
+               }
              else
                {
                  int type = d[i].type;
                  d[i].reply_port = __mach_reply_port ();

as well as in the error case of __io_select_request, and then just check
against MACH_PORT_NULL before destroy.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]