GLib may busy loop on invalid file descriptors

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

GLib may busy loop on invalid file descriptors

Benjamin Berg
Hi,

I ran into an issue the other day where abrtd was polling an invalid
file descriptor. Obviously, there must be a bug in abrtd which closed
the wrong FD even though it was still registered with the mainloop
using g_io_channel_unix_new and g_io_add_watch. However, the failure
mode of GLib to simply busy loop seems quite bad.

Should g_io_unix_check maybe react to (G_IO_HUP | G_IO_ERR | G_IO_NVAL)
in a way that results in an error and the removal of the source? That
is, effectively run a fallback handler application is watching these
error conditions.

A viable solution might be:
 * Return TRUE from g_io_unix_check by always checking for the errors
 * Test again in g_io_unix_dispatch but log an error and return FALSE
   if none of the requested conditions match.

Thoughts?

Benjamin

PS: https://github.com/abrt/abrt/issues/1280 has some info on the
specific issue.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLib may busy loop on invalid file descriptors

Frediano Ziglio
>
> Hi,
>
> I ran into an issue the other day where abrtd was polling an invalid
> file descriptor. Obviously, there must be a bug in abrtd which closed
> the wrong FD even though it was still registered with the mainloop
> using g_io_channel_unix_new and g_io_add_watch. However, the failure
> mode of GLib to simply busy loop seems quite bad.
>
> Should g_io_unix_check maybe react to (G_IO_HUP | G_IO_ERR | G_IO_NVAL)
> in a way that results in an error and the removal of the source? That
> is, effectively run a fallback handler application is watching these
> error conditions.
>
> A viable solution might be:
>  * Return TRUE from g_io_unix_check by always checking for the errors
>  * Test again in g_io_unix_dispatch but log an error and return FALSE
>    if none of the requested conditions match.
>
> Thoughts?
>
> Benjamin
>
> PS: https://github.com/abrt/abrt/issues/1280 has some info on the
> specific issue.

The problem is similar to a double free. In that case I would personally
abort the program. If GLib really care about security trying to recovery
is a bad idea.

Frediano
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib may busy loop on invalid file descriptors

Dan Winship-2
In reply to this post by Benjamin Berg
On 12/22/2017 06:09 AM, Benjamin Berg wrote:

> Hi,
>
> I ran into an issue the other day where abrtd was polling an invalid
> file descriptor. Obviously, there must be a bug in abrtd which closed
> the wrong FD even though it was still registered with the mainloop
> using g_io_channel_unix_new and g_io_add_watch. However, the failure
> mode of GLib to simply busy loop seems quite bad.
>
> Should g_io_unix_check maybe react to (G_IO_HUP | G_IO_ERR | G_IO_NVAL)
> in a way that results in an error and the removal of the source? That
> is, effectively run a fallback handler application is watching these
> error conditions.
>
> A viable solution might be:
>  * Return TRUE from g_io_unix_check by always checking for the errors
>  * Test again in g_io_unix_dispatch but log an error and return FALSE
>    if none of the requested conditions match.
>
> Thoughts?

FWIW I suggested more or less the same thing a long time ago but
eventually convinced myself was the wrong fix:
https://bugzilla.gnome.org/show_bug.cgi?id=321746

-- Dan

> Benjamin
>
> PS: https://github.com/abrt/abrt/issues/1280 has some info on the
> specific issue.
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list