ipsec: fix trace of GRE_teb packets 61/28661/3
authorChristian Hopps <chopps@labn.net>
Tue, 25 Aug 2020 16:40:40 +0000 (12:40 -0400)
committerNeale Ranns <nranns@cisco.com>
Fri, 4 Sep 2020 11:56:06 +0000 (11:56 +0000)
The issue is not easily hit. When GRE_teb packets are received the post
crypto processing adjusts the l2.l2_len value in the vnet_buffer opaque
data. This is overwriting the ipsec opaque data. Later the trace code
fetches the sa_index from the ipsec opaque data. It's just an accident
that this currently works, if the ipsec data is changed so that the
sa_index moves around it will be overwritten by the l2_len modification.
Indeed, this was found b/c local development changes had moved the
sa_index so it was over-lapping with the l2_len memory space, and the UT
failed.

Type: fix
Change-Id: Iaecfa750cf0b36653fd9e75b4d799f323a14d932
Signed-off-by: Christian Hopps <chopps@labn.net>
src/vnet/ipsec/esp_decrypt.c

index b3c031e..75092cc 100644 (file)
@@ -1265,6 +1265,10 @@ esp_decrypt_inline (vlib_main_t * vm,
                         CLIB_CACHE_LINE_BYTES * 2, LOAD);
        }
 
+      /* save the sa_index as GRE_teb post_crypto changes L2 opaque */
+      if (PREDICT_FALSE (b[0]->flags & VLIB_BUFFER_IS_TRACED))
+       current_sa_index = vnet_buffer (b[0])->ipsec.sad_index;
+
       if (next[0] >= ESP_DECRYPT_N_NEXT)
        esp_decrypt_post_crypto (vm, node, pd, pd2, b[0], next, is_ip6,
                                 is_tun, 0);
@@ -1274,8 +1278,7 @@ esp_decrypt_inline (vlib_main_t * vm,
        {
          esp_decrypt_trace_t *tr;
          tr = vlib_add_trace (vm, node, b[0], sizeof (*tr));
-         sa0 = pool_elt_at_index (im->sad,
-                                  vnet_buffer (b[0])->ipsec.sad_index);
+         sa0 = pool_elt_at_index (im->sad, current_sa_index);
          tr->crypto_alg = sa0->crypto_alg;
          tr->integ_alg = sa0->integ_alg;
          tr->seq = pd->seq;