In any case I agree with emilio's assessment on that bug, that this seems to be a UAF in GTK code rather than in Firefox code. Here's a recent crash report, so we have a concrete backtrace to reason about: bp-1b8c13ce-919c-47b9-b49e-3a2290231206 Top 10 frames of crashing thread: ``` 0 libgtk-3.so.0 gtk_printer_get_name gtk/gtkprinter.c:436 1 libprintbackend-cups.so find_printer modules/printbackends/cups/gtkprintbackendcups.c:1874 2 libglib-2.0.so.0 g_list_find_custom glib/glist.c:922 3 libprintbackend-cups.so cups_request_printer_list_cb modules/printbackends/cups/gtkprintbackendcups.c:3630 4 libprintbackend-cups.so cups_dispatch_watch_dispatch modules/printbackends/cups/gtkprintbackendcups.c:1581 5 libglib-2.0.so.0 g_main_dispatch glib/gmain.c:3309 5 libglib-2.0.so.0 g_main_context_dispatch glib/gmain.c:3974 6 libglib-2.0.so.0 g_main_context_iterate glib/gmain.c:4047 7 libglib-2.0.so.0 g_main_loop_run glib/gmain.c:4241 8 libgtk-3.so.0 gtk_enumerate_printers gtk/gtkprinter.c:1285 ``` I'm using the Linux Mint source on github as a reference for this GTK/cups code, since it's one of the first easily-linkable copies that I could find that has many/most of these source files (though line numbers might not match up exactly due to version differences). The innermost function in the backtrace is https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/gtk/gtkprinter.c#L434-L436 ```c const gchar * gtk_printer_get_name (GtkPrinter *printer) { g_return_val_if_fail (GTK_IS_PRINTER (printer), NULL); return printer->priv->name; } ``` The only object that could conceivably cause a UAF there is the `GtkPrinter *printer` parameter itself, or possibly its `priv` member (i.e. if `printer-priv` is pointing at an object that's been deleted and filled with garbage). Going up a few stack levels, this `printer` arg seems to come from a linked-list, `removed_printer_checklist`, that CUPS code gets and iterates-across in `cups_request_printer_list_cb`. That list gets assigned here: ```c removed_printer_checklist = gtk_print_backend_get_printer_list (backend); ``` https://github.com/linuxmint/gtk/blob/master/modules/printbackends/cups/gtkprintbackendcups.c#L3244C1-L3248C76 ...and then cups iterates over it here (and we crash during this iteration; note `g_list_find_custom` in the backtrace, calling the passed-in function pointer `find_printer`): ```c /* remove name from checklist if it was found */ node = g_list_find_custom (removed_printer_checklist, info->printer_name, (GCompareFunc) find_printer); removed_printer_checklist = g_list_delete_link (removed_printer_checklist, node); ``` https://github.com/linuxmint/gtk/blob/master/modules/printbackends/cups/gtkprintbackendcups.c#L3326-L3331 That iteration does seem to be deleting things as it goes. So a UAF here would suggest that there's a cycle in that list, or perhaps two `printer` objects that somehow share the same `priv` pointer (if `printer->priv` is the deleted thing rather than `printer`). Anyway: Gecko doesn't manage the lifetime of any of these objects, so I think it's pretty clear that the UAF here is a cups or gtk bug, and not a Gecko bug.
Bug 1660223 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
In any case I agree with emilio's assessment on that bug, that this seems to be a UAF in GTK code rather than in Firefox code. Here's a recent crash report, so we have a concrete backtrace to reason about: bp-1b8c13ce-919c-47b9-b49e-3a2290231206 Top 10 frames of crashing thread: ``` 0 libgtk-3.so.0 gtk_printer_get_name gtk/gtkprinter.c:436 1 libprintbackend-cups.so find_printer modules/printbackends/cups/gtkprintbackendcups.c:1874 2 libglib-2.0.so.0 g_list_find_custom glib/glist.c:922 3 libprintbackend-cups.so cups_request_printer_list_cb modules/printbackends/cups/gtkprintbackendcups.c:3630 4 libprintbackend-cups.so cups_dispatch_watch_dispatch modules/printbackends/cups/gtkprintbackendcups.c:1581 5 libglib-2.0.so.0 g_main_dispatch glib/gmain.c:3309 5 libglib-2.0.so.0 g_main_context_dispatch glib/gmain.c:3974 6 libglib-2.0.so.0 g_main_context_iterate glib/gmain.c:4047 7 libglib-2.0.so.0 g_main_loop_run glib/gmain.c:4241 8 libgtk-3.so.0 gtk_enumerate_printers gtk/gtkprinter.c:1285 ``` I'm using the Linux Mint source on github as a reference for this GTK/cups code, since it's one of the first easily-linkable copies that I could find that has many/most of these source files (though line numbers might not match up exactly due to version differences). The innermost function in the backtrace is https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/gtk/gtkprinter.c#L434-L436 ```c const gchar * gtk_printer_get_name (GtkPrinter *printer) { g_return_val_if_fail (GTK_IS_PRINTER (printer), NULL); return printer->priv->name; } ``` The only object that could conceivably cause a UAF there is the `GtkPrinter *printer` parameter itself, or possibly its `priv` member (i.e. if `printer-priv` is pointing at an object that's been deleted and filled with garbage). Going up a few stack levels, this `printer` arg seems to come from a linked-list, `removed_printer_checklist`, that CUPS code gets and iterates-across in `cups_request_printer_list_cb`. That list gets assigned here: ```c removed_printer_checklist = gtk_print_backend_get_printer_list (backend); ``` https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/modules/printbackends/cups/gtkprintbackendcups.c#L3244C1-L3248C76 ...and then cups iterates over it here (and we crash during this iteration; note `g_list_find_custom` in the backtrace, calling the passed-in function pointer `find_printer`): ```c /* remove name from checklist if it was found */ node = g_list_find_custom (removed_printer_checklist, info->printer_name, (GCompareFunc) find_printer); removed_printer_checklist = g_list_delete_link (removed_printer_checklist, node); ``` https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/modules/printbackends/cups/gtkprintbackendcups.c#L3326-L3331 That iteration does seem to be deleting things as it goes. So a UAF here would suggest that there's a cycle in that list, or perhaps two `printer` objects that somehow share the same `priv` pointer (if `printer->priv` is the deleted thing rather than `printer`). Anyway: Gecko doesn't manage the lifetime of any of these objects, so I think it's pretty clear that the UAF here is a cups or gtk bug, and not a Gecko bug.
In any case I agree with emilio's assessment on that bug, that this seems to be a UAF in GTK code rather than in Firefox code. Here's a recent crash report, so we have a concrete backtrace to reason about: bp-1b8c13ce-919c-47b9-b49e-3a2290231206 Top 10 frames of crashing thread: ``` 0 libgtk-3.so.0 gtk_printer_get_name gtk/gtkprinter.c:436 1 libprintbackend-cups.so find_printer modules/printbackends/cups/gtkprintbackendcups.c:1874 2 libglib-2.0.so.0 g_list_find_custom glib/glist.c:922 3 libprintbackend-cups.so cups_request_printer_list_cb modules/printbackends/cups/gtkprintbackendcups.c:3630 4 libprintbackend-cups.so cups_dispatch_watch_dispatch modules/printbackends/cups/gtkprintbackendcups.c:1581 5 libglib-2.0.so.0 g_main_dispatch glib/gmain.c:3309 5 libglib-2.0.so.0 g_main_context_dispatch glib/gmain.c:3974 6 libglib-2.0.so.0 g_main_context_iterate glib/gmain.c:4047 7 libglib-2.0.so.0 g_main_loop_run glib/gmain.c:4241 8 libgtk-3.so.0 gtk_enumerate_printers gtk/gtkprinter.c:1285 ``` I'm using the Linux Mint source on github as a reference for this GTK/cups code, since it's one of the first easily-linkable copies that I could find that has many/most of these source files (though line numbers might not match up exactly due to version differences). The innermost function in the backtrace is https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/gtk/gtkprinter.c#L434-L436 ```c const gchar * gtk_printer_get_name (GtkPrinter *printer) { g_return_val_if_fail (GTK_IS_PRINTER (printer), NULL); return printer->priv->name; } ``` The only object that could conceivably cause a UAF there is the `GtkPrinter *printer` parameter itself, or possibly its `priv` member (i.e. if `printer-priv` is pointing at an object that's been deleted and filled with garbage). Going up a few stack levels, this `printer` arg seems to come from a linked-list, `removed_printer_checklist`, that CUPS code gets and iterates-across in `cups_request_printer_list_cb`. That list gets assigned here: ```c removed_printer_checklist = gtk_print_backend_get_printer_list (backend); ``` https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/modules/printbackends/cups/gtkprintbackendcups.c#L3244C1-L3248C76 ...and then cups iterates over it here (and we crash during this iteration; note `g_list_find_custom` in the backtrace, calling the passed-in function pointer `find_printer`): ```c /* remove name from checklist if it was found */ node = g_list_find_custom (removed_printer_checklist, info->printer_name, (GCompareFunc) find_printer); removed_printer_checklist = g_list_delete_link (removed_printer_checklist, node); ``` https://github.com/linuxmint/gtk/blob/158a2b0e1e8d582bc041acc7fe323922747d7787/modules/printbackends/cups/gtkprintbackendcups.c#L3326-L3331 That iteration does seem to be deleting things as it goes. So a UAF here would suggest that there's a cycle in that list, or perhaps two `printer` objects that somehow share the same `priv` pointer (if `printer->priv` is the deleted thing rather than `printer`). Or just an entry in that list that's got a bogus pointer-to-deleted-data for other reasons. Anyway: Gecko doesn't manage the lifetime of any of these objects, so I think it's pretty clear that the UAF here is a cups or gtk bug, and not a Gecko bug.