linux-stable.git, branch v3.16.69

Linux 3.16.69

2019-06-20T17:11:30+00:00

tcp: enforce tcp_min_snd_mss in tcp_mtu_probing()

2019-06-20T17:11:29+00:00

commit 967c05aee439e6e5d7d805e195b3a20ef5c433d6 upstream.

If mtu probing is enabled tcp_mtu_probing() could very well end up
with a too small MSS.

Use the new sysctl tcp_min_snd_mss to make sure MSS search
is performed in an acceptable range.

CVE-2019-11479 -- tcp mss hardcoded to 48

Signed-off-by: Eric Dumazet 
Reported-by: Jonathan Lemon 
Cc: Jonathan Looney 
Acked-by: Neal Cardwell 
Cc: Yuchung Cheng 
Cc: Tyler Hicks 
Cc: Bruce Curtis 
Signed-off-by: David S. Miller 
[Salvatore Bonaccorso: Backport for context changes in 4.9.168]
[bwh: Backported to 3.16: The sysctl is global]
Signed-off-by: Ben Hutchings

tcp: add tcp_min_snd_mss sysctl

2019-06-20T17:11:28+00:00

commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream.

Some TCP peers announce a very small MSS option in their SYN and/or
SYN/ACK messages.

This forces the stack to send packets with a very high network/cpu
overhead.

Linux has enforced a minimal value of 48. Since this value includes
the size of TCP options, and that the options can consume up to 40
bytes, this means that each segment can include only 8 bytes of payload.

In some cases, it can be useful to increase the minimal value
to a saner value.

We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
reasons.

Note that TCP_MAXSEG socket option enforces a minimal value
of (TCP_MIN_MSS). David Miller increased this minimal value
in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.")
from 64 to 88.

We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.

CVE-2019-11479 -- tcp mss hardcoded to 48

Signed-off-by: Eric Dumazet 
Suggested-by: Jonathan Looney 
Acked-by: Neal Cardwell 
Cc: Yuchung Cheng 
Cc: Tyler Hicks 
Cc: Bruce Curtis 
Cc: Jonathan Lemon 
Signed-off-by: David S. Miller 
[Salvatore Bonaccorso: Backport for context changes in 4.9.168]
[bwh: Backported to 3.16: Make the sysctl global, consistent with
 net.ipv4.tcp_base_mss]
Signed-off-by: Ben Hutchings

tcp: tcp_fragment() should apply sane memory limits

2019-06-20T17:11:28+00:00

commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.

Jonathan Looney reported that a malicious peer can force a sender
to fragment its retransmit queue into tiny skbs, inflating memory
usage and/or overflow 32bit counters.

TCP allows an application to queue up to sk_sndbuf bytes,
so we need to give some allowance for non malicious splitting
of retransmit queue.

A new SNMP counter is added to monitor how many times TCP
did not allow to split an skb if the allowance was exceeded.

Note that this counter might increase in the case applications
use SO_SNDBUF socket option to lower sk_sndbuf.

CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the
	socket is already using more than half the allowed space

Signed-off-by: Eric Dumazet 
Reported-by: Jonathan Looney 
Acked-by: Neal Cardwell 
Acked-by: Yuchung Cheng 
Reviewed-by: Tyler Hicks 
Cc: Bruce Curtis 
Cc: Jonathan Lemon 
Signed-off-by: David S. Miller 
[Salvatore Bonaccorso: Adjust context for backport to 4.9.168]
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

tcp: limit payload size of sacked skbs

2019-06-20T17:11:28+00:00

commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff upstream.

Jonathan Looney reported that TCP can trigger the following crash
in tcp_shifted_skb() :

	BUG_ON(tcp_skb_pcount(skb) < pcount);

This can happen if the remote peer has advertized the smallest
MSS that linux TCP accepts : 48

An skb can hold 17 fragments, and each fragment can hold 32KB
on x86, or 64KB on PowerPC.

This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs
can overflow.

Note that tcp_sendmsg() builds skbs with less than 64KB
of payload, so this problem needs SACK to be enabled.
SACK blocks allow TCP to coalesce multiple skbs in the retransmit
queue, thus filling the 17 fragments to maximal capacity.

CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs

Backport notes, provided by Joao Martins 

v4.15 or since commit 737ff314563 ("tcp: use sequence distance to
detect reordering") had switched from the packet-based FACK tracking and
switched to sequence-based.

v4.14 and older still have the old logic and hence on
tcp_skb_shift_data() needs to retain its original logic and have
@fack_count in sync. In other words, we keep the increment of pcount with
tcp_skb_pcount(skb) to later used that to update fack_count. To make it
more explicit we track the new skb that gets incremented to pcount in
@next_pcount, and we get to avoid the constant invocation of
tcp_skb_pcount(skb) all together.

Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing")
Signed-off-by: Eric Dumazet 
Reported-by: Jonathan Looney 
Acked-by: Neal Cardwell 
Reviewed-by: Tyler Hicks 
Cc: Yuchung Cheng 
Cc: Bruce Curtis 
Cc: Jonathan Lemon 
Signed-off-by: David S. Miller 
[Salvatore Bonaccorso: Adjust for context changes to backport to
4.9.168]
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

Bluetooth: hidp: fix buffer overflow

2019-06-20T17:11:27+00:00

commit a1616a5ac99ede5d605047a9012481ce7ff18b16 upstream.

Struct ca is copied from userspace. It is not checked whether the "name"
field is NULL terminated, which allows local users to obtain potentially
sensitive information from kernel stack memory, via a HIDPCONNADD command.

This vulnerability is similar to CVE-2011-1079.

Signed-off-by: Young Xiao 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Ben Hutchings

ext4: zero out the unused memory region in the extent tree block

2019-06-20T17:11:27+00:00

commit 592acbf16821288ecdc4192c47e3774a4c48bb64 upstream.

This commit zeroes out the unused memory region in the buffer_head
corresponding to the extent metablock after writing the extent header
and the corresponding extent node entries.

This is done to prevent random uninitialized data from getting into
the filesystem when the extent block is synced.

This fixes CVE-2019-11833.

Signed-off-by: Sriram Rajagopalan 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Ben Hutchings

scsi: megaraid_sas: return error when create DMA pool failed

2019-06-20T17:11:27+00:00

commit bcf3b67d16a4c8ffae0aa79de5853435e683945c upstream.

when create DMA pool for cmd frames failed, we should return -ENOMEM,
instead of 0.
In some case in:

    megasas_init_adapter_fusion()

    -->megasas_alloc_cmds()
       -->megasas_create_frame_pool
          create DMA pool failed,
        --> megasas_free_cmds() [1]

    -->megasas_alloc_cmds_fusion()
       failed, then goto fail_alloc_cmds.
    -->megasas_free_cmds() [2]

we will call megasas_free_cmds twice, [1] will kfree cmd_list,
[2] will use cmd_list.it will cause a problem:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = ffffffc000f70000
[00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003,
*pmd=0000001fbf894003, *pte=006000006d000707
Internal error: Oops: 96000005 [#1] SMP
 Modules linked in:
 CPU: 18 PID: 1 Comm: swapper/0 Not tainted
 task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000
 PC is at megasas_free_cmds+0x30/0x70
 LR is at megasas_free_cmds+0x24/0x70
 ...
 Call trace:
 [] megasas_free_cmds+0x30/0x70
 [] megasas_init_adapter_fusion+0x2f4/0x4d8
 [] megasas_init_fw+0x2dc/0x760
 [] megasas_probe_one+0x3c0/0xcd8
 [] local_pci_probe+0x4c/0xb4
 [] pci_device_probe+0x11c/0x14c
 [] driver_probe_device+0x1ec/0x430
 [] __driver_attach+0xa8/0xb0
 [] bus_for_each_dev+0x74/0xc8
  [] driver_attach+0x28/0x34
 [] bus_add_driver+0x16c/0x248
 [] driver_register+0x6c/0x138
 [] __pci_register_driver+0x5c/0x6c
 [] megasas_init+0xc0/0x1a8
 [] do_one_initcall+0xe8/0x1ec
 [] kernel_init_freeable+0x1c8/0x284
 [] kernel_init+0x1c/0xe4

Signed-off-by: Jason Yan 
Acked-by: Sumit Saxena 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Ben Hutchings

drivers/virt/fsl_hypervisor.c: prevent integer overflow in ioctl

2019-06-20T17:11:26+00:00

commit 6a024330650e24556b8a18cc654ad00cfecf6c6c upstream.

The "param.count" value is a u64 thatcomes from the user.  The code
later in the function assumes that param.count is at least one and if
it's not then it leads to an Oops when we dereference the ZERO_SIZE_PTR.

Also the addition can have an integer overflow which would lead us to
allocate a smaller "pages" array than required.  I can't immediately
tell what the possible run times implications are, but it's safest to
prevent the overflow.

Link: http://lkml.kernel.org/r/20181218082129.GE32567@kadam
Fixes: 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")
Signed-off-by: Dan Carpenter 
Reviewed-by: Andrew Morton 
Cc: Timur Tabi 
Cc: Mihai Caraman 
Cc: Kumar Gala 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

mm/mincore.c: make mincore() more conservative

2019-06-20T17:11:26+00:00

commit 134fca9063ad4851de767d1768180e5dede9a881 upstream.

The semantics of what mincore() considers to be resident is not
completely clear, but Linux has always (since 2.3.52, which is when
mincore() was initially done) treated it as "page is available in page
cache".

That's potentially a problem, as that [in]directly exposes
meta-information about pagecache / memory mapping state even about
memory not strictly belonging to the process executing the syscall,
opening possibilities for sidechannel attacks.

Change the semantics of mincore() so that it only reveals pagecache
information for non-anonymous mappings that belog to files that the
calling process could (if it tried to) successfully open for writing;
otherwise we'd be including shared non-exclusive mappings, which

 - is the sidechannel

 - is not the usecase for mincore(), as that's primarily used for data,
   not (shared) text

[jkosina@suse.cz: v2]
  Link: http://lkml.kernel.org/r/20190312141708.6652-2-vbabka@suse.cz
[mhocko@suse.com: restructure can_do_mincore() conditions]
Link: http://lkml.kernel.org/r/nycvar.YFH.7.76.1903062342020.19912@cbobk.fhfr.pm
Signed-off-by: Jiri Kosina 
Signed-off-by: Vlastimil Babka 
Acked-by: Josh Snyder 
Acked-by: Michal Hocko 
Originally-by: Linus Torvalds 
Originally-by: Dominique Martinet 
Cc: Andy Lutomirski 
Cc: Dave Chinner 
Cc: Kevin Easton 
Cc: Matthew Wilcox 
Cc: Cyril Hrubis 
Cc: Tejun Heo 
Cc: Kirill A. Shutemov 
Cc: Daniel Gruss 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings