[SRU][Trusty][Xenial][Zesty][Artful][PATCH 0/1] Fix for CVE-2017-15115

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[SRU][Trusty][Xenial][Zesty][Artful][PATCH 0/1] Fix for CVE-2017-15115

Kleber Souza
Clean cherry-pick for Xenial, Zesty and Artful. Backport for Trusty because
the patch needed some fuzzing to be applied.

https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-15115.html

Xin Long (1):
  sctp: do not peel off an assoc from one netns to another one

 net/sctp/socket.c | 4 ++++
 1 file changed, 4 insertions(+)

--
2.14.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU][Trusty][PATCH] sctp: do not peel off an assoc from one netns to another one

Kleber Souza
From: Xin Long <[hidden email]>

Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.

As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.

This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:

  socket$inet6_sctp()
  bind$inet6()
  sendto$inet6()
  unshare(0x40000000)
  getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
  getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()

This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.

Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.

Reported-by: ChunYu Wang <[hidden email]>
Signed-off-by: Xin Long <[hidden email]>
Acked-by: Marcelo Ricardo Leitner <[hidden email]>
Acked-by: Neil Horman <[hidden email]>
Signed-off-by: David S. Miller <[hidden email]>

CVE-2017-15115
(backported from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74)
Signed-off-by: Kleber Sacilotto de Souza <[hidden email]>
---
 net/sctp/socket.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 806b8260d1c5..219e5e0298e4 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4308,6 +4308,10 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
  struct sctp_af *af;
  int err = 0;
 
+ /* Do not peel off from one netns to another one. */
+ if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
+ return -EINVAL;
+
  if (!asoc)
  return -EINVAL;
 
--
2.14.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU][Xenial][Zesty][Artful][PATCH 1/1] sctp: do not peel off an assoc from one netns to another one

Kleber Souza
In reply to this post by Kleber Souza
From: Xin Long <[hidden email]>

Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.

As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.

This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:

  socket$inet6_sctp()
  bind$inet6()
  sendto$inet6()
  unshare(0x40000000)
  getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
  getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()

This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.

Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.

Reported-by: ChunYu Wang <[hidden email]>
Signed-off-by: Xin Long <[hidden email]>
Acked-by: Marcelo Ricardo Leitner <[hidden email]>
Acked-by: Neil Horman <[hidden email]>
Signed-off-by: David S. Miller <[hidden email]>

CVE-2017-15115
(cherry picked from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74)
Signed-off-by: Kleber Sacilotto de Souza <[hidden email]>
---
 net/sctp/socket.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index d4730ada7f32..17841ab30798 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4906,6 +4906,10 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
  struct socket *sock;
  int err = 0;
 
+ /* Do not peel off from one netns to another one. */
+ if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
+ return -EINVAL;
+
  if (!asoc)
  return -EINVAL;
 
--
2.14.1


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [SRU][Trusty][Xenial][Zesty][Artful][PATCH 0/1] Fix for CVE-2017-15115

Stefan Bader-2
In reply to this post by Kleber Souza
On 07.12.2017 15:06, Kleber Sacilotto de Souza wrote:

> Clean cherry-pick for Xenial, Zesty and Artful. Backport for Trusty because
> the patch needed some fuzzing to be applied.
>
> https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-15115.html
>
> Xin Long (1):
>   sctp: do not peel off an assoc from one netns to another one
>
>  net/sctp/socket.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
Acked-by: Stefan Bader <[hidden email]>



--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

ACK: [SRU][Xenial][Zesty][Artful][PATCH 1/1] sctp: do not peel off an assoc from one netns to another one

Colin Ian King-2
In reply to this post by Kleber Souza
On 07/12/17 15:07, Kleber Sacilotto de Souza wrote:

> From: Xin Long <[hidden email]>
>
> Now when peeling off an association to the sock in another netns, all
> transports in this assoc are not to be rehashed and keep use the old
> key in hashtable.
>
> As a transport uses sk->net as the hash key to insert into hashtable,
> it would miss removing these transports from hashtable due to the new
> netns when closing the sock and all transports are being freeed, then
> later an use-after-free issue could be caused when looking up an asoc
> and dereferencing those transports.
>
> This is a very old issue since very beginning, ChunYu found it with
> syzkaller fuzz testing with this series:
>
>   socket$inet6_sctp()
>   bind$inet6()
>   sendto$inet6()
>   unshare(0x40000000)
>   getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
>   getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
>
> This patch is to block this call when peeling one assoc off from one
> netns to another one, so that the netns of all transport would not
> go out-sync with the key in hashtable.
>
> Note that this patch didn't fix it by rehashing transports, as it's
> difficult to handle the situation when the tuple is already in use
> in the new netns. Besides, no one would like to peel off one assoc
> to another netns, considering ipaddrs, ifaces, etc. are usually
> different.
>
> Reported-by: ChunYu Wang <[hidden email]>
> Signed-off-by: Xin Long <[hidden email]>
> Acked-by: Marcelo Ricardo Leitner <[hidden email]>
> Acked-by: Neil Horman <[hidden email]>
> Signed-off-by: David S. Miller <[hidden email]>
>
> CVE-2017-15115
> (cherry picked from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74)
> Signed-off-by: Kleber Sacilotto de Souza <[hidden email]>
> ---
>  net/sctp/socket.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d4730ada7f32..17841ab30798 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4906,6 +4906,10 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
>   struct socket *sock;
>   int err = 0;
>  
> + /* Do not peel off from one netns to another one. */
> + if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
> + return -EINVAL;
> +
>   if (!asoc)
>   return -EINVAL;
>  
>
Clean cherry pick.

Acked-by: Colin Ian King <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: [SRU][Trusty][PATCH] sctp: do not peel off an assoc from one netns to another one

Colin Ian King-2
In reply to this post by Kleber Souza
On 07/12/17 15:06, Kleber Sacilotto de Souza wrote:

> From: Xin Long <[hidden email]>
>
> Now when peeling off an association to the sock in another netns, all
> transports in this assoc are not to be rehashed and keep use the old
> key in hashtable.
>
> As a transport uses sk->net as the hash key to insert into hashtable,
> it would miss removing these transports from hashtable due to the new
> netns when closing the sock and all transports are being freeed, then
> later an use-after-free issue could be caused when looking up an asoc
> and dereferencing those transports.
>
> This is a very old issue since very beginning, ChunYu found it with
> syzkaller fuzz testing with this series:
>
>   socket$inet6_sctp()
>   bind$inet6()
>   sendto$inet6()
>   unshare(0x40000000)
>   getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST()
>   getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF()
>
> This patch is to block this call when peeling one assoc off from one
> netns to another one, so that the netns of all transport would not
> go out-sync with the key in hashtable.
>
> Note that this patch didn't fix it by rehashing transports, as it's
> difficult to handle the situation when the tuple is already in use
> in the new netns. Besides, no one would like to peel off one assoc
> to another netns, considering ipaddrs, ifaces, etc. are usually
> different.
>
> Reported-by: ChunYu Wang <[hidden email]>
> Signed-off-by: Xin Long <[hidden email]>
> Acked-by: Marcelo Ricardo Leitner <[hidden email]>
> Acked-by: Neil Horman <[hidden email]>
> Signed-off-by: David S. Miller <[hidden email]>
>
> CVE-2017-15115
> (backported from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74)
> Signed-off-by: Kleber Sacilotto de Souza <[hidden email]>
> ---
>  net/sctp/socket.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 806b8260d1c5..219e5e0298e4 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4308,6 +4308,10 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp)
>   struct sctp_af *af;
>   int err = 0;
>  
> + /* Do not peel off from one netns to another one. */
> + if (!net_eq(current->nsproxy->net_ns, sock_net(sk)))
> + return -EINVAL;
> +
>   if (!asoc)
>   return -EINVAL;
>  
>
Backport looks good to me.

Acked-by: Colin Ian King <[hidden email]>

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED: [SRU, Trusty] sctp: do not peel off an assoc from one netns to another

Thadeu Lima de Souza Cascardo-3
In reply to this post by Kleber Souza
Applied to trusty master-next branch.

Thanks.
Cascardo.

Applied-to: trusty/master-next

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED: [SRU, Xenial, Zesty, Artful, 1/1] sctp: do not peel off an assoc from one

Thadeu Lima de Souza Cascardo-3
In reply to this post by Kleber Souza
Applied to xenial, zesty and artful master-next branches.

Thanks.
Cascardo.

Applied-to: xenial/master-next
Applied-to: zesty/master-next
Applied-to: artful/master-next

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team