--- /dev/null
+From bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Tue, 14 May 2019 15:43:57 -0700
+Subject: binfmt_elf: move brk out of mmap when doing direct loader exec
+
+From: Kees Cook <keescook@chromium.org>
+
+commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream.
+
+Commmit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
+made changes in the rare case when the ELF loader was directly invoked
+(e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of
+the loader), by moving into the mmap region to avoid both ET_EXEC and
+PIE binaries. This had the effect of also moving the brk region into
+mmap, which could lead to the stack and brk being arbitrarily close to
+each other. An unlucky process wouldn't get its requested stack size
+and stack allocations could end up scribbling on the heap.
+
+This is illustrated here. In the case of using the loader directly, brk
+(so helpfully identified as "[heap]") is allocated with the _loader_ not
+the binary. For example, with ASLR entirely disabled, you can see this
+more clearly:
+
+$ /bin/cat /proc/self/maps
+555555554000-55555555c000 r-xp 00000000 ... /bin/cat
+55555575b000-55555575c000 r--p 00007000 ... /bin/cat
+55555575c000-55555575d000 rw-p 00008000 ... /bin/cat
+55555575d000-55555577e000 rw-p 00000000 ... [heap]
+...
+7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
+7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
+7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffe000-7ffff7fff000 rw-p 00000000 ...
+7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
+
+$ /lib/x86_64-linux-gnu/ld-2.27.so /bin/cat /proc/self/maps
+...
+7ffff7bcc000-7ffff7bd4000 r-xp 00000000 ... /bin/cat
+7ffff7bd4000-7ffff7dd3000 ---p 00008000 ... /bin/cat
+7ffff7dd3000-7ffff7dd4000 r--p 00007000 ... /bin/cat
+7ffff7dd4000-7ffff7dd5000 rw-p 00008000 ... /bin/cat
+7ffff7dd5000-7ffff7dfc000 r-xp 00000000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7fb2000-7ffff7fd6000 rw-p 00000000 ...
+7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
+7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
+7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
+7ffff7ffe000-7ffff8020000 rw-p 00000000 ... [heap]
+7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
+
+The solution is to move brk out of mmap and into ELF_ET_DYN_BASE since
+nothing is there in the direct loader case (and ET_EXEC is still far
+away at 0x400000). Anything that ran before should still work (i.e.
+the ultimately-launched binary already had the brk very far from its
+text, so this should be no different from a COMPAT_BRK standpoint). The
+only risk I see here is that if someone started to suddenly depend on
+the entire memory space lower than the mmap region being available when
+launching binaries via a direct loader execs which seems highly
+unlikely, I'd hope: this would mean a binary would _not_ work when
+exec()ed normally.
+
+(Note that this is only done under CONFIG_ARCH_HAS_ELF_RANDOMIZATION
+when randomization is turned on.)
+
+Link: http://lkml.kernel.org/r/20190422225727.GA21011@beast
+Link: https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com
+Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Reported-by: Ali Saidi <alisaidi@amazon.com>
+Cc: Ali Saidi <alisaidi@amazon.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Jann Horn <jannh@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Frank van der Linden <fllinden@amazon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/binfmt_elf.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/binfmt_elf.c
++++ b/fs/binfmt_elf.c
+@@ -1116,6 +1116,17 @@ static int load_elf_binary(struct linux_
+ current->mm->start_stack = bprm->p;
+
+ if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {
++ /*
++ * For architectures with ELF randomization, when executing
++ * a loader directly (i.e. no interpreter listed in ELF
++ * headers), move the brk area out of the mmap region
++ * (since it grows up, and may collide early with the stack
++ * growing down), and into the unused ELF_ET_DYN_BASE region.
++ */
++ if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && !interpreter)
++ current->mm->brk = current->mm->start_brk =
++ ELF_ET_DYN_BASE;
++
+ current->mm->brk = current->mm->start_brk =
+ arch_randomize_brk(current->mm);
+ #ifdef compat_brk_randomized
iommu-amd-fix-race-in-increase_address_space.patch
pci-kirin-fix-section-mismatch-warning.patch
floppy-fix-usercopy-direction.patch
+binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch
+tcp-reset-send_head-when-removing-skb-from-write-queue.patch
+tcp-don-t-dequeue-syn-fin-segments-from-write-queue.patch
--- /dev/null
+From cpaasch@apple.com Thu Sep 19 22:07:30 2019
+From: Christoph Paasch <cpaasch@apple.com>
+Date: Fri, 13 Sep 2019 13:08:19 -0700
+Subject: tcp: Don't dequeue SYN/FIN-segments from write-queue
+To: stable@vger.kernel.org, netdev@vger.kernel.org, gregkh@linuxfoundation.org, Sasha Levin <sashal@kernel.org>
+Cc: David Miller <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jason Baron <jbaron@akamai.com>, Vladimir Rutsky <rutsky@google.com>, Soheil Hassas Yeganeh <soheil@google.com>, Neal Cardwell <ncardwell@google.com>
+Message-ID: <20190913200819.32686-3-cpaasch@apple.com>
+
+From: Christoph Paasch <cpaasch@apple.com>
+
+If a SYN/FIN-segment is on the write-queue, skb->len is 0, but the
+segment actually has been transmitted. end_seq and seq of the tcp_skb_cb
+in that case will indicate this difference.
+
+We should not remove such segments from the write-queue as we might be
+in SYN_SENT-state and a retransmission-timer is running. When that one
+fires, packets_out will be 1, but the write-queue would be empty,
+resulting in:
+
+[ 61.280214] ------------[ cut here ]------------
+[ 61.281307] WARNING: CPU: 0 PID: 0 at net/ipv4/tcp_timer.c:429 tcp_retransmit_timer+0x18f9/0x2660
+[ 61.283498] Modules linked in:
+[ 61.284084] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.142 #58
+[ 61.285214] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
+[ 61.286644] task: ffffffff8401e1c0 task.stack: ffffffff84000000
+[ 61.287758] RIP: 0010:tcp_retransmit_timer+0x18f9/0x2660
+[ 61.288715] RSP: 0018:ffff88806ce07cb8 EFLAGS: 00010206
+[ 61.289669] RAX: ffffffff8401e1c0 RBX: ffff88805c998b00 RCX: 0000000000000006
+[ 61.290968] RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffff88805c9994d8
+[ 61.292314] RBP: ffff88805c99919a R08: ffff88807fff901c R09: ffff88807fff9008
+[ 61.293547] R10: ffff88807fff9017 R11: ffff88807fff9010 R12: ffff88805c998b30
+[ 61.294834] R13: ffffffff844b9380 R14: 0000000000000000 R15: ffff88805c99930c
+[ 61.296086] FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000
+[ 61.297523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 61.298646] CR2: 00007f721da50ff8 CR3: 0000000004014002 CR4: 00000000001606f0
+[ 61.299944] Call Trace:
+[ 61.300403] <IRQ>
+[ 61.300806] ? kvm_sched_clock_read+0x21/0x30
+[ 61.301689] ? sched_clock+0x5/0x10
+[ 61.302433] ? sched_clock_cpu+0x18/0x170
+[ 61.303173] tcp_write_timer_handler+0x2c1/0x7a0
+[ 61.304038] tcp_write_timer+0x13e/0x160
+[ 61.304794] call_timer_fn+0x14a/0x5f0
+[ 61.305480] ? tcp_write_timer_handler+0x7a0/0x7a0
+[ 61.306364] ? __next_timer_interrupt+0x140/0x140
+[ 61.307229] ? _raw_spin_unlock_irq+0x24/0x40
+[ 61.308033] ? tcp_write_timer_handler+0x7a0/0x7a0
+[ 61.308887] ? tcp_write_timer_handler+0x7a0/0x7a0
+[ 61.309760] run_timer_softirq+0xc41/0x1080
+[ 61.310539] ? trigger_dyntick_cpu.isra.33+0x180/0x180
+[ 61.311506] ? ktime_get+0x13f/0x1c0
+[ 61.312232] ? clockevents_program_event+0x10d/0x2f0
+[ 61.313158] __do_softirq+0x20b/0x96b
+[ 61.313889] irq_exit+0x1a7/0x1e0
+[ 61.314513] smp_apic_timer_interrupt+0xfc/0x4d0
+[ 61.315386] apic_timer_interrupt+0x8f/0xa0
+[ 61.316129] </IRQ>
+
+Followed by a panic.
+
+So, before removing an skb with skb->len == 0, let's make sure that the
+skb is really empty by checking the end_seq and seq.
+
+This patch needs to be backported only to 4.14 and older (among those
+that applied the backport of fdfc5c8594c2).
+
+Fixes: fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases")
+Cc: Eric Dumazet <edumazet@google.com>
+Cc: Jason Baron <jbaron@akamai.com>
+Cc: Vladimir Rutsky <rutsky@google.com>
+Cc: Soheil Hassas Yeganeh <soheil@google.com>
+Cc: Neal Cardwell <ncardwell@google.com>
+Signed-off-by: Christoph Paasch <cpaasch@apple.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/ipv4/tcp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/ipv4/tcp.c
++++ b/net/ipv4/tcp.c
+@@ -922,7 +922,8 @@ static int tcp_send_mss(struct sock *sk,
+ */
+ static void tcp_remove_empty_skb(struct sock *sk, struct sk_buff *skb)
+ {
+- if (skb && !skb->len) {
++ if (skb && !skb->len &&
++ TCP_SKB_CB(skb)->end_seq == TCP_SKB_CB(skb)->seq) {
+ tcp_unlink_write_queue(skb, sk);
+ tcp_check_send_head(sk, skb);
+ sk_wmem_free_skb(sk, skb);
--- /dev/null
+From cpaasch@apple.com Thu Sep 19 22:05:39 2019
+From: Christoph Paasch <cpaasch@apple.com>
+Date: Fri, 13 Sep 2019 13:08:18 -0700
+Subject: tcp: Reset send_head when removing skb from write-queue
+To: stable@vger.kernel.org, netdev@vger.kernel.org, gregkh@linuxfoundation.org, Sasha Levin <sashal@kernel.org>
+Cc: David Miller <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jason Baron <jbaron@akamai.com>, Vladimir Rutsky <rutsky@google.com>, Soheil Hassas Yeganeh <soheil@google.com>, Neal Cardwell <ncardwell@google.com>
+Message-ID: <20190913200819.32686-2-cpaasch@apple.com>
+
+From: Christoph Paasch <cpaasch@apple.com>
+
+syzkaller is not happy since commit fdfc5c8594c2 ("tcp: remove empty skb
+from write queue in error cases"):
+
+CPU: 1 PID: 13814 Comm: syz-executor.4 Not tainted 4.14.143 #5
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
+task: ffff888040105c00 task.stack: ffff8880649c0000
+RIP: 0010:tcp_sendmsg_locked+0x6b4/0x4390 net/ipv4/tcp.c:1350
+RSP: 0018:ffff8880649cf718 EFLAGS: 00010206
+RAX: 0000000000000014 RBX: 000000000000001e RCX: ffffc90000717000
+RDX: 0000000000000077 RSI: ffffffff82e760f7 RDI: 00000000000000a0
+RBP: ffff8880649cfaa8 R08: 1ffff1100c939e7a R09: ffff8880401063c8
+R10: 0000000000000003 R11: 0000000000000001 R12: dffffc0000000000
+R13: ffff888043d74750 R14: ffff888043d74500 R15: 000000000000001e
+FS: 00007f0afcb6d700(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000001b2ca22000 CR3: 0000000040496004 CR4: 00000000003606e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ tcp_sendmsg+0x2a/0x40 net/ipv4/tcp.c:1533
+ inet_sendmsg+0x173/0x4e0 net/ipv4/af_inet.c:784
+ sock_sendmsg_nosec net/socket.c:646 [inline]
+ sock_sendmsg+0xc3/0x100 net/socket.c:656
+ SYSC_sendto+0x35d/0x5e0 net/socket.c:1766
+ do_syscall_64+0x241/0x680 arch/x86/entry/common.c:292
+ entry_SYSCALL_64_after_hwframe+0x42/0xb7
+
+The problem is that we are removing an skb from the write-queue that
+could have been referenced by the sk_send_head. Thus, we need to check
+for the send_head's sanity after removing it.
+
+This patch needs to be backported only to 4.14 and older (among those
+that applied the backport of fdfc5c8594c2).
+
+Fixes: fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases")
+Cc: Eric Dumazet <edumazet@google.com>
+Cc: Jason Baron <jbaron@akamai.com>
+Cc: Vladimir Rutsky <rutsky@google.com>
+Cc: Soheil Hassas Yeganeh <soheil@google.com>
+Cc: Neal Cardwell <ncardwell@google.com>
+Signed-off-by: Christoph Paasch <cpaasch@apple.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/ipv4/tcp.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/net/ipv4/tcp.c
++++ b/net/ipv4/tcp.c
+@@ -924,8 +924,7 @@ static void tcp_remove_empty_skb(struct
+ {
+ if (skb && !skb->len) {
+ tcp_unlink_write_queue(skb, sk);
+- if (tcp_write_queue_empty(sk))
+- tcp_chrono_stop(sk, TCP_CHRONO_BUSY);
++ tcp_check_send_head(sk, skb);
+ sk_wmem_free_skb(sk, skb);
+ }
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
