| Message ID | ZCZ79IlUW53XxaVr@gauss3.secunet.de (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [ipsec] xfrm: Don't allow optional intermediate templates that changes the address family | expand |
> When an optional intermediate template changes the address family, > it is unclear which family the next template should have. This can > lead to misinterpretations of IPv4/IPv6 addresses. So reject > optional intermediate templates on insertion time. This change breaks the installation of IPv4-in-IPv6 (or vice-versa) policies with IPComp, where the optional IPComp template and SA is installed with tunnel mode (while the ESP template/SA that follows is installed in transport mode) and the address family is that of the SA not that of the policy. Note that mixed-family scenarios with IPComp are currently broken due to an address family issue, but that's a problem in xfrm_tmpl_resolve_one() that occurs later when packets are actually matched against policies. There is a simple patch for it that I haven't got around to submit to the list yet. Regards, Tobias
On Fri, Mar 31, 2023 at 10:19:33AM +0200, Tobias Brunner wrote: > > When an optional intermediate template changes the address family, > > it is unclear which family the next template should have. This can > > lead to misinterpretations of IPv4/IPv6 addresses. So reject > > optional intermediate templates on insertion time. > > This change breaks the installation of IPv4-in-IPv6 (or vice-versa) policies > with IPComp, where the optional IPComp template and SA is installed with > tunnel mode (while the ESP template/SA that follows is installed in > transport mode) and the address family is that of the SA not that of the > policy. > > Note that mixed-family scenarios with IPComp are currently broken due to an > address family issue, but that's a problem in xfrm_tmpl_resolve_one() that > occurs later when packets are actually matched against policies. There is a > simple patch for it that I haven't got around to submit to the list yet. Grmpf, I did a lot of tests, but not IPComp. This means, it might be not so easy to fix the memory corruption I tried to fix with this. Thanks for the heads up!
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index 103af2b3e986..df4e840b630e 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1770,6 +1770,7 @@ static void copy_templates(struct xfrm_policy *xp, struct xfrm_user_tmpl *ut, static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family, struct netlink_ext_ack *extack) { + bool opt_family_change; u16 prev_family; int i; @@ -1778,6 +1779,7 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family, return -EINVAL; } + opt_family_change = false; prev_family = family; for (i = 0; i < nr; i++) { @@ -1791,9 +1793,16 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family, if (!ut[i].family) ut[i].family = family; + if (opt_family_change) { + NL_SET_ERR_MSG(extack, "Optional intermediate templates don't support family changes"); + return -EINVAL; + } + switch (ut[i].mode) { case XFRM_MODE_TUNNEL: case XFRM_MODE_BEET: + if (ut[i].optional && ut[i].family != prev_family) + opt_family_change = true; break; default: if (ut[i].family != prev_family) {
When an optional intermediate template changes the address family, it is unclear which family the next template should have. This can lead to misinterpretations of IPv4/IPv6 addresses. So reject optional intermediate templates on insertion time. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hyunwoo Kim <v4bel@theori.io> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> --- net/xfrm/xfrm_user.c | 9 +++++++++ 1 file changed, 9 insertions(+)