Hello,
I reviewed current upstream `master` on 2026-03-16 and found that the IKEv2 API dump path still copies variable-length key vectors into fixed `64`-byte API arrays without any clamp.
In current `src/plugins/ikev2/ikev2_api.c`, the `send_sa()` family still contains:
```c
k->sk_d_len = vec_len(sa->sk_d);
clib_memcpy(&k->sk_d, sa->sk_d, k->sk_d_len);
k->sk_ai_len = vec_len(sa->sk_ai);
clib_memcpy(&k->sk_ai, sa->sk_ai, k->sk_ai_len);
k->sk_ar_len = vec_len(sa->sk_ar);
clib_memcpy(&k->sk_ar, sa->sk_ar, k->sk_ar_len);
```
I also checked the current API type definition in `src/plugins/ikev2/ikev2_types.api`, which still defines:
```c
typedef ikev2_keys
{
u8 sk_d[64];
u8 sk_d_len;
u8 sk_ai[64];
u8 sk_ai_len;
u8 sk_ar[64];
u8 sk_ar_len;
u8 sk_ei[64];
u8 sk_ei_len;
u8 sk_er[64];
u8 sk_er_len;
u8 sk_pi[64];
u8 sk_pi_len;
u8 sk_pr[64];
u8 sk_pr_len;
};
```
So current head still has a direct copy from dynamic `vec_len()`-sized internal SA vectors into fixed `64`-byte API arrays, with no `clib_min()` or equivalent bound before the copy.
That means any key vector longer than `64` bytes overwrites:
1. its own adjacent `*_len` field first, and then
2. the following key arrays inside the same `vl_api_ikev2_keys_t` object.
This is a real current-head API serialization bug. I am not overclaiming the trigger surface; the claim is simply that the dump path still lacks the defensive bound that the fixed API layout requires.
The minimal fix is to clamp each copy, for example:
```c
u32 len = vec_len(sa->sk_d);
k->sk_d_len = clib_min(len, sizeof(k->sk_d));
clib_memcpy(&k->sk_d, sa->sk_d, k->sk_d_len);
```
and apply the same pattern to the other key fields.
Best regards
Pengpeng Hou
