netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kazunori MIYAZAWA <kazunori@miyazawa.org>
To: usagi-core@linux-ipv6.org
Cc: miika@iki.fi, Diego.Beltrami@hiit.fi,
	herbert@gondor.apana.org.au, netdev@vger.kernel.org
Subject: Re: (usagi-core 31727) Re: [PATCH][IPSEC][6/7] inter address family ipsec tunnel
Date: Mon, 04 Dec 2006 13:26:29 +0900	[thread overview]
Message-ID: <4573A375.7010100@miyazawa.org> (raw)
In-Reply-To: <20061203.191208.74749805.davem@davemloft.net>

David Miller wrote:
> From: Kazunori MIYAZAWA <kazunori@miyazawa.org>
> Date: Mon, 04 Dec 2006 11:50:09 +0900
> 
>> Thank you for your tracing the bug.
>>
>> I understood the issue.
>> Mmm, if we can not use ut->family, can we use
>> ut->id.family instead?
>>
>> Or is it also uninitialized?
> 
> struct xfrm_id does not have a family field
> 
> struct xfrm_id
> {
> 	xfrm_address_t	daddr;
> 	__be32		spi;
> 	__u8		proto;
> };
> 
> That's what ut->id is.
> 
> You're thinking of xfrm_usersa_id, which is used by
> another structure, xfrm_aevent_id.
> 

Sorry I misread.

> For the time being I'm thinking of using the following
> patch.  I removed the xp->family clobbering, the AF_KEY
> changes don't do this, so there is no reason for the
> xfrm_user side to do it either.
> 
> Every path that leads to copy_templates() will perform
> a validate_tmpl() which will change ut->family == 0
> to the policy's family value.  Any other non-supported
> value will trigger an error.
> 
> Let's hope this fix is sufficient.  I'm about to test
> this now.
> 

Thank you very much.

If uninitialized ut->family is AF_INET or AF_INET6 by chance
and the family of outer addresses (ut->saddr) is differnt
ut->family, it results some garbage in the kernel as you know.

I think it does not results any oops or a segmentation fault
because xfrm_address always has enough length (16 bytes) to wrong
access.

 From the point of view of security, the policy has garbege
templates, but the selector is valid and it mangates applying
IPsec. So it result blocking the traffic.
Accordingly, I think it falls down to secure side.

Anyway I will test the patch.

Thank you,

> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index 6f97665..311205f 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -858,7 +858,6 @@ static void copy_templates(struct xfrm_p
>  	int i;
>  
>  	xp->xfrm_nr = nr;
> -	xp->family = ut->family;
>  	for (i = 0; i < nr; i++, ut++) {
>  		struct xfrm_tmpl *t = &xp->xfrm_vec[i];
>  
> @@ -876,19 +875,53 @@ static void copy_templates(struct xfrm_p
>  	}
>  }
>  
> +static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
> +{
> +	int i;
> +
> +	if (nr > XFRM_MAX_DEPTH)
> +		return -EINVAL;
> +
> +	for (i = 0; i < nr; i++) {
> +		/* We never validated the ut->family value, so many
> +		 * applications simply leave it at zero.  The check was
> +		 * never made and ut->family was ignored because all
> +		 * templates could be assumed to have the same family as
> +		 * the policy itself.  Now that we will have ipv4-in-ipv6
> +		 * and ipv6-in-ipv4 tunnels, this is no longer true.
> +		 */
> +		if (!ut[i].family)
> +			ut[i].family = family;
> +
> +		switch (ut[i].family) {
> +		case AF_INET:
> +			break;
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +		case AF_INET6:
> +			break;
> +#endif
> +		default:
> +			return -EINVAL;
> +		};
> +	}
> +
> +	return 0;
> +}
> +
>  static int copy_from_user_tmpl(struct xfrm_policy *pol, struct rtattr **xfrma)
>  {
>  	struct rtattr *rt = xfrma[XFRMA_TMPL-1];
> -	struct xfrm_user_tmpl *utmpl;
> -	int nr;
>  
>  	if (!rt) {
>  		pol->xfrm_nr = 0;
>  	} else {
> -		nr = (rt->rta_len - sizeof(*rt)) / sizeof(*utmpl);
> +		struct xfrm_user_tmpl *utmpl = RTA_DATA(rt);
> +		int nr = (rt->rta_len - sizeof(*rt)) / sizeof(*utmpl);
> +		int err;
>  
> -		if (nr > XFRM_MAX_DEPTH)
> -			return -EINVAL;
> +		err = validate_tmpl(nr, utmpl, pol->family);
> +		if (err)
> +			return err;
>  
>  		copy_templates(pol, RTA_DATA(rt), nr);
>  	}
> @@ -1530,7 +1563,8 @@ static int xfrm_add_acquire(struct sk_bu
>  	}
>  
>  	/*   build an XP */
> -	xp = xfrm_policy_construct(&ua->policy, (struct rtattr **) xfrma, &err);        if (!xp) {
> +	xp = xfrm_policy_construct(&ua->policy, (struct rtattr **) xfrma, &err);
> +	if (!xp) {
>  		kfree(x);
>  		return err;
>  	}
> @@ -1979,7 +2013,7 @@ #endif
>  		return NULL;
>  
>  	nr = ((len - sizeof(*p)) / sizeof(*ut));
> -	if (nr > XFRM_MAX_DEPTH)
> +	if (validate_tmpl(nr, ut, p->sel.family))
>  		return NULL;
>  
>  	if (p->dir > XFRM_POLICY_OUT)
> 
> 


  parent reply	other threads:[~2006-12-04  4:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-24  5:39 [PATCH][IPSEC][6/7] inter address family ipsec tunnel Kazunori MIYAZAWA
2006-12-01  1:05 ` David Miller
2006-12-01  5:07   ` Kazunori MIYAZAWA
2006-12-04  1:58     ` David Miller
2006-12-04  2:28       ` David Miller
2006-12-04  2:50         ` Kazunori MIYAZAWA
2006-12-04  3:12           ` David Miller
2006-12-04  3:30             ` Herbert Xu
2006-12-04  4:26             ` Kazunori MIYAZAWA [this message]
2006-12-04  6:33               ` (usagi-core 31727) " David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4573A375.7010100@miyazawa.org \
    --to=kazunori@miyazawa.org \
    --cc=Diego.Beltrami@hiit.fi \
    --cc=herbert@gondor.apana.org.au \
    --cc=miika@iki.fi \
    --cc=netdev@vger.kernel.org \
    --cc=usagi-core@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).