On Mon, Nov 27, 2017 at 11:39:40AM +0100, Florian Westphal wrote:
> Steffen Klassert <steffen.klassert@xxxxxxxxxxx> wrote:
> >
> > Florian, could you please give the patch blelow a try?
>
> Doesn't help.
Thanks for testing!
>
> > static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
> > {
> > + u16 prev_family;
> > int i;
> >
> > if (nr > XFRM_MAX_DEPTH)
> > return -EINVAL;
> >
> > + prev_family = family;
>
> family is AF_INET6 (10), nr is 1.
>
> > for (i = 0; i < nr; i++) {
> > /* We never validated the ut->family value, so many
> > * applications simply leave it at zero. The check was
> > @@ -1435,6 +1438,12 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
> > if (!ut[i].family)
> > ut[i].family = family;
> >
> > + if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
> > + (ut[i].family != prev_family))
> > + return -EINVAL;
>
> mode is XFRM_MODE_TRANSPORT, family == prev_family (10), so no
> -EINVAL here.
>
> Socket is AF_INET6.
> setsockopt(3, SOL_IPV6, 0x23 /* IPV6_??? */, ...
> sendto(3, "", 0, MSG_EOR|MSG_NOSIGNAL|0x10, {sa_family=AF_INET,
> sin_port=htons(20002), sin_addr=inet_addr("0.0.0.0")}, 16) = -1
> EAGAIN (Resource temporarily unavailable)
>
> and then used with AF_INET address, which causes the KASAN warning
> as we feed xfrm_state_find with on-stack ipv4 addresses.
This means that a policy with IPv6 selector matched an IPv4 flow, hmm.
This is probably because most selector fields are wildcard. We could
catch this by checking the address families of selector and flow
in xfrm_sk_policy_lookup() before the policy match().
I'll try to get the reproducer to work here so that I don't need
to bother you with this, thanks again!