linux.git, branch v3.16.82

Linux 3.16.82

2020-02-11T20:03:59+00:00

s390: Fix unmatched preempt_disable() on exit

2020-02-11T20:03:58+00:00

exit_thread_runtime_instr() may return with preemption disabled,
leading to the following lockdep splat:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
in_atomic(): 1, irqs_disabled(): 0, pid: 565, name: kworker/u2:0
no locks held by kworker/u2:0/565.
CPU: 0 PID: 565 Comm: kworker/u2:0 Not tainted 3.16.81-00145-gafe1c874fa44 #1
       00000000025dbbd8 00000000025dbbe8 0000000000000002 0000000000000000 
       00000000025dbc78 00000000025dbbf0 00000000025dbbf0 000000000098c55c 
       0000000000000000 00000000025d05b8 00000000025d1590 0000000000000000 
       0000000000000000 000000000000000c 00000000025dbbd8 0000000000000070 
       00000000009b7220 000000000098c55c 00000000025dbbd8 00000000025dbc20 
Call Trace:
([<000000000098c4ce>] show_trace+0xb6/0xd8)
 [<000000000098c592>] show_stack+0xa2/0xd8
 [<0000000000992c04>] dump_stack+0xc4/0x118
 [<0000000000191e20>] __might_sleep+0x230/0x238
 [<000000000099fbb0>] mutex_lock_nested+0x48/0x3d8
 [<000000000025e33e>] perf_event_exit_task+0x36/0x398
 [<0000000000158536>] do_exit+0x3ae/0xca0
 [<0000000000175826>] ____call_usermodehelper+0x136/0x148
 [<00000000009a550a>] kernel_thread_starter+0x6/0xc
 [<00000000009a5504>] kernel_thread_starter+0x0/0xc

This was fixed by commit 8d9047f8b967 "s390/runtime instrumentation:
simplify task exit handling" upstream, but that won't apply here.

Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Signed-off-by: Ben Hutchings

mmc: sdhci-s3c: solve problem with sleeping in atomic context

2020-02-11T20:03:57+00:00

commit 017210d1c0dc2e2d3b142985cb31d90b98dc0f0f upstream.

This change addresses following problem:

[    2.560726] ------------[ cut here ]------------
[    2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744 lockdep_trace_alloc+0xec/0x118()
[    2.574439] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    2.579821] Modules linked in:
[    2.583038] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.0-next-20141216-00002-g4ff197fc1902-dirty #1318
[    2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[    2.599892] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[    2.607612] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[    2.614822] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[    2.622885] [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[    2.631569] [] (warn_slowpath_fmt) from [] (lockdep_trace_alloc+0xec/0x118)
[    2.640246] [] (lockdep_trace_alloc) from [] (__kmalloc+0x3c/0x1cc)
[    2.648240] [] (__kmalloc) from [] (clk_fetch_parent_index+0xb8/0xd4)
[    2.656390] [] (clk_fetch_parent_index) from [] (clk_calc_new_rates+0xe0/0x1fc)
[    2.665415] [] (clk_calc_new_rates) from [] (clk_calc_new_rates+0x1b4/0x1fc)
[    2.674181] [] (clk_calc_new_rates) from [] (clk_set_rate+0x50/0xc8)
[    2.682265] [] (clk_set_rate) from [] (sdhci_cmu_set_clock+0x68/0x16c)
[    2.690503] [] (sdhci_cmu_set_clock) from [] (sdhci_do_set_ios+0xf0/0x64c)
[    2.699095] [] (sdhci_do_set_ios) from [] (sdhci_set_ios+0x20/0x2c)
[    2.707080] [] (sdhci_set_ios) from [] (mmc_power_up+0x118/0x1fc)
[    2.714889] [] (mmc_power_up) from [] (mmc_start_host+0x44/0x6c)
[    2.722615] [] (mmc_start_host) from [] (mmc_add_host+0x58/0x7c)
[    2.730341] [] (mmc_add_host) from [] (sdhci_add_host+0x968/0xd94)
[    2.738240] [] (sdhci_add_host) from [] (sdhci_s3c_probe+0x354/0x52c)
[    2.746406] [] (sdhci_s3c_probe) from [] (platform_drv_probe+0x48/0xa4)
[    2.754733] [] (platform_drv_probe) from [] (driver_probe_device+0x13c/0x37c)
[    2.763585] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98)
[    2.772003] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[    2.780163] [] (bus_for_each_dev) from [] (bus_add_driver+0xe4/0x200)
[    2.788322] [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[    2.796308] [] (driver_register) from [] (do_one_initcall+0xac/0x1f0)
[    2.804473] [] (do_one_initcall) from [] (kernel_init_freeable+0x10c/0x1d8)
[    2.813153] [] (kernel_init_freeable) from [] (kernel_init+0x28/0x108)
[    2.821398] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
[    2.828939] ---[ end trace 03cc00e539849d1f ]---

clk_set_rate() tries to take clk's prepare_lock mutex while being in atomic
context entered in sdhci_do_set_ios().

The solution is inspired by similar situation in sdhci_set_power() also called
from sdhci_do_set_ios():

                spin_unlock_irq(&host->lock);
                mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
                spin_lock_irq(&host->lock);

Note that since sdhci_s3c_set_clock() sets SDHCI_CLOCK_CARD_EN, proposed change
first resets this bit. It is reset anyway (by setting SDHCI_CLOCK_INT_EN bit
only) after call to clk_set_rate() in order to wait for the clock to stabilize
and is set again as soon as the clock becomes stable.

Signed-off-by: Paul Osmialowski 
Tested-by: Jaehoon Chung 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

mmc: sdhci-s3c: Check if clk_set_rate() succeeds

2020-02-11T20:03:57+00:00

commit cd0cfdd2485e6252b3c69284bf09d06c4d303116 upstream.

It is possible that we may fail to set the clock rate, if we do so then
log the failure and don't bother reprogramming the IP.

Signed-off-by: Mark Brown 
Acked-by: Jaehoon Chung 
Signed-off-by: Ulf Hansson 
Signed-off-by: Ben Hutchings

deb-pkg: remove obsolete -isp option to dpkg-gencontrol

2020-02-11T20:03:57+00:00

commit 4204111c028d492019e4440d12e9e3d062db4283 upstream.

The -isp option has been deprecated, after it became the default
behaviour back in 2006.

Since dpkg 1.17.11, dpkg-gencontrol emits a warning on -isp usage.

References: https://bugs.debian.org/215233
Signed-off-by: Asbjoern Sloth Toennesen 
Signed-off-by: Michal Marek 
Signed-off-by: Ben Hutchings

inet: protect against too small mtu values.

2020-02-11T20:03:57+00:00

commit 501a90c945103e8627406763dac418f20f3837b2 upstream.

syzbot was once again able to crash a host by setting a very small mtu
on loopback device.

Let's make inetdev_valid_mtu() available in include/net/ip.h,
and use it in ip_setup_cork(), so that we protect both ip_append_page()
and __ip_append_data()

Also add a READ_ONCE() when the device mtu is read.

Pairs this lockless read with one WRITE_ONCE() in __dev_set_mtu(),
even if other code paths might write over this field.

Add a big comment in include/linux/netdevice.h about dev->mtu
needing READ_ONCE()/WRITE_ONCE() annotations.

Hopefully we will add the missing ones in followup patches.

[1]

refcount_t: saturated; leaking memory.
WARNING: CPU: 0 PID: 9464 at lib/refcount.c:22 refcount_warn_saturate+0x138/0x1f0 lib/refcount.c:22
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 9464 Comm: syz-executor850 Not tainted 5.4.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x197/0x210 lib/dump_stack.c:118
 panic+0x2e3/0x75c kernel/panic.c:221
 __warn.cold+0x2f/0x3e kernel/panic.c:582
 report_bug+0x289/0x300 lib/bug.c:195
 fixup_bug arch/x86/kernel/traps.c:174 [inline]
 fixup_bug arch/x86/kernel/traps.c:169 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:refcount_warn_saturate+0x138/0x1f0 lib/refcount.c:22
Code: 06 31 ff 89 de e8 c8 f5 e6 fd 84 db 0f 85 6f ff ff ff e8 7b f4 e6 fd 48 c7 c7 e0 71 4f 88 c6 05 56 a6 a4 06 01 e8 c7 a8 b7 fd <0f> 0b e9 50 ff ff ff e8 5c f4 e6 fd 0f b6 1d 3d a6 a4 06 31 ff 89
RSP: 0018:ffff88809689f550 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff815e4336 RDI: ffffed1012d13e9c
RBP: ffff88809689f560 R08: ffff88809c50a3c0 R09: fffffbfff15d31b1
R10: fffffbfff15d31b0 R11: ffffffff8ae98d87 R12: 0000000000000001
R13: 0000000000040100 R14: ffff888099041104 R15: ffff888218d96e40
 refcount_add include/linux/refcount.h:193 [inline]
 skb_set_owner_w+0x2b6/0x410 net/core/sock.c:1999
 sock_wmalloc+0xf1/0x120 net/core/sock.c:2096
 ip_append_page+0x7ef/0x1190 net/ipv4/ip_output.c:1383
 udp_sendpage+0x1c7/0x480 net/ipv4/udp.c:1276
 inet_sendpage+0xdb/0x150 net/ipv4/af_inet.c:821
 kernel_sendpage+0x92/0xf0 net/socket.c:3794
 sock_sendpage+0x8b/0xc0 net/socket.c:936
 pipe_to_sendpage+0x2da/0x3c0 fs/splice.c:458
 splice_from_pipe_feed fs/splice.c:512 [inline]
 __splice_from_pipe+0x3ee/0x7c0 fs/splice.c:636
 splice_from_pipe+0x108/0x170 fs/splice.c:671
 generic_splice_sendpage+0x3c/0x50 fs/splice.c:842
 do_splice_from fs/splice.c:861 [inline]
 direct_splice_actor+0x123/0x190 fs/splice.c:1035
 splice_direct_to_actor+0x3b4/0xa30 fs/splice.c:990
 do_splice_direct+0x1da/0x2a0 fs/splice.c:1078
 do_sendfile+0x597/0xd00 fs/read_write.c:1464
 __do_sys_sendfile64 fs/read_write.c:1525 [inline]
 __se_sys_sendfile64 fs/read_write.c:1511 [inline]
 __x64_sys_sendfile64+0x1dd/0x220 fs/read_write.c:1511
 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441409
Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fffb64c4f78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441409
RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000005
RBP: 0000000000073b8a R08: 0000000000000010 R09: 0000000000000010
R10: 0000000000010001 R11: 0000000000000246 R12: 0000000000402180
R13: 0000000000402210 R14: 0000000000000000 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..

Fixes: 1470ddf7f8ce ("inet: Remove explicit write references to sk/inet in ip_append_data")
Signed-off-by: Eric Dumazet 
Reported-by: syzbot 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()
 - Keep using literal 68 instead of IPV4_MIN_MTU
 - Adjust context]
Signed-off-by: Ben Hutchings

tcp: Protect accesses to .ts_recent_stamp with {READ,WRITE}_ONCE()

2020-02-11T20:03:56+00:00

commit 721c8dafad26ccfa90ff659ee19755e3377b829d upstream.

Syncookies borrow the ->rx_opt.ts_recent_stamp field to store the
timestamp of the last synflood. Protect them with READ_ONCE() and
WRITE_ONCE() since reads and writes aren't serialised.

Use of .rx_opt.ts_recent_stamp for storing the synflood timestamp was
introduced by a0f82f64e269 ("syncookies: remove last_synq_overflow from
struct tcp_sock"). But unprotected accesses were already there when
timestamp was stored in .last_synq_overflow.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Guillaume Nault 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE()]
Signed-off-by: Ben Hutchings

tcp: fix rejected syncookies due to stale timestamps

2020-02-11T20:03:56+00:00

commit 04d26e7b159a396372646a480f4caa166d1b6720 upstream.

If no synflood happens for a long enough period of time, then the
synflood timestamp isn't refreshed and jiffies can advance so much
that time_after32() can't accurately compare them any more.

Therefore, we can end up in a situation where time_after32(now,
last_overflow + HZ) returns false, just because these two values are
too far apart. In that case, the synflood timestamp isn't updated as
it should be, which can trick tcp_synq_no_recent_overflow() into
rejecting valid syncookies.

For example, let's consider the following scenario on a system
with HZ=1000:

  * The synflood timestamp is 0, either because that's the timestamp
    of the last synflood or, more commonly, because we're working with
    a freshly created socket.

  * We receive a new SYN, which triggers synflood protection. Let's say
    that this happens when jiffies == 2147484649 (that is,
    'synflood timestamp' + HZ + 2^31 + 1).

  * Then tcp_synq_overflow() doesn't update the synflood timestamp,
    because time_after32(2147484649, 1000) returns false.
    With:
      - 2147484649: the value of jiffies, aka. 'now'.
      - 1000: the value of 'last_overflow' + HZ.

  * A bit later, we receive the ACK completing the 3WHS. But
    cookie_v[46]_check() rejects it because tcp_synq_no_recent_overflow()
    says that we're not under synflood. That's because
    time_after32(2147484649, 120000) returns false.
    With:
      - 2147484649: the value of jiffies, aka. 'now'.
      - 120000: the value of 'last_overflow' + TCP_SYNCOOKIE_VALID.

    Of course, in reality jiffies would have increased a bit, but this
    condition will last for the next 119 seconds, which is far enough
    to accommodate for jiffie's growth.

Fix this by updating the overflow timestamp whenever jiffies isn't
within the [last_overflow, last_overflow + HZ] range. That shouldn't
have any performance impact since the update still happens at most once
per second.

Now we're guaranteed to have fresh timestamps while under synflood, so
tcp_synq_no_recent_overflow() can safely use it with time_after32() in
such situations.

Stale timestamps can still make tcp_synq_no_recent_overflow() return
the wrong verdict when not under synflood. This will be handled in the
next patch.

For 64 bits architectures, the problem was introduced with the
conversion of ->tw_ts_recent_stamp to 32 bits integer by commit
cca9bab1b72c ("tcp: use monotonic timestamps for PAWS").
The problem has always been there on 32 bits architectures.

Fixes: cca9bab1b72c ("tcp: use monotonic timestamps for PAWS")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Guillaume Nault 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tcp: syncookies: extend validity range

2020-02-11T20:03:55+00:00

commit 264ea103a7473f51aced838e68ed384ea2c759f5 upstream.

Now we allow storing more request socks per listener, we might
hit syncookie mode less often and hit following bug in our stack :

When we send a burst of syncookies, then exit this mode,
tcp_synq_no_recent_overflow() can return false if the ACK packets coming
from clients are coming three seconds after the end of syncookie
episode.

This is a way too strong requirement and conflicts with rest of
syncookie code which allows ACK to be aged up to 2 minutes.

Perfectly valid ACK packets are dropped just because clients might be
in a crowded wifi environment or on another planet.

So let's fix this, and also change tcp_synq_overflow() to not
dirty a cache line for every syncookie we send, as we are under attack.

Signed-off-by: Eric Dumazet 
Acked-by: Florian Westphal 
Acked-by: Yuchung Cheng 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

tcp: md5: fix potential overestimation of TCP option space

2020-02-11T20:03:55+00:00

commit 9424e2e7ad93ffffa88f882c9bc5023570904b55 upstream.

Back in 2008, Adam Langley fixed the corner case of packets for flows
having all of the following options : MD5 TS SACK

Since MD5 needs 20 bytes, and TS needs 12 bytes, no sack block
can be cooked from the remaining 8 bytes.

tcp_established_options() correctly sets opts->num_sack_blocks
to zero, but returns 36 instead of 32.

This means TCP cooks packets with 4 extra bytes at the end
of options, containing unitialized bytes.

Fixes: 33ad798c924b ("tcp: options clean up")
Signed-off-by: Eric Dumazet 
Reported-by: syzbot 
Acked-by: Neal Cardwell 
Acked-by: Soheil Hassas Yeganeh 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings