aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet
diff options
context:
space:
mode:
authorDave Barach <dave@barachs.net>2017-06-07 08:18:49 -0400
committerDamjan Marion <dmarion.lists@gmail.com>2017-06-07 13:35:04 +0000
commita62699954a9f57c8407ba10d08636c79166f56ed (patch)
tree9e19c0d40b16199d97bd2d379127218f4d0ab91a /src/vnet
parent7a4e0925f58f04cd31e4c37def959600d888940c (diff)
VPP-873: fix vector expansion bug in dispatch_pending_node
The main interior graph-node dispatch loop had a longstanding dangling vector element reference: 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 (nm->pending_frames + i) 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 during dispatch function execution, 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. Change-Id: Ideb6363bb060c4e8bf9b901882c318bd83853121 Signed-off-by: Dave Barach <dave@barachs.net>
Diffstat (limited to 'src/vnet')
0 files changed, 0 insertions, 0 deletions