From: Greg Kroah-Hartman Date: Thu, 19 Sep 2019 20:08:25 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v4.4.194~13 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=83f8f38e0a2d69ca7ae6c9dca9c44cfe529bc04b;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch tcp-don-t-dequeue-syn-fin-segments-from-write-queue.patch tcp-reset-send_head-when-removing-skb-from-write-queue.patch --- diff --git a/queue-4.14/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch b/queue-4.14/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch new file mode 100644 index 00000000000..316d173f33b --- /dev/null +++ b/queue-4.14/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch @@ -0,0 +1,105 @@ +From bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 Mon Sep 17 00:00:00 2001 +From: Kees Cook +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 + +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 +Reported-by: Ali Saidi +Cc: Ali Saidi +Cc: Guenter Roeck +Cc: Michal Hocko +Cc: Matthew Wilcox +Cc: Thomas Gleixner +Cc: Jann Horn +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Cc: Frank van der Linden +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.14/series b/queue-4.14/series index bf64113247c..dd53ab1a063 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -53,3 +53,6 @@ iommu-amd-flush-old-domains-in-kdump-kernel.patch 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 diff --git a/queue-4.14/tcp-don-t-dequeue-syn-fin-segments-from-write-queue.patch b/queue-4.14/tcp-don-t-dequeue-syn-fin-segments-from-write-queue.patch new file mode 100644 index 00000000000..da14115ee2e --- /dev/null +++ b/queue-4.14/tcp-don-t-dequeue-syn-fin-segments-from-write-queue.patch @@ -0,0 +1,91 @@ +From cpaasch@apple.com Thu Sep 19 22:07:30 2019 +From: Christoph Paasch +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 +Cc: David Miller , Eric Dumazet , Jason Baron , Vladimir Rutsky , Soheil Hassas Yeganeh , Neal Cardwell +Message-ID: <20190913200819.32686-3-cpaasch@apple.com> + +From: Christoph Paasch + +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] +[ 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] + +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 +Cc: Jason Baron +Cc: Vladimir Rutsky +Cc: Soheil Hassas Yeganeh +Cc: Neal Cardwell +Signed-off-by: Christoph Paasch +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/tcp-reset-send_head-when-removing-skb-from-write-queue.patch b/queue-4.14/tcp-reset-send_head-when-removing-skb-from-write-queue.patch new file mode 100644 index 00000000000..b5445dd4ccf --- /dev/null +++ b/queue-4.14/tcp-reset-send_head-when-removing-skb-from-write-queue.patch @@ -0,0 +1,69 @@ +From cpaasch@apple.com Thu Sep 19 22:05:39 2019 +From: Christoph Paasch +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 +Cc: David Miller , Eric Dumazet , Jason Baron , Vladimir Rutsky , Soheil Hassas Yeganeh , Neal Cardwell +Message-ID: <20190913200819.32686-2-cpaasch@apple.com> + +From: Christoph Paasch + +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 +Cc: Jason Baron +Cc: Vladimir Rutsky +Cc: Soheil Hassas Yeganeh +Cc: Neal Cardwell +Signed-off-by: Christoph Paasch +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + }