All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Galtieri <pgaltieri@mvista.com>
To: Paolo Galtieri <pgaltieri@mvista.com>
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>,
	netdev@vger.kernel.org, sri@us.ibm.com
Subject: Re: Bug in SCTP with SCTP_BINDX_REM_ADDR
Date: Thu, 05 Apr 2007 14:08:41 -0700	[thread overview]
Message-ID: <46156559.3030909@mvista.com> (raw)
In-Reply-To: <46155B49.4030206@mvista.com>

Oops, the patch I sent previously was for an older 2.6 kernel.  I'm 
testing on a 2.6.10+ SCTP patches up to 2.6.17.  Here is a revised patch 
for 2.6.21:

Paolo


Signed-off-by: Paolo Galtieri <pgaltieri@mvista.com>

--- linux-2.6.21/net/sctp/socket.c      2007-03-26 06:58:14.000000000 -0700
+++ linux-2.6.21build/net/sctp/socket.c 2007-04-05 14:04:51.000000000 -0700
@@ -627,6 +627,12 @@ int sctp_bindx_rem(struct sock *sk, stru
                        retval = -EINVAL;
                        goto err_bindx_rem;
                }
+
+               if (!af->addr_valid(sa_addr, sp, NULL)) {
+                       retval = -EADDRNOTAVAIL;
+                       goto err_bindx_rem;
+               }
+
                if (sa_addr->v4.sin_port != htons(bp->port)) {
                        retval = -EINVAL;
                        goto err_bindx_rem;


Paolo Galtieri wrote:
> Here's the revises patch
>
> Paolo
>
> Signed-off-by: Paolo Galtieri <pgaltieri@mvista.com>
>
> --- net/sctp/socket.c.orig      2007-04-05 12:59:15.000000000 -0700
> +++ net/sctp/socket.c   2007-04-05 13:11:37.000000000 -0700
> @@ -627,6 +627,12 @@ int sctp_bindx_rem(struct sock *sk, stru
>                        retval = -EINVAL;
>                        goto err_bindx_rem;
>                }
> +
> +               if (!af->addr_valid(&saveaddr, sp)) {
> +                       retval = -EADDRNOTAVAIL;
> +                       goto err_bindx_rem;
> +               }
> +
>                if (sa_addr->v4.sin_port != htons(bp->port)) {
>                        retval = -EINVAL;
>                        goto err_bindx_rem;
>
>
> Vlad Yasevich wrote:
>> Hi Paolo
>>
>> Paolo Galtieri wrote:
>>> What is happening is that the check for IPV6_ADDR_MAPPED that occurs
>>> during the add is missing when you do the remove and hence the IPv6
>>> address is never mapped to the IPv4 address causing the lookup to
>>> fail.  Below is the patch to add the necessary checks to do the
>>> mapping.  This patch is against 2.6.21-rc5
>>>
>>> Does this make sense?  Any comments are appreciated.
>>>
>>
>> Yes, it makes perfect sense; however, I think you can just use
>> af->addr_valid() instead of adding a special case below.
>>
>> If that works, can you regenerate the patch and provide a
>> Signed-off-by line so I can incorporate that.
>>
>> Thanks
>> -vlad
>>
>>> Thank you,
>>> Paolo
>>>
>>> I've attached the test program - compile as gcc -o bindx-test-ipv6 
>>> bindx-test-ipv6.c -lsctp
>>> ================================ >8 
>>> ==========================================
>>> --- net/sctp/socket.c.orig      2007-04-04 13:22:59.000000000 -0700
>>> +++ net/sctp/socket.c   2007-04-04 13:25:35.000000000 -0700
>>> @@ -627,6 +627,27 @@ int sctp_bindx_rem(struct sock *sk, stru
>>>                        retval = -EINVAL;
>>>                        goto err_bindx_rem;
>>>                }
>>> +               /*
>>> +                * It's possible that we mapped an IPV6 addr to an 
>>> IPV4 addr
>>> +                * during the sctp_bindx_add() operation.  This will 
>>> happen if
>>> +                * the IPV6 address we assigned to an interface is a 
>>> mapped
>>> +                * address, e.g. ::ffff:192.0.2.128.  If we have 
>>> mapped an IPV6
>>> +                * address to an IPV4 address during the add we need 
>>> to make
>>> +                * sure we do the same thing during the remove, 
>>> otherwise we
>>> +                * wont find a match on the address_list.
>>> +                */
>>> +
>>> +               if (af->sa_family == AF_INET6) {
>>> +                       struct in6_addr *in6;
>>> +                       int type;
>>> +
>>> +                       in6 = (struct in6_addr 
>>> *)&sa_addr->v6.sin6_addr;
>>> +                       type = ipv6_addr_type(in6);
>>> +
>>> +                       if (type == IPV6_ADDR_MAPPED)
>>> +                               sctp_v6_map_v4(sa_addr);
>>> +               }
>>> +
>>>                if (sa_addr->v4.sin_port != htons(bp->port)) {
>>>                        retval = -EINVAL;
>>>                        goto err_bindx_rem;
>>>
>>>
>>
>>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

      reply	other threads:[~2007-04-05 21:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 13:34 Bug in SCTP with SCTP_BINDX_REM_ADDR Paolo Galtieri
2007-04-05 19:07 ` Vlad Yasevich
2007-04-05 20:25   ` Paolo Galtieri
2007-04-05 21:08     ` Paolo Galtieri [this message]

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=46156559.3030909@mvista.com \
    --to=pgaltieri@mvista.com \
    --cc=netdev@vger.kernel.org \
    --cc=sri@us.ibm.com \
    --cc=vladislav.yasevich@hp.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.