commit 23db944f754e99abf814a79a2273b0191d35e4ff Author: Greg Kroah-Hartman Date: Sat Jun 25 12:44:36 2022 +0200 Linux 5.4.201 Link: https://lore.kernel.org/r/20220623164321.195163701@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Hulk Robot Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3994d2ee55e28a08a4af4ef2ad5ced8d194d8b78 Author: Greg Kroah-Hartman Date: Thu Jun 23 18:19:35 2022 +0200 Revert "hwmon: Make chip parameter for with_info API mandatory" This reverts commit 1ec0bc72f5dab3ab367ae5230cf6f212d805a225 which is commit ddaefa209c4ac791c1262e97c9b2d0440c8ef1d5 upstream. It should not have been applied to the stable trees. Link: https://lore.kernel.org/r/20220622154454.GA1864037@roeck-us.net Reported-by: Julian Haller Reported-by: Guenter Roeck Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7b9c3bfbad2510478ac29221d2c40a09184ce6a1 Author: Will Deacon Date: Fri Jun 10 16:12:27 2022 +0100 arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer commit c50f11c6196f45c92ca48b16a5071615d4ae0572 upstream. Invalidating the buffer memory in arch_sync_dma_for_device() for FROM_DEVICE transfers When using the streaming DMA API to map a buffer prior to inbound non-coherent DMA (i.e. DMA_FROM_DEVICE), we invalidate any dirty CPU cachelines so that they will not be written back during the transfer and corrupt the buffer contents written by the DMA. This, however, poses two potential problems: (1) If the DMA transfer does not write to every byte in the buffer, then the unwritten bytes will contain stale data once the transfer has completed. (2) If the buffer has a virtual alias in userspace, then stale data may be visible via this alias during the period between performing the cache invalidation and the DMA writes landing in memory. Address both of these issues by cleaning (aka writing-back) the dirty lines in arch_sync_dma_for_device(DMA_FROM_DEVICE) instead of discarding them using invalidation. Cc: Ard Biesheuvel Cc: Christoph Hellwig Cc: Robin Murphy Cc: Russell King Cc: Link: https://lore.kernel.org/r/20220606152150.GA31568@willie-the-truck Signed-off-by: Will Deacon Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220610151228.4562-2-will@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 2e1591c27b954f1f60ef8ce5d214e8fee1b4d304 Author: Willy Tarreau Date: Mon May 2 10:46:14 2022 +0200 tcp: drop the hash_32() part from the index calculation 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 Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit c26e1addf15763ae404f4bbf131719a724e768ab Author: Willy Tarreau Date: Mon May 2 10:46:13 2022 +0200 tcp: increase source port perturb table to 2^16 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 Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 77d29f3b18c466a6b88bdfceccec3085961a7d0e Author: Willy Tarreau Date: Mon May 2 10:46:12 2022 +0200 tcp: dynamically allocate the perturb table used by source ports 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 Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 7c0a777b7dbdcd39eb45996afe6df7770f7926ac Author: Willy Tarreau Date: Mon May 2 10:46:11 2022 +0200 tcp: add small random increments to the source port 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 Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 53c5de3092ade55f82ed4f5373d8a8ca115df818 Author: Willy Tarreau Date: Mon May 2 10:46:09 2022 +0200 tcp: use different parts of the port_offset for index and offset 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 Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 95921a3bab76872e8b5c6ba07903cbdbcc352cc6 Author: Eric Dumazet Date: Tue Feb 9 11:20:28 2021 -0800 tcp: add some entropy in __inet_hash_connect() 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 Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit bdcbf2602febf5cf19065d4fa091873b1f482779 Author: Marian Postevca Date: Fri Jun 3 18:34:59 2022 +0300 usb: gadget: u_ether: fix regression in setting fixed MAC address commit b337af3a4d6147000b7ca6b3438bf5c820849b37 upstream. In systemd systems setting a fixed MAC address through the "dev_addr" module argument fails systematically. When checking the MAC address after the interface is created it always has the same but different MAC address to the one supplied as argument. This is partially caused by systemd which by default will set an internally generated permanent MAC address for interfaces that are marked as having a randomly generated address. Commit 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase") didn't take into account the fact that the interface must be marked as having a set MAC address when it's set as module argument. Fixed by marking the interface with NET_ADDR_SET when the "dev_addr" module argument is supplied. Fixes: 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase") Cc: stable@vger.kernel.org Signed-off-by: Marian Postevca Link: https://lore.kernel.org/r/20220603153459.32722-1-posteuca@mutex.one Signed-off-by: Greg Kroah-Hartman commit 2577d67a9a8aa5ee5e3963379f63e427a916de08 Author: Mike Snitzer Date: Tue Jun 21 12:35:04 2022 -0400 dm: remove special-casing of bio-based immutable singleton target on NVMe Commit 9c37de297f6590937f95a28bec1b7ac68a38618f upstream. There is no benefit to DM special-casing NVMe. Remove all code used to establish DM_TYPE_NVME_BIO_BASED. Also, remove 3 'struct mapped_device *md' variables in __map_bio() which masked the same variable that is available within __map_bio()'s scope. Tested-by: Guenter Roeck Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 4143503b486afa8cac2a2c0550fd240593a08834 Author: Christian Borntraeger Date: Mon May 30 11:27:06 2022 +0200 s390/mm: use non-quiescing sske for KVM switch to keyed guest commit 3ae11dbcfac906a8c3a480e98660a823130dc16a upstream. The switch to a keyed guest does not require a classic sske as the other guest CPUs are not accessing the key before the switch is complete. By using the NQ SSKE things are faster especially with multiple guests. Signed-off-by: Christian Borntraeger Suggested-by: Janis Schoetterl-Glausch Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20220530092706.11637-3-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman