Uploaded image for project: 'vpp'
  1. vpp
  2. VPP-873

fix vector expansion bug in dispatch_pending_node

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Highest Highest
    • 17.07
    • None
    • None

      The main interior graph-node dispatch loop has an ages-old dangling vector references:

      for (i = 0; i < _vec_len (nm->pending_frames); i++)
         cpu_time_now = dispatch_pending_node (vm, nm->pending_frames + i,
                                     cpu_time_now);

      Passing a pointer to a vector element has considerable comedic potential if there's any chance that the vector could expand. 

      dispatch_pending_node() calls dispatch_node() - and indirectly any interior graph node dispatch function. If that node happens to expand nm->pending_frames by filling in a new frame, nm->pending_frames can expand.

      After calling the node dispatch function, dispatch_node() does the following: 

      nf = vec_elt_at_index (nm->next_frames, p->next_frame_index);

      If nm->pending_frames expands, p is a dangling reference to freed memory. By luck, the TCP stack managed to allocate a fresh frame which included "old-p," which caused p->next_frame_index to be filled with the new-frame poison pattern 0xfefefefe.

      This has been broken from day 1, summer 2007, first use of the third-generation vector processing library

       

       

       

            dbarach Dave Barach
            dbarach Dave Barach
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 day
                1d