[PATCH] sctp: fix a potential missing-check bug

[PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
and max_len to check whether it is in the appropriate range. If it is not,
an error code -EINVAL will be returned. This is enforced by a security
check. But, this check is only executed when 'val' is not 0. In fact, if
'val' is 0, it will be assigned with a new value (if the return value of
the function sctp_id2assoc() is not 0) in the following execution. However,
this new value of 'val' is not checked before it is used to assigned to
asoc->user_frag. That means it is possible that the new value of 'val'
could be out of the expected range. This can cause security issues
such as buffer overflows, e.g., the new value of 'val' is used as an index
to access a buffer.

This patch inserts a check for the new value of 'val' to see if it is in
the expected range. If it is not, an error code -EINVAL will be returned.

Signed-off-by: Wenwen Wang <wang6495@umn.edu>
---
 net/sctp/socket.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 80835ac..03e1cc3 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3212,6 +3212,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 	struct sctp_af *af = sp->pf->af;
 	struct sctp_assoc_value params;
 	struct sctp_association *asoc;
+	int min_len, max_len;
 	int val;
 
 	if (optlen == sizeof(int)) {
@@ -3231,19 +3232,15 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 		return -EINVAL;
 	}
 
-	if (val) {
-		int min_len, max_len;
+	min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
+	min_len -= af->ip_options_len(sk);
+	min_len -= sizeof(struct sctphdr) +
+		   sizeof(struct sctp_data_chunk);
 
-		min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
-		min_len -= af->ip_options_len(sk);
-		min_len -= sizeof(struct sctphdr) +
-			   sizeof(struct sctp_data_chunk);
+	max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
 
-		max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
-
-		if (val < min_len || val > max_len)
-			return -EINVAL;
-	}
+	if (val && (val < min_len || val > max_len))
+		return -EINVAL;
 
 	asoc = sctp_id2assoc(sk, params.assoc_id);
 	if (asoc) {
@@ -3253,6 +3250,9 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 			val -= sizeof(struct sctphdr) +
 			       sctp_datachk_len(&asoc->stream);
 		}
+		/* Check the new val to make sure it is in the range. */
+		if (val < min_len || val > max_len)
+			return -EINVAL;
 		asoc->user_frag = val;
 		asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
 	} else {
-- 
2.7.4

Re: [PATCH] sctp: fix a potential missing-check bug

[Marcelo Ricardo Leitner]

On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
> and max_len to check whether it is in the appropriate range. If it is not,
> an error code -EINVAL will be returned. This is enforced by a security
> check. But, this check is only executed when 'val' is not 0. In fact, if
> 'val' is 0, it will be assigned with a new value (if the return value of
> the function sctp_id2assoc() is not 0) in the following execution. However,
> this new value of 'val' is not checked before it is used to assigned to
> asoc->user_frag. That means it is possible that the new value of 'val'
> could be out of the expected range. This can cause security issues
> such as buffer overflows, e.g., the new value of 'val' is used as an index
> to access a buffer.
>
> This patch inserts a check for the new value of 'val' to see if it is in
> the expected range. If it is not, an error code -EINVAL will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
>  net/sctp/socket.c | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)

?
This patch is the same as previous one. git send-email <old file>
maybe?

  Marcelo

Re: [PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
>> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
>> and max_len to check whether it is in the appropriate range. If it is not,
>> an error code -EINVAL will be returned. This is enforced by a security
>> check. But, this check is only executed when 'val' is not 0. In fact, if
>> 'val' is 0, it will be assigned with a new value (if the return value of
>> the function sctp_id2assoc() is not 0) in the following execution. However,
>> this new value of 'val' is not checked before it is used to assigned to
>> asoc->user_frag. That means it is possible that the new value of 'val'
>> could be out of the expected range. This can cause security issues
>> such as buffer overflows, e.g., the new value of 'val' is used as an index
>> to access a buffer.
>>
>> This patch inserts a check for the new value of 'val' to see if it is in
>> the expected range. If it is not, an error code -EINVAL will be returned.
>>
>> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
>> ---
>>  net/sctp/socket.c | 22 +++++++++++-----------
>>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> ?
> This patch is the same as previous one. git send-email <old file>
> maybe?
>
>   Marcelo

Thanks for your suggestion, Marcelo. I can send the old file. But, I
have added a line of comment in this patch.

Wenwen

Re: [PATCH] sctp: fix a potential missing-check bug

[Marcelo Ricardo Leitner]

On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote:
> On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
> >> and max_len to check whether it is in the appropriate range. If it is not,
> >> an error code -EINVAL will be returned. This is enforced by a security
> >> check. But, this check is only executed when 'val' is not 0. In fact, if
> >> 'val' is 0, it will be assigned with a new value (if the return value of
> >> the function sctp_id2assoc() is not 0) in the following execution. However,
> >> this new value of 'val' is not checked before it is used to assigned to
> >> asoc->user_frag. That means it is possible that the new value of 'val'
> >> could be out of the expected range. This can cause security issues
> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
> >> to access a buffer.
> >>
> >> This patch inserts a check for the new value of 'val' to see if it is in
> >> the expected range. If it is not, an error code -EINVAL will be returned.
> >>
> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> >> ---
> >>  net/sctp/socket.c | 22 +++++++++++-----------
> >>  1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > ?
> > This patch is the same as previous one. git send-email <old file>
> > maybe?
> >
> >   Marcelo
>
> Thanks for your suggestion, Marcelo. I can send the old file. But, I
> have added a line of comment in this patch.

I meant if you had sent the old patch again by accident, because you
said you worked on an old version of the tree, but then posted a patch
that also doesn't use the new MTU function I mentioned.

  Marcelo

Re: [PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

On Wed, May 2, 2018 at 8:48 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote:
>> On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
>> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
>> >> and max_len to check whether it is in the appropriate range. If it is not,
>> >> an error code -EINVAL will be returned. This is enforced by a security
>> >> check. But, this check is only executed when 'val' is not 0. In fact, if
>> >> 'val' is 0, it will be assigned with a new value (if the return value of
>> >> the function sctp_id2assoc() is not 0) in the following execution. However,
>> >> this new value of 'val' is not checked before it is used to assigned to
>> >> asoc->user_frag. That means it is possible that the new value of 'val'
>> >> could be out of the expected range. This can cause security issues
>> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
>> >> to access a buffer.
>> >>
>> >> This patch inserts a check for the new value of 'val' to see if it is in
>> >> the expected range. If it is not, an error code -EINVAL will be returned.
>> >>
>> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
>> >> ---
>> >>  net/sctp/socket.c | 22 +++++++++++-----------
>> >>  1 file changed, 11 insertions(+), 11 deletions(-)
>> >
>> > ?
>> > This patch is the same as previous one. git send-email <old file>
>> > maybe?
>> >
>> >   Marcelo
>>
>> Thanks for your suggestion, Marcelo. I can send the old file. But, I
>> have added a line of comment in this patch.
>
> I meant if you had sent the old patch again by accident, because you
> said you worked on an old version of the tree, but then posted a patch
> that also doesn't use the new MTU function I mentioned.
>
>   Marcelo

I worked on the latest kernel. But, I didn't find the MTU function
sctp_mtu_payload().

The problematic function that I found is sctp_setsockopt_maxseg()
located in the file net/sctp/socket.c.

Thanks,

Wenwen

Re: [PATCH] sctp: fix a potential missing-check bug

[Marcelo Ricardo Leitner]

On Thu, May 03, 2018 at 07:01:51AM -0500, Wenwen Wang wrote:
> On Wed, May 2, 2018 at 8:48 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote:
> >> On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
> >> <marcelo.leitner@gmail.com> wrote:
> >> > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
> >> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
> >> >> and max_len to check whether it is in the appropriate range. If it is not,
> >> >> an error code -EINVAL will be returned. This is enforced by a security
> >> >> check. But, this check is only executed when 'val' is not 0. In fact, if
> >> >> 'val' is 0, it will be assigned with a new value (if the return value of
> >> >> the function sctp_id2assoc() is not 0) in the following execution. However,
> >> >> this new value of 'val' is not checked before it is used to assigned to
> >> >> asoc->user_frag. That means it is possible that the new value of 'val'
> >> >> could be out of the expected range. This can cause security issues
> >> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
> >> >> to access a buffer.
> >> >>
> >> >> This patch inserts a check for the new value of 'val' to see if it is in
> >> >> the expected range. If it is not, an error code -EINVAL will be returned.
> >> >>
> >> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> >> >> ---
> >> >>  net/sctp/socket.c | 22 +++++++++++-----------
> >> >>  1 file changed, 11 insertions(+), 11 deletions(-)
> >> >
> >> > ?
> >> > This patch is the same as previous one. git send-email <old file>
> >> > maybe?
> >> >
> >> >   Marcelo
> >>
> >> Thanks for your suggestion, Marcelo. I can send the old file. But, I
> >> have added a line of comment in this patch.
> >
> > I meant if you had sent the old patch again by accident, because you
> > said you worked on an old version of the tree, but then posted a patch
> > that also doesn't use the new MTU function I mentioned.
> >
> >   Marcelo
>
> I worked on the latest kernel. But, I didn't find the MTU function
> sctp_mtu_payload().

Which tree are you using?
[a] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
   or
[b] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
?

The function isn't on [a] yet, but it is on [b].

  Marcelo

Re: [PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

On Thu, May 3, 2018 at 7:46 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Thu, May 03, 2018 at 07:01:51AM -0500, Wenwen Wang wrote:
>> On Wed, May 2, 2018 at 8:48 PM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote:
>> >> On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
>> >> <marcelo.leitner@gmail.com> wrote:
>> >> > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
>> >> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
>> >> >> and max_len to check whether it is in the appropriate range. If it is not,
>> >> >> an error code -EINVAL will be returned. This is enforced by a security
>> >> >> check. But, this check is only executed when 'val' is not 0. In fact, if
>> >> >> 'val' is 0, it will be assigned with a new value (if the return value of
>> >> >> the function sctp_id2assoc() is not 0) in the following execution. However,
>> >> >> this new value of 'val' is not checked before it is used to assigned to
>> >> >> asoc->user_frag. That means it is possible that the new value of 'val'
>> >> >> could be out of the expected range. This can cause security issues
>> >> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
>> >> >> to access a buffer.
>> >> >>
>> >> >> This patch inserts a check for the new value of 'val' to see if it is in
>> >> >> the expected range. If it is not, an error code -EINVAL will be returned.
>> >> >>
>> >> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
>> >> >> ---
>> >> >>  net/sctp/socket.c | 22 +++++++++++-----------
>> >> >>  1 file changed, 11 insertions(+), 11 deletions(-)
>> >> >
>> >> > ?
>> >> > This patch is the same as previous one. git send-email <old file>
>> >> > maybe?
>> >> >
>> >> >   Marcelo
>> >>
>> >> Thanks for your suggestion, Marcelo. I can send the old file. But, I
>> >> have added a line of comment in this patch.
>> >
>> > I meant if you had sent the old patch again by accident, because you
>> > said you worked on an old version of the tree, but then posted a patch
>> > that also doesn't use the new MTU function I mentioned.
>> >
>> >   Marcelo
>>
>> I worked on the latest kernel. But, I didn't find the MTU function
>> sctp_mtu_payload().
>
> Which tree are you using?
> [a] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>    or
> [b] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> ?
>
> The function isn't on [a] yet, but it is on [b].
>
>   Marcelo

Many thanks for your patience, Marcelo :)

The tree I am working on is:
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Wenwen

Re: [PATCH] sctp: fix a potential missing-check bug

[Marcelo Ricardo Leitner]

On Thu, May 03, 2018 at 08:31:28AM -0500, Wenwen Wang wrote:
> On Thu, May 3, 2018 at 7:46 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Thu, May 03, 2018 at 07:01:51AM -0500, Wenwen Wang wrote:
> >> On Wed, May 2, 2018 at 8:48 PM, Marcelo Ricardo Leitner
> >> <marcelo.leitner@gmail.com> wrote:
> >> > On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote:
> >> >> On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
> >> >> <marcelo.leitner@gmail.com> wrote:
> >> >> > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
> >> >> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
> >> >> >> and max_len to check whether it is in the appropriate range. If it is not,
> >> >> >> an error code -EINVAL will be returned. This is enforced by a security
> >> >> >> check. But, this check is only executed when 'val' is not 0. In fact, if
> >> >> >> 'val' is 0, it will be assigned with a new value (if the return value of
> >> >> >> the function sctp_id2assoc() is not 0) in the following execution. However,
> >> >> >> this new value of 'val' is not checked before it is used to assigned to
> >> >> >> asoc->user_frag. That means it is possible that the new value of 'val'
> >> >> >> could be out of the expected range. This can cause security issues
> >> >> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
> >> >> >> to access a buffer.
> >> >> >>
> >> >> >> This patch inserts a check for the new value of 'val' to see if it is in
> >> >> >> the expected range. If it is not, an error code -EINVAL will be returned.
> >> >> >>
> >> >> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> >> >> >> ---
> >> >> >>  net/sctp/socket.c | 22 +++++++++++-----------
> >> >> >>  1 file changed, 11 insertions(+), 11 deletions(-)
> >> >> >
> >> >> > ?
> >> >> > This patch is the same as previous one. git send-email <old file>
> >> >> > maybe?
> >> >> >
> >> >> >   Marcelo
> >> >>
> >> >> Thanks for your suggestion, Marcelo. I can send the old file. But, I
> >> >> have added a line of comment in this patch.
> >> >
> >> > I meant if you had sent the old patch again by accident, because you
> >> > said you worked on an old version of the tree, but then posted a patch
> >> > that also doesn't use the new MTU function I mentioned.
> >> >
> >> >   Marcelo
> >>
> >> I worked on the latest kernel. But, I didn't find the MTU function
> >> sctp_mtu_payload().
> >
> > Which tree are you using?
> > [a] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
> >    or
> > [b] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> > ?
> >
> > The function isn't on [a] yet, but it is on [b].
> >
> >   Marcelo
>
> Many thanks for your patience, Marcelo :)
>
> The tree I am working on is:
> git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Ahh! That explains the discrepancy :)
For networking patches, please refer to
Documentation/networking/netdev-FAQ.txt
It describes what the 2 trees I pointed out are and how they should be
used.
In short, both net and net-next are always newer than the one you're
using for networking subsystem.

Regards,
Marcelo

Re: [PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

On Thu, May 3, 2018 at 8:39 AM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Thu, May 03, 2018 at 08:31:28AM -0500, Wenwen Wang wrote:
>> On Thu, May 3, 2018 at 7:46 AM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > On Thu, May 03, 2018 at 07:01:51AM -0500, Wenwen Wang wrote:
>> >> On Wed, May 2, 2018 at 8:48 PM, Marcelo Ricardo Leitner
>> >> <marcelo.leitner@gmail.com> wrote:
>> >> > On Wed, May 02, 2018 at 08:27:05PM -0500, Wenwen Wang wrote:
>> >> >> On Wed, May 2, 2018 at 8:24 PM, Marcelo Ricardo Leitner
>> >> >> <marcelo.leitner@gmail.com> wrote:
>> >> >> > On Wed, May 02, 2018 at 08:15:45PM -0500, Wenwen Wang wrote:
>> >> >> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
>> >> >> >> and max_len to check whether it is in the appropriate range. If it is not,
>> >> >> >> an error code -EINVAL will be returned. This is enforced by a security
>> >> >> >> check. But, this check is only executed when 'val' is not 0. In fact, if
>> >> >> >> 'val' is 0, it will be assigned with a new value (if the return value of
>> >> >> >> the function sctp_id2assoc() is not 0) in the following execution. However,
>> >> >> >> this new value of 'val' is not checked before it is used to assigned to
>> >> >> >> asoc->user_frag. That means it is possible that the new value of 'val'
>> >> >> >> could be out of the expected range. This can cause security issues
>> >> >> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
>> >> >> >> to access a buffer.
>> >> >> >>
>> >> >> >> This patch inserts a check for the new value of 'val' to see if it is in
>> >> >> >> the expected range. If it is not, an error code -EINVAL will be returned.
>> >> >> >>
>> >> >> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
>> >> >> >> ---
>> >> >> >>  net/sctp/socket.c | 22 +++++++++++-----------
>> >> >> >>  1 file changed, 11 insertions(+), 11 deletions(-)
>> >> >> >
>> >> >> > ?
>> >> >> > This patch is the same as previous one. git send-email <old file>
>> >> >> > maybe?
>> >> >> >
>> >> >> >   Marcelo
>> >> >>
>> >> >> Thanks for your suggestion, Marcelo. I can send the old file. But, I
>> >> >> have added a line of comment in this patch.
>> >> >
>> >> > I meant if you had sent the old patch again by accident, because you
>> >> > said you worked on an old version of the tree, but then posted a patch
>> >> > that also doesn't use the new MTU function I mentioned.
>> >> >
>> >> >   Marcelo
>> >>
>> >> I worked on the latest kernel. But, I didn't find the MTU function
>> >> sctp_mtu_payload().
>> >
>> > Which tree are you using?
>> > [a] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>> >    or
>> > [b] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>> > ?
>> >
>> > The function isn't on [a] yet, but it is on [b].
>> >
>> >   Marcelo
>>
>> Many thanks for your patience, Marcelo :)
>>
>> The tree I am working on is:
>> git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> Ahh! That explains the discrepancy :)
> For networking patches, please refer to
> Documentation/networking/netdev-FAQ.txt
> It describes what the 2 trees I pointed out are and how they should be
> used.
> In short, both net and net-next are always newer than the one you're
> using for networking subsystem.
>
> Regards,
> Marcelo

I see now. Will work on the new networking trees. Thanks!

Wenwen

[PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
and max_len to check whether it is in the appropriate range. If it is not,
an error code -EINVAL will be returned. This is enforced by a security
check. But, this check is only executed when 'val' is not 0. In fact, if
'val' is 0, it will be assigned with a new value (if the return value of
the function sctp_id2assoc() is not 0) in the following execution. However,
this new value of 'val' is not checked before it is used to assigned to
asoc->user_frag. That means it is possible that the new value of 'val'
could be out of the expected range. This can cause security issues
such as buffer overflows, e.g., the new value of 'val' is used as an index
to access a buffer.

This patch inserts a check for the new value of 'val' to see if it is in
the expected range. If it is not, an error code -EINVAL will be returned.

Signed-off-by: Wenwen Wang <wang6495@umn.edu>
---
 net/sctp/socket.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 80835ac..2beb601 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3212,6 +3212,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 	struct sctp_af *af = sp->pf->af;
 	struct sctp_assoc_value params;
 	struct sctp_association *asoc;
+	int min_len, max_len;
 	int val;
 
 	if (optlen == sizeof(int)) {
@@ -3231,19 +3232,15 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 		return -EINVAL;
 	}
 
-	if (val) {
-		int min_len, max_len;
+	min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
+	min_len -= af->ip_options_len(sk);
+	min_len -= sizeof(struct sctphdr) +
+		   sizeof(struct sctp_data_chunk);
 
-		min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
-		min_len -= af->ip_options_len(sk);
-		min_len -= sizeof(struct sctphdr) +
-			   sizeof(struct sctp_data_chunk);
+	max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
 
-		max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
-
-		if (val < min_len || val > max_len)
-			return -EINVAL;
-	}
+	if (val && (val < min_len || val > max_len))
+		return -EINVAL;
 
 	asoc = sctp_id2assoc(sk, params.assoc_id);
 	if (asoc) {
@@ -3253,6 +3250,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
 			val -= sizeof(struct sctphdr) +
 			       sctp_datachk_len(&asoc->stream);
 		}
+		if (val < min_len || val > max_len)
+			return -EINVAL;
 		asoc->user_frag = val;
 		asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
 	} else {
-- 
2.7.4

Re: [PATCH] sctp: fix a potential missing-check bug

[Marcelo Ricardo Leitner]

Hi Wenwen,

On Wed, May 02, 2018 at 05:12:45PM -0500, Wenwen Wang wrote:
> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
> and max_len to check whether it is in the appropriate range. If it is not,
> an error code -EINVAL will be returned. This is enforced by a security
> check. But, this check is only executed when 'val' is not 0. In fact, if

Which makes sense, no? Especially if considering that 0 should be an
allowed value as it turns off the user limit.

> 'val' is 0, it will be assigned with a new value (if the return value of
> the function sctp_id2assoc() is not 0) in the following execution. However,
> this new value of 'val' is not checked before it is used to assigned to

Which 'new value'? val is not set to something new during the
function. It always contains the user supplied value.

> asoc->user_frag. That means it is possible that the new value of 'val'
> could be out of the expected range. This can cause security issues
> such as buffer overflows, e.g., the new value of 'val' is used as an index
> to access a buffer.
>
> This patch inserts a check for the new value of 'val' to see if it is in
> the expected range. If it is not, an error code -EINVAL will be returned.
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
>  net/sctp/socket.c | 21 ++++++++++-----------
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 80835ac..2beb601 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3212,6 +3212,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>  	struct sctp_af *af = sp->pf->af;
>  	struct sctp_assoc_value params;
>  	struct sctp_association *asoc;
> +	int min_len, max_len;
>  	int val;
>
>  	if (optlen == sizeof(int)) {
> @@ -3231,19 +3232,15 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>  		return -EINVAL;
>  	}
>
> -	if (val) {
> -		int min_len, max_len;
> +	min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
> +	min_len -= af->ip_options_len(sk);
> +	min_len -= sizeof(struct sctphdr) +
> +		   sizeof(struct sctp_data_chunk);

On which tree did you base your patch on? Your patch lacks a tag so it
defaults to net-next, and I reworked this section on current net-next
and these MTU calculcations are now handled by sctp_mtu_payload().

But even for net tree, I don't understand which issue you're fixing
here. Actually it seems to me that both codes seems to do the same
thing.

>
> -		min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
> -		min_len -= af->ip_options_len(sk);
> -		min_len -= sizeof(struct sctphdr) +
> -			   sizeof(struct sctp_data_chunk);
> +	max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
>
> -		max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
> -
> -		if (val < min_len || val > max_len)
> -			return -EINVAL;
> -	}
> +	if (val && (val < min_len || val > max_len))
> +		return -EINVAL;
>
>  	asoc = sctp_id2assoc(sk, params.assoc_id);
>  	if (asoc) {
> @@ -3253,6 +3250,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>  			val -= sizeof(struct sctphdr) +
>  			       sctp_datachk_len(&asoc->stream);
>  		}
> +		if (val < min_len || val > max_len)
> +			return -EINVAL;
>  		asoc->user_frag = val;
>  		asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
>  	} else {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] sctp: fix a potential missing-check bug

[Wenwen Wang]

Hi Marcelo,

I guess I worked on an old version of the kernel. I will re-submit the
patch. Sorry :(

Wenwen

On Wed, May 2, 2018 at 6:23 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi Wenwen,
>
> On Wed, May 02, 2018 at 05:12:45PM -0500, Wenwen Wang wrote:
>> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
>> and max_len to check whether it is in the appropriate range. If it is not,
>> an error code -EINVAL will be returned. This is enforced by a security
>> check. But, this check is only executed when 'val' is not 0. In fact, if
>
> Which makes sense, no? Especially if considering that 0 should be an
> allowed value as it turns off the user limit.
>
>> 'val' is 0, it will be assigned with a new value (if the return value of
>> the function sctp_id2assoc() is not 0) in the following execution. However,
>> this new value of 'val' is not checked before it is used to assigned to
>
> Which 'new value'? val is not set to something new during the
> function. It always contains the user supplied value.
>
>> asoc->user_frag. That means it is possible that the new value of 'val'
>> could be out of the expected range. This can cause security issues
>> such as buffer overflows, e.g., the new value of 'val' is used as an index
>> to access a buffer.
>>
>> This patch inserts a check for the new value of 'val' to see if it is in
>> the expected range. If it is not, an error code -EINVAL will be returned.
>>
>> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
>> ---
>>  net/sctp/socket.c | 21 ++++++++++-----------
>>  1 file changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index 80835ac..2beb601 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -3212,6 +3212,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>>       struct sctp_af *af = sp->pf->af;
>>       struct sctp_assoc_value params;
>>       struct sctp_association *asoc;
>> +     int min_len, max_len;
>>       int val;
>>
>>       if (optlen == sizeof(int)) {
>> @@ -3231,19 +3232,15 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>>               return -EINVAL;
>>       }
>>
>> -     if (val) {
>> -             int min_len, max_len;
>> +     min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
>> +     min_len -= af->ip_options_len(sk);
>> +     min_len -= sizeof(struct sctphdr) +
>> +                sizeof(struct sctp_data_chunk);
>
> On which tree did you base your patch on? Your patch lacks a tag so it
> defaults to net-next, and I reworked this section on current net-next
> and these MTU calculcations are now handled by sctp_mtu_payload().
>
> But even for net tree, I don't understand which issue you're fixing
> here. Actually it seems to me that both codes seems to do the same
> thing.
>
>>
>> -             min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
>> -             min_len -= af->ip_options_len(sk);
>> -             min_len -= sizeof(struct sctphdr) +
>> -                        sizeof(struct sctp_data_chunk);
>> +     max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
>>
>> -             max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
>> -
>> -             if (val < min_len || val > max_len)
>> -                     return -EINVAL;
>> -     }
>> +     if (val && (val < min_len || val > max_len))
>> +             return -EINVAL;
>>
>>       asoc = sctp_id2assoc(sk, params.assoc_id);
>>       if (asoc) {
>> @@ -3253,6 +3250,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
>>                       val -= sizeof(struct sctphdr) +
>>                              sctp_datachk_len(&asoc->stream);
>>               }
>> +             if (val < min_len || val > max_len)
>> +                     return -EINVAL;
>>               asoc->user_frag = val;
>>               asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
>>       } else {
>> --
>> 2.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: [PATCH] sctp: fix a potential missing-check bug

[Neil Horman]

On Wed, May 02, 2018 at 08:07:17PM -0500, Wenwen Wang wrote:
> Hi Marcelo,
> 
> I guess I worked on an old version of the kernel. I will re-submit the
> patch. Sorry :(
> 
You don't have to resubmit the patch, this isn't broken.  As marcelo points out,
a value of zero in this socket option is special, meaning set the fragmentation
to whatever the pmtu is, which will always rest between the min and max segment
lengths.

Neil

> Wenwen
> 
> On Wed, May 2, 2018 at 6:23 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > Hi Wenwen,
> >
> > On Wed, May 02, 2018 at 05:12:45PM -0500, Wenwen Wang wrote:
> >> In sctp_setsockopt_maxseg(), the integer 'val' is compared against min_len
> >> and max_len to check whether it is in the appropriate range. If it is not,
> >> an error code -EINVAL will be returned. This is enforced by a security
> >> check. But, this check is only executed when 'val' is not 0. In fact, if
> >
> > Which makes sense, no? Especially if considering that 0 should be an
> > allowed value as it turns off the user limit.
> >
> >> 'val' is 0, it will be assigned with a new value (if the return value of
> >> the function sctp_id2assoc() is not 0) in the following execution. However,
> >> this new value of 'val' is not checked before it is used to assigned to
> >
> > Which 'new value'? val is not set to something new during the
> > function. It always contains the user supplied value.
> >
> >> asoc->user_frag. That means it is possible that the new value of 'val'
> >> could be out of the expected range. This can cause security issues
> >> such as buffer overflows, e.g., the new value of 'val' is used as an index
> >> to access a buffer.
> >>
> >> This patch inserts a check for the new value of 'val' to see if it is in
> >> the expected range. If it is not, an error code -EINVAL will be returned.
> >>
> >> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> >> ---
> >>  net/sctp/socket.c | 21 ++++++++++-----------
> >>  1 file changed, 10 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> >> index 80835ac..2beb601 100644
> >> --- a/net/sctp/socket.c
> >> +++ b/net/sctp/socket.c
> >> @@ -3212,6 +3212,7 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> >>       struct sctp_af *af = sp->pf->af;
> >>       struct sctp_assoc_value params;
> >>       struct sctp_association *asoc;
> >> +     int min_len, max_len;
> >>       int val;
> >>
> >>       if (optlen == sizeof(int)) {
> >> @@ -3231,19 +3232,15 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> >>               return -EINVAL;
> >>       }
> >>
> >> -     if (val) {
> >> -             int min_len, max_len;
> >> +     min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
> >> +     min_len -= af->ip_options_len(sk);
> >> +     min_len -= sizeof(struct sctphdr) +
> >> +                sizeof(struct sctp_data_chunk);
> >
> > On which tree did you base your patch on? Your patch lacks a tag so it
> > defaults to net-next, and I reworked this section on current net-next
> > and these MTU calculcations are now handled by sctp_mtu_payload().
> >
> > But even for net tree, I don't understand which issue you're fixing
> > here. Actually it seems to me that both codes seems to do the same
> > thing.
> >
> >>
> >> -             min_len = SCTP_DEFAULT_MINSEGMENT - af->net_header_len;
> >> -             min_len -= af->ip_options_len(sk);
> >> -             min_len -= sizeof(struct sctphdr) +
> >> -                        sizeof(struct sctp_data_chunk);
> >> +     max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
> >>
> >> -             max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
> >> -
> >> -             if (val < min_len || val > max_len)
> >> -                     return -EINVAL;
> >> -     }
> >> +     if (val && (val < min_len || val > max_len))
> >> +             return -EINVAL;
> >>
> >>       asoc = sctp_id2assoc(sk, params.assoc_id);
> >>       if (asoc) {
> >> @@ -3253,6 +3250,8 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> >>                       val -= sizeof(struct sctphdr) +
> >>                              sctp_datachk_len(&asoc->stream);
> >>               }
> >> +             if (val < min_len || val > max_len)
> >> +                     return -EINVAL;
> >>               asoc->user_frag = val;
> >>               asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
> >>       } else {
> >> --
> >> 2.7.4
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
>