All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: Daniel Borkmann <dborkman@redhat.com>, davem@davemloft.net
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net] net: sctp: fix ABI mismatch through sctp_assoc_to_state helper
Date: Thu, 28 Aug 2014 16:48:40 +0000	[thread overview]
Message-ID: <53FF5D68.80105@gmail.com> (raw)
In-Reply-To: <1409232506-16598-1-git-send-email-dborkman@redhat.com>

On 08/28/2014 09:28 AM, Daniel Borkmann wrote:
> Since SCTP day 1, that is, 19b55a2af145 ("Initial commit") from lksctp
> tree, the official <netinet/sctp.h> header carries a copy of enum
> sctp_sstat_state that looks like (compared to the current in-kernel
> enumeration):
> 
>   User definition:                     Kernel definition:
> 
>   enum sctp_sstat_state {              typedef enum {
>     SCTP_EMPTY             = 0,          <removed>
>     SCTP_CLOSED            = 1,          SCTP_STATE_CLOSED            = 0,
>     SCTP_COOKIE_WAIT       = 2,          SCTP_STATE_COOKIE_WAIT       = 1,
>     SCTP_COOKIE_ECHOED     = 3,          SCTP_STATE_COOKIE_ECHOED     = 2,
>     SCTP_ESTABLISHED       = 4,          SCTP_STATE_ESTABLISHED       = 3,
>     SCTP_SHUTDOWN_PENDING  = 5,          SCTP_STATE_SHUTDOWN_PENDING  = 4,
>     SCTP_SHUTDOWN_SENT     = 6,          SCTP_STATE_SHUTDOWN_SENT     = 5,
>     SCTP_SHUTDOWN_RECEIVED = 7,          SCTP_STATE_SHUTDOWN_RECEIVED = 6,
>     SCTP_SHUTDOWN_ACK_SENT = 8,          SCTP_STATE_SHUTDOWN_ACK_SENT = 7,
>   };                                   } sctp_state_t;
> 
> This header was later on also placed into the uapi, so that user space
> programs can compile without having <netinet/sctp.h>, but the shipped
> with <linux/sctp.h> instead.
> 
> While RFC6458 under 8.2.1.Association Status (SCTP_STATUS) says that
> sstat_state can range from SCTP_CLOSED to SCTP_SHUTDOWN_ACK_SENT, we
> nevertheless have a what it appears to be dummy SCTP_EMPTY state from
> the very early days.
> 
> While it seems to do just nothing, commit 0b8f9e25b0aa ("sctp: remove
> completely unsed EMPTY state") did the right thing and removed this dead
> code. That however, causes an off-by-one when the user asks the SCTP
> stack via SCTP_STATUS API and checks for the current socket state thus
> yielding possibly undefined behaviour in applications as they expect
> the kernel to tell the right thing.
> 
> The enumeration had to be changed however as based on the current socket
> state, we access a function pointer lookup-table through this. Therefore,
> I think the best way to deal with this is just to add a helper function
> sctp_assoc_to_state() to encapsulate the off-by-one quirk.
> 
> Reported-by: Tristan Su <sooqing@gmail.com>
> Fixes: 0b8f9e25b0aa ("sctp: remove completely unsed EMPTY state")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>

Looks good. Thanks.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>

-vlad

WARNING: multiple messages have this Message-ID (diff)
From: Vlad Yasevich <vyasevich@gmail.com>
To: Daniel Borkmann <dborkman@redhat.com>, davem@davemloft.net
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net] net: sctp: fix ABI mismatch through sctp_assoc_to_state helper
Date: Thu, 28 Aug 2014 12:48:40 -0400	[thread overview]
Message-ID: <53FF5D68.80105@gmail.com> (raw)
In-Reply-To: <1409232506-16598-1-git-send-email-dborkman@redhat.com>

On 08/28/2014 09:28 AM, Daniel Borkmann wrote:
> Since SCTP day 1, that is, 19b55a2af145 ("Initial commit") from lksctp
> tree, the official <netinet/sctp.h> header carries a copy of enum
> sctp_sstat_state that looks like (compared to the current in-kernel
> enumeration):
> 
>   User definition:                     Kernel definition:
> 
>   enum sctp_sstat_state {              typedef enum {
>     SCTP_EMPTY             = 0,          <removed>
>     SCTP_CLOSED            = 1,          SCTP_STATE_CLOSED            = 0,
>     SCTP_COOKIE_WAIT       = 2,          SCTP_STATE_COOKIE_WAIT       = 1,
>     SCTP_COOKIE_ECHOED     = 3,          SCTP_STATE_COOKIE_ECHOED     = 2,
>     SCTP_ESTABLISHED       = 4,          SCTP_STATE_ESTABLISHED       = 3,
>     SCTP_SHUTDOWN_PENDING  = 5,          SCTP_STATE_SHUTDOWN_PENDING  = 4,
>     SCTP_SHUTDOWN_SENT     = 6,          SCTP_STATE_SHUTDOWN_SENT     = 5,
>     SCTP_SHUTDOWN_RECEIVED = 7,          SCTP_STATE_SHUTDOWN_RECEIVED = 6,
>     SCTP_SHUTDOWN_ACK_SENT = 8,          SCTP_STATE_SHUTDOWN_ACK_SENT = 7,
>   };                                   } sctp_state_t;
> 
> This header was later on also placed into the uapi, so that user space
> programs can compile without having <netinet/sctp.h>, but the shipped
> with <linux/sctp.h> instead.
> 
> While RFC6458 under 8.2.1.Association Status (SCTP_STATUS) says that
> sstat_state can range from SCTP_CLOSED to SCTP_SHUTDOWN_ACK_SENT, we
> nevertheless have a what it appears to be dummy SCTP_EMPTY state from
> the very early days.
> 
> While it seems to do just nothing, commit 0b8f9e25b0aa ("sctp: remove
> completely unsed EMPTY state") did the right thing and removed this dead
> code. That however, causes an off-by-one when the user asks the SCTP
> stack via SCTP_STATUS API and checks for the current socket state thus
> yielding possibly undefined behaviour in applications as they expect
> the kernel to tell the right thing.
> 
> The enumeration had to be changed however as based on the current socket
> state, we access a function pointer lookup-table through this. Therefore,
> I think the best way to deal with this is just to add a helper function
> sctp_assoc_to_state() to encapsulate the off-by-one quirk.
> 
> Reported-by: Tristan Su <sooqing@gmail.com>
> Fixes: 0b8f9e25b0aa ("sctp: remove completely unsed EMPTY state")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>

Looks good. Thanks.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>

-vlad

  reply	other threads:[~2014-08-28 16:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 13:28 [PATCH net] net: sctp: fix ABI mismatch through sctp_assoc_to_state helper Daniel Borkmann
2014-08-28 13:28 ` Daniel Borkmann
2014-08-28 16:48 ` Vlad Yasevich [this message]
2014-08-28 16:48   ` Vlad Yasevich
2014-08-30  3:31 ` David Miller
2014-08-30  3:31   ` 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=53FF5D68.80105@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.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 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.