linux-stable.git, branch v4.9.320

Linux 4.9.320

2022-06-25T09:45:20+00:00

Link: https://lore.kernel.org/r/20220623164344.053938039@linuxfoundation.org
Tested-by: Florian Fainelli 
Tested-by: Pavel Machek (CIP) 
Tested-by: Shuah Khan 
Tested-by: Jon Hunter 
Tested-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

tcp: drop the hash_32() part from the index calculation

2022-06-25T09:45:20+00:00

commit e8161345ddbb66e449abde10d2fdce93f867eba9 upstream.

In commit 190cc82489f4 ("tcp: change source port randomizarion at
connect() time"), the table_perturb[] array was introduced and an
index was taken from the port_offset via hash_32(). But it turns
out that hash_32() performs a multiplication while the input here
comes from the output of SipHash in secure_seq, that is well
distributed enough to avoid the need for yet another hash.

Suggested-by: Amit Klein 
Reviewed-by: Eric Dumazet 
Signed-off-by: Willy Tarreau 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tcp: increase source port perturb table to 2^16

2022-06-25T09:45:20+00:00

commit 4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5 upstream.

Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately
identify a client by forcing it to emit only 40 times more connections
than there are entries in the table_perturb[] table. The previous two
improvements consisting in resalting the secret every 10s and adding
randomness to each port selection only slightly improved the situation,
and the current value of 2^8 was too small as it's not very difficult
to make a client emit 10k connections in less than 10 seconds.

Thus we're increasing the perturb table from 2^8 to 2^16 so that the
same precision now requires 2.6M connections, which is more difficult in
this time frame and harder to hide as a background activity. The impact
is that the table now uses 256 kB instead of 1 kB, which could mostly
affect devices making frequent outgoing connections. However such
components usually target a small set of destinations (load balancers,
database clients, perf assessment tools), and in practice only a few
entries will be visited, like before.

A live test at 1 million connections per second showed no performance
difference from the previous value.

Reported-by: Moshe Kol 
Reported-by: Yossi Gilad 
Reported-by: Amit Klein 
Reviewed-by: Eric Dumazet 
Signed-off-by: Willy Tarreau 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tcp: dynamically allocate the perturb table used by source ports

2022-06-25T09:45:20+00:00

commit e9261476184be1abd486c9434164b2acbe0ed6c2 upstream.

We'll need to further increase the size of this table and it's likely
that at some point its size will not be suitable anymore for a static
table. Let's allocate it on boot from inet_hashinfo2_init(), which is
called from tcp_init().

Cc: Moshe Kol 
Cc: Yossi Gilad 
Cc: Amit Klein 
Reviewed-by: Eric Dumazet 
Signed-off-by: Willy Tarreau 
Signed-off-by: Jakub Kicinski 
[bwh: Backported to 4.9:
 - There is no inet_hashinfo2_init(), so allocate the table in
   inet_hashinfo_init() when called by TCP
 - Adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tcp: add small random increments to the source port

2022-06-25T09:45:19+00:00

commit ca7af0402550f9a0b3316d5f1c30904e42ed257d upstream.

Here we're randomly adding between 0 and 7 random increments to the
selected source port in order to add some noise in the source port
selection that will make the next port less predictable.

With the default port range of 32768-60999 this means a worst case
reuse scenario of 14116/8=1764 connections between two consecutive
uses of the same port, with an average of 14116/4.5=3137. This code
was stressed at more than 800000 connections per second to a fixed
target with all connections closed by the client using RSTs (worst
condition) and only 2 connections failed among 13 billion, despite
the hash being reseeded every 10 seconds, indicating a perfectly
safe situation.

Cc: Moshe Kol 
Cc: Yossi Gilad 
Cc: Amit Klein 
Reviewed-by: Eric Dumazet 
Signed-off-by: Willy Tarreau 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tcp: use different parts of the port_offset for index and offset

2022-06-25T09:45:19+00:00

commit 9e9b70ae923baf2b5e8a0ea4fd0c8451801ac526 upstream.

Amit Klein suggests that we use different parts of port_offset for the
table's index and the port offset so that there is no direct relation
between them.

Cc: Jason A. Donenfeld 
Cc: Moshe Kol 
Cc: Yossi Gilad 
Cc: Amit Klein 
Reviewed-by: Eric Dumazet 
Signed-off-by: Willy Tarreau 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

secure_seq: use the 64 bits of the siphash for port offset calculation

2022-06-25T09:45:19+00:00

commit b2d057560b8107c633b39aabe517ff9d93f285e3 upstream.

SipHash replaced MD5 in secure_ipv{4,6}_port_ephemeral() via commit
7cd23e5300c1 ("secure_seq: use SipHash in place of MD5"), but the output
remained truncated to 32-bit only. In order to exploit more bits from the
hash, let's make the functions return the full 64-bit of siphash_3u32().
We also make sure the port offset calculation in __inet_hash_connect()
remains done on 32-bit to avoid the need for div_u64_rem() and an extra
cost on 32-bit systems.

Cc: Jason A. Donenfeld 
Cc: Moshe Kol 
Cc: Yossi Gilad 
Cc: Amit Klein 
Reviewed-by: Eric Dumazet 
Signed-off-by: Willy Tarreau 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tcp: add some entropy in __inet_hash_connect()

2022-06-25T09:45:19+00:00

commit c579bd1b4021c42ae247108f1e6f73dd3f08600c upstream.

Even when implementing RFC 6056 3.3.4 (Algorithm 4: Double-Hash
Port Selection Algorithm), a patient attacker could still be able
to collect enough state from an otherwise idle host.

Idea of this patch is to inject some noise, in the
cases __inet_hash_connect() found a candidate in the first
attempt.

This noise should not significantly reduce the collision
avoidance, and should be zero if connection table
is already well used.

Note that this is not implementing RFC 6056 3.3.5
because we think Algorithm 5 could hurt typical
workloads.

Signed-off-by: Eric Dumazet 
Cc: David Dworken 
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

tcp: change source port randomizarion at connect() time

2022-06-25T09:45:19+00:00

commit 190cc82489f46f9d88e73c81a47e14f80a791e1a upstream.

RFC 6056 (Recommendations for Transport-Protocol Port Randomization)
provides good summary of why source selection needs extra care.

David Dworken reminded us that linux implements Algorithm 3
as described in RFC 6056 3.3.3

Quoting David :
   In the context of the web, this creates an interesting info leak where
   websites can count how many TCP connections a user's computer is
   establishing over time. For example, this allows a website to count
   exactly how many subresources a third party website loaded.
   This also allows:
   - Distinguishing between different users behind a VPN based on
       distinct source port ranges.
   - Tracking users over time across multiple networks.
   - Covert communication channels between different browsers/browser
       profiles running on the same computer
   - Tracking what applications are running on a computer based on
       the pattern of how fast source ports are getting incremented.

Section 3.3.4 describes an enhancement, that reduces
attackers ability to use the basic information currently
stored into the shared 'u32 hint'.

This change also decreases collision rate when
multiple applications need to connect() to
different destinations.

Signed-off-by: Eric Dumazet 
Reported-by: David Dworken 
Cc: Willem de Bruijn 
Signed-off-by: David S. Miller 
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

fuse: fix pipe buffer lifetime for direct_io

2022-06-25T09:45:19+00:00

commit 0c4bcfdecb1ac0967619ee7ff44871d93c08c909 upstream.

In FOPEN_DIRECT_IO mode, fuse_file_write_iter() calls
fuse_direct_write_iter(), which normally calls fuse_direct_io(), which then
imports the write buffer with fuse_get_user_pages(), which uses
iov_iter_get_pages() to grab references to userspace pages instead of
actually copying memory.

On the filesystem device side, these pages can then either be read to
userspace (via fuse_dev_read()), or splice()d over into a pipe using
fuse_dev_splice_read() as pipe buffers with &nosteal_pipe_buf_ops.

This is wrong because after fuse_dev_do_read() unlocks the FUSE request,
the userspace filesystem can mark the request as completed, causing write()
to return. At that point, the userspace filesystem should no longer have
access to the pipe buffer.

Fix by copying pages coming from the user address space to new pipe
buffers.

Reported-by: Jann Horn 
Fixes: c3021629a0d8 ("fuse: support splice() reading from fuse device")
Cc: 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Zach O'Keefe 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman