[PATCH 0/4][SRU][X] Multiple TCP Fixups

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

[PATCH 0/4][SRU][X] Multiple TCP Fixups

Tyler Hicks-2
This series reverts my backport of a fixup for the CVE-2019-11478 fix
and applies the version of the fixup that the TCP maintainer provided
for the 4.4 linux-stable tree. It also includes another fixup, from
upstream, which addresses some performance issues that were reported to
me. Details can be found here:

 https://databricks.com/blog/2019/08/01/network-performance-regressions-from-tcp-sack-vulnerability-fixes.html

The fix for CVE-2019-15239 is sandwiched in the middle of the series. It
made cherry-picking of the entire series from linux-stable possible but,
more importantly, it fixes a flaw that was caused by a bad backport in
the linux-stable tree.

 https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-11478
 https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-15239

Note that the Ubuntu CVE Tracker entry for CVE-2019-15239 is not fully
updated with breaks-fix commit info as I'm still trying to decide how
best to do that for this somewhat unique CVE that affects linux-stable
but not linux.

I believe that I was able to reproduce the some of the nondeterministic
performance regression that Databricks was seeing using netperf while
running the 4.4.0-159.187-generic. I didn't see this behavior while
testing the 4.4.0-150.176-generic kernel, which is the last published
kernel before CVE-2019-11478 was fixed. I also don't see the behavior
once these patches are applied to the 4.4.0-159.187-generic kernel.

Tyler

Eric Dumazet (2):
  tcp: refine memory limit test in tcp_fragment()
  tcp: be more careful in tcp_fragment()

Soheil Hassas Yeganeh (1):
  tcp: reset sk_send_head in tcp_write_queue_purge

Tyler Hicks (1):
  UBUNTU: SAUCE: Revert "tcp: refine memory limit test in
    tcp_fragment()"

 include/net/tcp.h     | 22 ++++++++++++++++++++--
 net/ipv4/tcp_output.c | 12 ++++++++++--
 2 files changed, 30 insertions(+), 4 deletions(-)

--
2.17.1


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

[PATCH 1/4] UBUNTU: SAUCE: Revert "tcp: refine memory limit test in tcp_fragment()"

Tyler Hicks-2
This reverts commit 92fc18789a3793965588087a1d7860f38f3c65b4. I've
received a private report detailing a performance regression in the
Xenial 4.4 kernel that is fixed by commit b617158dc096 ("tcp: be more
careful in tcp_fragment()"). Before pulling that patch in, it would be
best to revert my backport of commit b6653b3629e5 ("tcp: refine memory
limit test in tcp_fragment()") and go with the version that Eric Dumazet
provided for the upstream linux-stable 4.4 tree.

CVE-2019-11478

Signed-off-by: Tyler Hicks <[hidden email]>
---
 net/ipv4/tcp_output.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 719d2cc8770c..ede265fbf7ba 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1163,8 +1163,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
  if (nsize < 0)
  nsize = 0;
 
- if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf &&
-     skb != tcp_send_head(sk))) {
+ if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
  NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
  return -ENOMEM;
  }
--
2.17.1


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

[PATCH 2/4] tcp: refine memory limit test in tcp_fragment()

Tyler Hicks-2
In reply to this post by Tyler Hicks-2
From: Eric Dumazet <[hidden email]>

commit b6653b3629e5b88202be3c9abc44713973f5c4b4 upstream.

tcp_fragment() might be called for skbs in the write queue.

Memory limits might have been exceeded because tcp_sendmsg() only
checks limits at full skb (64KB) boundaries.

Therefore, we need to make sure tcp_fragment() wont punish applications
that might have setup very low SO_SNDBUF values.

Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
Signed-off-by: Eric Dumazet <[hidden email]>
Reported-by: Christoph Paasch <[hidden email]>
Tested-by: Christoph Paasch <[hidden email]>
Signed-off-by: David S. Miller <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>

CVE-2019-11478

(cherry picked from commit 46c7b5d6f2a51c355b29118814fbfbdb79c35656 linux-stable)
Signed-off-by: Tyler Hicks <[hidden email]>
---
 net/ipv4/tcp_output.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index ede265fbf7ba..1b2a6ab5da9d 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1163,7 +1163,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
  if (nsize < 0)
  nsize = 0;
 
- if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf)) {
+ if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 0x20000)) {
  NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
  return -ENOMEM;
  }
--
2.17.1


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

[PATCH 3/4] tcp: reset sk_send_head in tcp_write_queue_purge

Tyler Hicks-2
In reply to this post by Tyler Hicks-2
From: Soheil Hassas Yeganeh <[hidden email]>

[ Upstream commit dbbf2d1e4077bab0c65ece2765d3fc69cf7d610f ]

tcp_write_queue_purge clears all the SKBs in the write queue
but does not reset the sk_send_head. As a result, we can have
a NULL pointer dereference anywhere that we use tcp_send_head
instead of the tcp_write_queue_tail.

For example, after a27fd7a8ed38 (tcp: purge write queue upon RST),
we can purge the write queue on RST. Prior to
75c119afe14f (tcp: implement rb-tree based retransmit queue),
tcp_push will only check tcp_send_head and then accesses
tcp_write_queue_tail to send the actual SKB. As a result, it will
dereference a NULL pointer.

This has been reported twice for 4.14 where we don't have
75c119afe14f:

By Timofey Titovets:

[  422.081094] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000038
[  422.081254] IP: tcp_push+0x42/0x110
[  422.081314] PGD 0 P4D 0
[  422.081364] Oops: 0002 [#1] SMP PTI

By Yongjian Xu:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
IP: tcp_push+0x48/0x120
PGD 80000007ff77b067 P4D 80000007ff77b067 PUD 7fd989067 PMD 0
Oops: 0002 [#18] SMP PTI
Modules linked in: tcp_diag inet_diag tcp_bbr sch_fq iTCO_wdt
iTCO_vendor_support pcspkr ixgbe mdio i2c_i801 lpc_ich joydev input_leds shpchp
e1000e igb dca ptp pps_core hwmon mei_me mei ipmi_si ipmi_msghandler sg ses
scsi_transport_sas enclosure ext4 jbd2 mbcache sd_mod ahci libahci megaraid_sas
wmi ast ttm dm_mirror dm_region_hash dm_log dm_mod dax
CPU: 6 PID: 14156 Comm: [ET_NET 6] Tainted: G D 4.14.26-1.el6.x86_64 #1
Hardware name: LENOVO ThinkServer RD440 /ThinkServer RD440, BIOS A0TS80A
09/22/2014
task: ffff8807d78d8140 task.stack: ffffc9000e944000
RIP: 0010:tcp_push+0x48/0x120
RSP: 0018:ffffc9000e947a88 EFLAGS: 00010246
RAX: 00000000000005b4 RBX: ffff880f7cce9c00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff8807d00f5000
RBP: ffffc9000e947aa8 R08: 0000000000001c84 R09: 0000000000000000
R10: ffff8807d00f5158 R11: 0000000000000000 R12: ffff8807d00f5000
R13: 0000000000000020 R14: 00000000000256d4 R15: 0000000000000000
FS: 00007f5916de9700(0000) GS:ffff88107fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000038 CR3: 00000007f8226004 CR4: 00000000001606e0
Call Trace:
tcp_sendmsg_locked+0x33d/0xe50
tcp_sendmsg+0x37/0x60
inet_sendmsg+0x39/0xc0
sock_sendmsg+0x49/0x60
sock_write_iter+0xb6/0x100
do_iter_readv_writev+0xec/0x130
? rw_verify_area+0x49/0xb0
do_iter_write+0x97/0xd0
vfs_writev+0x7e/0xe0
? __wake_up_common_lock+0x80/0xa0
? __fget_light+0x2c/0x70
? __do_page_fault+0x1e7/0x530
do_writev+0x60/0xf0
? inet_shutdown+0xac/0x110
SyS_writev+0x10/0x20
do_syscall_64+0x6f/0x140
? prepare_exit_to_usermode+0x8b/0xa0
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x3135ce0c57
RSP: 002b:00007f5916de4b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000003135ce0c57
RDX: 0000000000000002 RSI: 00007f5916de4b90 RDI: 000000000000606f
RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f5916de8c38
R10: 0000000000000000 R11: 0000000000000293 R12: 00000000000464cc
R13: 00007f5916de8c30 R14: 00007f58d8bef080 R15: 0000000000000002
Code: 48 8b 97 60 01 00 00 4c 8d 97 58 01 00 00 41 b9 00 00 00 00 41 89 f3 4c 39
d2 49 0f 44 d1 41 81 e3 00 80 00 00 0f 85 b0 00 00 00 <80> 4a 38 08 44 8b 8f 74
06 00 00 44 89 8f 7c 06 00 00 83 e6 01
RIP: tcp_push+0x48/0x120 RSP: ffffc9000e947a88
CR2: 0000000000000038
---[ end trace 8d545c2e93515549 ]---

There is other scenario which found in stable 4.4:
Allocated:
 [<ffffffff82f380a6>] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
 [<ffffffff832466c3>] alloc_skb_fclone include/linux/skbuff.h:856 [inline]
 [<ffffffff832466c3>] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
 [<ffffffff83249164>] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
 [<ffffffff83300ef3>] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
Freed:
 [<ffffffff82f372fd>] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
 [<ffffffff83288834>] sk_wmem_free_skb include/net/sock.h:1447 [inline]
 [<ffffffff83288834>] tcp_write_queue_purge include/net/tcp.h:1460 [inline]
 [<ffffffff83288834>] tcp_connect_init net/ipv4/tcp_output.c:3122 [inline]
 [<ffffffff83288834>] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
 [<ffffffff8329b991>] tcp_v4_connect+0xf31/0x1890 net/ipv4/tcp_ipv4.c:246

BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 [inline]
BUG: KASAN: use-after-free in tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
 [<ffffffff81515cd5>] kasan_report.cold.7+0x175/0x2f7 mm/kasan/report.c:408
 [<ffffffff814f9784>] __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:427
 [<ffffffff83286582>] tcp_skb_pcount include/net/tcp.h:796 [inline]
 [<ffffffff83286582>] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 [inline]
 [<ffffffff83286582>] tcp_write_xmit+0x3fc2/0x4cb0 net/ipv4/tcp_output.c:2056
 [<ffffffff83287a40>] __tcp_push_pending_frames+0xa0/0x290 net/ipv4/tcp_output.c:2307

stable 4.4 and stable 4.9 don't have the commit abb4a8b870b5 ("tcp: purge write queue upon RST")
which is referred in dbbf2d1e4077,
in tcp_connect_init, it calls tcp_write_queue_purge, and does not reset sk_send_head, then UAF.

stable 4.14 have the commit abb4a8b870b5 ("tcp: purge write queue upon RST"),
in tcp_reset, it calls tcp_write_queue_purge(sk), and does not reset sk_send_head, then UAF.

So this patch can be used to fix stable 4.4 and 4.9.

Fixes: a27fd7a8ed38 (tcp: purge write queue upon RST)
Reported-by: Timofey Titovets <[hidden email]>
Reported-by: Yongjian Xu <[hidden email]>
Signed-off-by: Eric Dumazet <[hidden email]>
Signed-off-by: Soheil Hassas Yeganeh <[hidden email]>
Tested-by: Yongjian Xu <[hidden email]>
Signed-off-by: David S. Miller <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
Signed-off-by: Mao Wenan <[hidden email]>
Signed-off-by: Sasha Levin <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>

CVE-2019-15239

(cherry picked from commit 8f0b77b71f3fec09f86f80cd98c36a1a35109499 linux-stable)
Signed-off-by: Tyler Hicks <[hidden email]>
---
 include/net/tcp.h | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index bf8a0dae977a..77438a8406ec 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1443,6 +1443,11 @@ struct sock *tcp_try_fastopen(struct sock *sk, struct sk_buff *skb,
 void tcp_fastopen_init_key_once(bool publish);
 #define TCP_FASTOPEN_KEY_LENGTH 16
 
+static inline void tcp_init_send_head(struct sock *sk)
+{
+ sk->sk_send_head = NULL;
+}
+
 /* Fastopen key context */
 struct tcp_fastopen_context {
  struct crypto_cipher *tfm;
@@ -1459,6 +1464,7 @@ static inline void tcp_write_queue_purge(struct sock *sk)
  sk_wmem_free_skb(sk, skb);
  sk_mem_reclaim(sk);
  tcp_clear_all_retrans_hints(tcp_sk(sk));
+ tcp_init_send_head(sk);
  inet_csk(sk)->icsk_backoff = 0;
 }
 
@@ -1520,11 +1526,6 @@ static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unli
  tcp_sk(sk)->highest_sack = NULL;
 }
 
-static inline void tcp_init_send_head(struct sock *sk)
-{
- sk->sk_send_head = NULL;
-}
-
 static inline void __tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb)
 {
  __skb_queue_tail(&sk->sk_write_queue, skb);
--
2.17.1


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

[PATCH 4/4] tcp: be more careful in tcp_fragment()

Tyler Hicks-2
In reply to this post by Tyler Hicks-2
From: Eric Dumazet <[hidden email]>

[ Upstream commit b617158dc096709d8600c53b6052144d12b89fab ]

Some applications set tiny SO_SNDBUF values and expect
TCP to just work. Recent patches to address CVE-2019-11478
broke them in case of losses, since retransmits might
be prevented.

We should allow these flows to make progress.

This patch allows the first and last skb in retransmit queue
to be split even if memory limits are hit.

It also adds the some room due to the fact that tcp_sendmsg()
and tcp_sendpage() might overshoot sk_wmem_queued by about one full
TSO skb (64KB size). Note this allowance was already present
in stable backports for kernels < 4.15

Note for < 4.15 backports :
 tcp_rtx_queue_tail() will probably look like :

static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
{
        struct sk_buff *skb = tcp_send_head(sk);

        return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
}

Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits")
Signed-off-by: Eric Dumazet <[hidden email]>
Reported-by: Andrew Prout <[hidden email]>
Tested-by: Andrew Prout <[hidden email]>
Tested-by: Jonathan Lemon <[hidden email]>
Tested-by: Michal Kubecek <[hidden email]>
Acked-by: Neal Cardwell <[hidden email]>
Acked-by: Yuchung Cheng <[hidden email]>
Acked-by: Christoph Paasch <[hidden email]>
Cc: Jonathan Looney <[hidden email]>
Signed-off-by: David S. Miller <[hidden email]>
Signed-off-by: Sasha Levin <[hidden email]>

CVE-2019-11478

(cherry picked from commit 5917ca48053447dac0e13c51ed7d4e2471a1cbc9 linux-stable)
Signed-off-by: Tyler Hicks <[hidden email]>
---
 include/net/tcp.h     | 17 +++++++++++++++++
 net/ipv4/tcp_output.c | 11 ++++++++++-
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 77438a8406ec..0410fd29d569 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1526,6 +1526,23 @@ static inline void tcp_check_send_head(struct sock *sk, struct sk_buff *skb_unli
  tcp_sk(sk)->highest_sack = NULL;
 }
 
+static inline struct sk_buff *tcp_rtx_queue_head(const struct sock *sk)
+{
+ struct sk_buff *skb = tcp_write_queue_head(sk);
+
+ if (skb == tcp_send_head(sk))
+ skb = NULL;
+
+ return skb;
+}
+
+static inline struct sk_buff *tcp_rtx_queue_tail(const struct sock *sk)
+{
+ struct sk_buff *skb = tcp_send_head(sk);
+
+ return skb ? tcp_write_queue_prev(sk, skb) : tcp_write_queue_tail(sk);
+}
+
 static inline void __tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb)
 {
  __skb_queue_tail(&sk->sk_write_queue, skb);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 1b2a6ab5da9d..0d53506dac22 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1153,6 +1153,7 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
  struct tcp_sock *tp = tcp_sk(sk);
  struct sk_buff *buff;
  int nsize, old_factor;
+ long limit;
  int nlen;
  u8 flags;
 
@@ -1163,7 +1164,15 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
  if (nsize < 0)
  nsize = 0;
 
- if (unlikely((sk->sk_wmem_queued >> 1) > sk->sk_sndbuf + 0x20000)) {
+ /* tcp_sendmsg() can overshoot sk_wmem_queued by one full size skb.
+ * We need some allowance to not penalize applications setting small
+ * SO_SNDBUF values.
+ * Also allow first and last skb in retransmit queue to be split.
+ */
+ limit = sk->sk_sndbuf + 2 * SKB_TRUESIZE(GSO_MAX_SIZE);
+ if (unlikely((sk->sk_wmem_queued >> 1) > limit &&
+     skb != tcp_rtx_queue_head(sk) &&
+     skb != tcp_rtx_queue_tail(sk))) {
  NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPWQUEUETOOBIG);
  return -ENOMEM;
  }
--
2.17.1


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

ACK+cmnt: [PATCH 0/4][SRU][X] Multiple TCP Fixups

Thadeu Lima de Souza Cascardo-3
In reply to this post by Tyler Hicks-2
On Thu, Aug 29, 2019 at 12:49:44AM +0000, Tyler Hicks wrote:

> This series reverts my backport of a fixup for the CVE-2019-11478 fix
> and applies the version of the fixup that the TCP maintainer provided
> for the 4.4 linux-stable tree. It also includes another fixup, from
> upstream, which addresses some performance issues that were reported to
> me. Details can be found here:
>
>  https://databricks.com/blog/2019/08/01/network-performance-regressions-from-tcp-sack-vulnerability-fixes.html
>
> The fix for CVE-2019-15239 is sandwiched in the middle of the series. It
> made cherry-picking of the entire series from linux-stable possible but,
> more importantly, it fixes a flaw that was caused by a bad backport in
> the linux-stable tree.
>
>  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-11478
>  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-15239


Acked-by: Thadeu Lima de Souza Cascardo <[hidden email]>

I'm all for making our code more in line with linux-stable. Thanks!

Also, the NULL pointer dereference, which seems to be the point of the
patchset. Yay! \o/

Cheking for the limits using truesize and allowing head and tail to be split
seem safer from the point of view of performance regression, or even possible
regressions with small send buffers. Which was the point of the backport in the
first place, but who knows what other usecases are out there.

Which takes me to the point of the comment. Was this patchset tested with the
example regression we had? The packetdrill test that set the small send buffer
and got stuck on a write? And was it tested against the PoCs for the SACK
attacks?

Thanks.
Cascardo.

>
> Note that the Ubuntu CVE Tracker entry for CVE-2019-15239 is not fully
> updated with breaks-fix commit info as I'm still trying to decide how
> best to do that for this somewhat unique CVE that affects linux-stable
> but not linux.
>
> I believe that I was able to reproduce the some of the nondeterministic
> performance regression that Databricks was seeing using netperf while
> running the 4.4.0-159.187-generic. I didn't see this behavior while
> testing the 4.4.0-150.176-generic kernel, which is the last published
> kernel before CVE-2019-11478 was fixed. I also don't see the behavior
> once these patches are applied to the 4.4.0-159.187-generic kernel.
>
> Tyler
>
> Eric Dumazet (2):
>   tcp: refine memory limit test in tcp_fragment()
>   tcp: be more careful in tcp_fragment()
>
> Soheil Hassas Yeganeh (1):
>   tcp: reset sk_send_head in tcp_write_queue_purge
>
> Tyler Hicks (1):
>   UBUNTU: SAUCE: Revert "tcp: refine memory limit test in
>     tcp_fragment()"
>
>  include/net/tcp.h     | 22 ++++++++++++++++++++--
>  net/ipv4/tcp_output.c | 12 ++++++++++--
>  2 files changed, 30 insertions(+), 4 deletions(-)
>
> --
> 2.17.1
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

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

Re: ACK+cmnt: [PATCH 0/4][SRU][X] Multiple TCP Fixups

Tyler Hicks-2
On 2019-08-30 08:43:17, Thadeu Lima de Souza Cascardo wrote:

> On Thu, Aug 29, 2019 at 12:49:44AM +0000, Tyler Hicks wrote:
> > This series reverts my backport of a fixup for the CVE-2019-11478 fix
> > and applies the version of the fixup that the TCP maintainer provided
> > for the 4.4 linux-stable tree. It also includes another fixup, from
> > upstream, which addresses some performance issues that were reported to
> > me. Details can be found here:
> >
> >  https://databricks.com/blog/2019/08/01/network-performance-regressions-from-tcp-sack-vulnerability-fixes.html
> >
> > The fix for CVE-2019-15239 is sandwiched in the middle of the series. It
> > made cherry-picking of the entire series from linux-stable possible but,
> > more importantly, it fixes a flaw that was caused by a bad backport in
> > the linux-stable tree.
> >
> >  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-11478
> >  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-15239
>
>
> Acked-by: Thadeu Lima de Souza Cascardo <[hidden email]>
>
> I'm all for making our code more in line with linux-stable. Thanks!
>
> Also, the NULL pointer dereference, which seems to be the point of the
> patchset. Yay! \o/
>
> Cheking for the limits using truesize and allowing head and tail to be split
> seem safer from the point of view of performance regression, or even possible
> regressions with small send buffers. Which was the point of the backport in the
> first place, but who knows what other usecases are out there.
>
> Which takes me to the point of the comment. Was this patchset tested with the
> example regression we had? The packetdrill test that set the small send buffer
> and got stuck on a write? And was it tested against the PoCs for the SACK
> attacks?

My testing for these changes was focused on the fix for the reported
performance regression. I didn't test with the PoC or the packetdrill
test although I wish that I would have now that you mention it...

Tyler

>
> Thanks.
> Cascardo.
>
> >
> > Note that the Ubuntu CVE Tracker entry for CVE-2019-15239 is not fully
> > updated with breaks-fix commit info as I'm still trying to decide how
> > best to do that for this somewhat unique CVE that affects linux-stable
> > but not linux.
> >
> > I believe that I was able to reproduce the some of the nondeterministic
> > performance regression that Databricks was seeing using netperf while
> > running the 4.4.0-159.187-generic. I didn't see this behavior while
> > testing the 4.4.0-150.176-generic kernel, which is the last published
> > kernel before CVE-2019-11478 was fixed. I also don't see the behavior
> > once these patches are applied to the 4.4.0-159.187-generic kernel.
> >
> > Tyler
> >
> > Eric Dumazet (2):
> >   tcp: refine memory limit test in tcp_fragment()
> >   tcp: be more careful in tcp_fragment()
> >
> > Soheil Hassas Yeganeh (1):
> >   tcp: reset sk_send_head in tcp_write_queue_purge
> >
> > Tyler Hicks (1):
> >   UBUNTU: SAUCE: Revert "tcp: refine memory limit test in
> >     tcp_fragment()"
> >
> >  include/net/tcp.h     | 22 ++++++++++++++++++++--
> >  net/ipv4/tcp_output.c | 12 ++++++++++--
> >  2 files changed, 30 insertions(+), 4 deletions(-)
> >
> > --
> > 2.17.1
> >
> >
> > --
> > kernel-team mailing list
> > [hidden email]
> > https://lists.ubuntu.com/mailman/listinfo/kernel-team

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

NAK: [PATCH 0/4][SRU][X] Multiple TCP Fixups

Tyler Hicks-2
In reply to this post by Tyler Hicks-2
On 2019-08-29 00:49:44, Tyler Hicks wrote:

> This series reverts my backport of a fixup for the CVE-2019-11478 fix
> and applies the version of the fixup that the TCP maintainer provided
> for the 4.4 linux-stable tree. It also includes another fixup, from
> upstream, which addresses some performance issues that were reported to
> me. Details can be found here:
>
>  https://databricks.com/blog/2019/08/01/network-performance-regressions-from-tcp-sack-vulnerability-fixes.html
>
> The fix for CVE-2019-15239 is sandwiched in the middle of the series. It
> made cherry-picking of the entire series from linux-stable possible but,
> more importantly, it fixes a flaw that was caused by a bad backport in
> the linux-stable tree.
>
>  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-11478
>  https://people.canonical.com/~ubuntu-security/cve/?cve=CVE-2019-15239
>
> Note that the Ubuntu CVE Tracker entry for CVE-2019-15239 is not fully
> updated with breaks-fix commit info as I'm still trying to decide how
> best to do that for this somewhat unique CVE that affects linux-stable
> but not linux.
>
> I believe that I was able to reproduce the some of the nondeterministic
> performance regression that Databricks was seeing using netperf while
> running the 4.4.0-159.187-generic. I didn't see this behavior while
> testing the 4.4.0-150.176-generic kernel, which is the last published
> kernel before CVE-2019-11478 was fixed. I also don't see the behavior
> once these patches are applied to the 4.4.0-159.187-generic kernel.

These changes are all in the 4.4.189 upstream linux-stable pull request
that was prepared by Connor. This series sent out by me can be ignored.

Tyler

>
> Tyler
>
> Eric Dumazet (2):
>   tcp: refine memory limit test in tcp_fragment()
>   tcp: be more careful in tcp_fragment()
>
> Soheil Hassas Yeganeh (1):
>   tcp: reset sk_send_head in tcp_write_queue_purge
>
> Tyler Hicks (1):
>   UBUNTU: SAUCE: Revert "tcp: refine memory limit test in
>     tcp_fragment()"
>
>  include/net/tcp.h     | 22 ++++++++++++++++++++--
>  net/ipv4/tcp_output.c | 12 ++++++++++--
>  2 files changed, 30 insertions(+), 4 deletions(-)
>
> --
> 2.17.1
>
>
> --
> kernel-team mailing list
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

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