[wp-trac] [WordPress Trac] #56926: Infinite loop in wp_nav_menu

[WordPress Trac]

#56926: Infinite loop in wp_nav_menu
-------------------------------------------------+-------------------------
 Reporter:  david.binda                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  6.1.1
Component:  Menus                                |     Version:  6.1
 Severity:  normal                               |  Resolution:
 Keywords:  reporter-feedback has-patch has-     |     Focuses:
  unit-tests                                     |
-------------------------------------------------+-------------------------

Comment (by david.binda):

 Sorry for the delay here. There seem to be more instances of the nav menu
 items which have their own ID set as their parent, thus running into the
 infinite loop (and ultimately either to out of memory error, or timing out
 a request) in the code mentioned in this ticket.

 I still haven't figured out how exactly such situation happens, but have
 been able to pin-point that it happens in customizer on the frontend side
 of things.

 Adding a logging for cases when the `_menu_item_menu_item_parent` meta is
 set to the same `object_id`, all I got were requests from customizer when
 updating a nav menu:


 {{{
 do_action('wp_ajax_customize_save'), WP_Hook->do_action,
 WP_Hook->apply_filters, WP_Customize_Manager->save,
 WP_Customize_Manager->save_changeset_post, wp_insert_post,
 wp_transition_post_status, do_action('transition_post_status'),
 WP_Hook->do_action, WP_Hook->apply_filters,
 _wp_customize_publish_changeset,
 WP_Customize_Manager->_publish_changeset_values,
 WP_Customize_Setting->save, WP_Customize_Nav_Menu_Item_Setting->update,
 wp_update_nav_menu_item, update_post_meta, update_metadata
 }}}

 Further, the payload, data passed in via `$_POST['customized']`, already
 contains the bad data, so the corruption, IMHO, happens on the JavaScript
 side of things while working in customizer.

 It's still unclear to me how exactly it happens (I had no luck attempting
 to reproduce it), but it feels like it might be beneficial to have some
 more safe-guards, and perhaps even a server-side validation, for the
 `menu_item_parent` value (eg.: for it to not point to the nav menu item
 itself). But even if such safe-guars were added, there are still going to
 be such instances in the wild, so, from my point of view, we should still
 take such situation into consideration in any code working with the
 `_menu_item_menu_item_parent` meta.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56926#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform