linux-stable.git, branch v6.1.73

Linux 6.1.73

2024-01-15T17:54:51+00:00

Link: https://lore.kernel.org/r/20240113094204.017594027@linuxfoundation.org
Tested-by: Salvatore Bonaccorso 
Tested-by: SeongJae Park 
Tested-by: Pavel Machek (CIP) 
Tested-by: Ron Economos 
Tested-by: Slade Watkins 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Jon Hunter 
Tested-by: kernelci.org bot 
Tested-by: Conor Dooley 
Signed-off-by: Greg Kroah-Hartman

cifs: fix flushing folio regression for 6.1 backport

2024-01-15T17:54:51+00:00

filemap_get_folio works differenty in 6.1 vs. later kernels
(returning NULL in 6.1 instead of an error).  Add
this minor correction which addresses the regression in the patch:
  cifs: Fix flushing, invalidation and file size with copy_file_range()

Link: https://lore.kernel.org/all/a76b370f93cb928c049b94e1fde0d2da506dfcb2.camel@amazon.com/
Reported-by: "Jitindar Singh, Suraj" 
Suggested-by: David Howells 
Reported-by: Salvatore Bonaccorso 
Signed-off-by: Steve French 
Tested-by: Salvatore Bonaccorso 
Signed-off-by: Greg Kroah-Hartman

ipv6: remove max_size check inline with ipv4

2024-01-15T17:54:51+00:00

commit af6d10345ca76670c1b7c37799f0d5576ccef277 upstream.

In ip6_dst_gc() replace:

  if (entries > gc_thresh)

With:

  if (entries > ops->gc_thresh)

Sending Ipv6 packets in a loop via a raw socket triggers an issue where a
route is cloned by ip6_rt_cache_alloc() for each packet sent. This quickly
consumes the Ipv6 max_size threshold which defaults to 4096 resulting in
these warnings:

[1]   99.187805] dst_alloc: 7728 callbacks suppressed
[2] Route cache is full: consider increasing sysctl net.ipv6.route.max_size.
.
.
[300] Route cache is full: consider increasing sysctl net.ipv6.route.max_size.

When this happens the packet is dropped and sendto() gets a network is
unreachable error:

remaining pkt 200557 errno 101
remaining pkt 196462 errno 101
.
.
remaining pkt 126821 errno 101

Implement David Aherns suggestion to remove max_size check seeing that Ipv6
has a GC to manage memory usage. Ipv4 already does not check max_size.

Here are some memory comparisons for Ipv4 vs Ipv6 with the patch:

Test by running 5 instances of a program that sends UDP packets to a raw
socket 5000000 times. Compare Ipv4 and Ipv6 performance with a similar
program.

Ipv4:

Before test:

MemFree:        29427108 kB
Slab:             237612 kB

ip6_dst_cache       1912   2528    256   32    2 : tunables    0    0    0
xfrm_dst_cache         0      0    320   25    2 : tunables    0    0    0
ip_dst_cache        2881   3990    192   42    2 : tunables    0    0    0

During test:

MemFree:        29417608 kB
Slab:             247712 kB

ip6_dst_cache       1912   2528    256   32    2 : tunables    0    0    0
xfrm_dst_cache         0      0    320   25    2 : tunables    0    0    0
ip_dst_cache       44394  44394    192   42    2 : tunables    0    0    0

After test:

MemFree:        29422308 kB
Slab:             238104 kB

ip6_dst_cache       1912   2528    256   32    2 : tunables    0    0    0
xfrm_dst_cache         0      0    320   25    2 : tunables    0    0    0
ip_dst_cache        3048   4116    192   42    2 : tunables    0    0    0

Ipv6 with patch:

Errno 101 errors are not observed anymore with the patch.

Before test:

MemFree:        29422308 kB
Slab:             238104 kB

ip6_dst_cache       1912   2528    256   32    2 : tunables    0    0    0
xfrm_dst_cache         0      0    320   25    2 : tunables    0    0    0
ip_dst_cache        3048   4116    192   42    2 : tunables    0    0    0

During Test:

MemFree:        29431516 kB
Slab:             240940 kB

ip6_dst_cache      11980  12064    256   32    2 : tunables    0    0    0
xfrm_dst_cache         0      0    320   25    2 : tunables    0    0    0
ip_dst_cache        3048   4116    192   42    2 : tunables    0    0    0

After Test:

MemFree:        29441816 kB
Slab:             238132 kB

ip6_dst_cache       1902   2432    256   32    2 : tunables    0    0    0
xfrm_dst_cache         0      0    320   25    2 : tunables    0    0    0
ip_dst_cache        3048   4116    192   42    2 : tunables    0    0    0

Tested-by: Andrea Mayer 
Signed-off-by: Jon Maxwell 
Reviewed-by: David Ahern 
Link: https://lore.kernel.org/r/20230112012532.311021-1-jmaxwell37@gmail.com
Signed-off-by: Jakub Kicinski 
Cc: "Jitindar Singh, Suraj" 
Signed-off-by: Greg Kroah-Hartman

Revert "nfsd: separate nfsd_last_thread() from nfsd_put()"

2024-01-15T17:54:50+00:00

This reverts commit 03d68ffc48b94cc1e15bbf3b4f16f1e1e4fa286a which is
commit 9f28a971ee9fdf1bf8ce8c88b103f483be610277 upstream.

It is reported to cause issues, so revert it.

Reported-by: email200202 
Link: https://lore.kernel.org/r/e341cb408b5663d8c91b8fa57b41bb984be43448.camel@kernel.org
Cc: NeilBrown 
Cc: Jeff Layton 
Cc: Chuck Lever 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Revert "nfsd: call nfsd_last_thread() before final nfsd_put()"

2024-01-15T17:54:50+00:00

This reverts commit bb4f791cb2de1140d0fbcedfe9e791ff364021d7 which is
commit 2a501f55cd641eb4d3c16a2eab0d678693fac663 upstream.

It is reported to cause issues, so revert it.

Reported-by: email200202 
Link: https://lore.kernel.org/r/e341cb408b5663d8c91b8fa57b41bb984be43448.camel@kernel.org
Cc: NeilBrown 
Cc: Jeff Layton 
Cc: Chuck Lever 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Linux 6.1.72

2024-01-10T16:10:37+00:00

Link: https://lore.kernel.org/r/20240108153511.214254205@linuxfoundation.org
Tested-by: SeongJae Park 
Tested-by: Florian Fainelli 
Tested-by: Allen Pais 
Tested-by: Shuah Khan 
Tested-by: Salvatore Bonaccorso 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Conor Dooley 
Tested-by: Jon Hunter 
Tested-by: Sven Joachim 
Tested-by: Ron Economos 
Tested-by: Kelsey Steele 
Tested-by: Pavel Machek (CIP) 
Tested-by: Yann Sionneau 
Tested-by: kernelci.org bot 
Signed-off-by: Greg Kroah-Hartman

Revert "interconnect: qcom: sm8250: Enable sync_state"

2024-01-10T16:10:37+00:00

This reverts commit 3637f6bdfe2ccd53c493836b6e43c9a73e4513b3 which is
commit bfc7db1cb94ad664546d70212699f8cc6c539e8c upstream.

This resulted in boot regression on RB5 (sm8250), causing the device
to hard crash into USB crash dump mode everytime.

Signed-off-by: Amit Pundir 
Link: https://lkft.validation.linaro.org/scheduler/job/7151629#L4239
Signed-off-by: Greg Kroah-Hartman

smb3: Replace smb2pdu 1-element arrays with flex-arrays

2024-01-10T16:10:37+00:00

commit eb3e28c1e89b4984308777231887e41aa8a0151f upstream.

The kernel is globally removing the ambiguous 0-length and 1-element
arrays in favor of flexible arrays, so that we can gain both compile-time
and run-time array bounds checking[1].

Replace the trailing 1-element array with a flexible array in the
following structures:

	struct smb2_err_rsp
	struct smb2_tree_connect_req
	struct smb2_negotiate_rsp
	struct smb2_sess_setup_req
	struct smb2_sess_setup_rsp
	struct smb2_read_req
	struct smb2_read_rsp
	struct smb2_write_req
	struct smb2_write_rsp
	struct smb2_query_directory_req
	struct smb2_query_directory_rsp
	struct smb2_set_info_req
	struct smb2_change_notify_rsp
	struct smb2_create_rsp
	struct smb2_query_info_req
	struct smb2_query_info_rsp

Replace the trailing 1-element array with a flexible array, but leave
the existing structure padding:

	struct smb2_file_all_info
	struct smb2_lock_req

Adjust all related size calculations to match the changes to sizeof().

No machine code output or .data section differences are produced after
these changes.

[1] For lots of details, see both:
    https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
    https://people.kernel.org/kees/bounded-flexible-arrays-in-c

Cc: Steve French 
Cc: Paulo Alcantara 
Cc: Ronnie Sahlberg 
Cc: Shyam Prasad N 
Cc: Tom Talpey 
Cc: Namjae Jeon 
Cc: Sergey Senozhatsky 
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Reviewed-by: Namjae Jeon 
Signed-off-by: Kees Cook 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

media: qcom: camss: Comment CSID dt_id field

2024-01-10T16:10:37+00:00

commit f910d3ba78a2677c23508f225eb047d89eb4b2b6 upstream.

Digging into the documentation we find that the DT_ID bitfield is used to
map the six bit DT to a two bit ID code. This value is concatenated to the
VC bitfield to create a CID value. DT_ID is the two least significant bits
of CID and VC the most significant bits.

Originally we set dt_id = vc * 4 in and then subsequently set dt_id = vc.

commit 3c4ed72a16bc ("media: camss: sm8250: Virtual channels for CSID")
silently fixed the multiplication by four which would give a better
value for the generated CID without mentioning what was being done or why.

Next up I haplessly changed the value back to "dt_id = vc * 4" since there
didn't appear to be any logic behind it.

Hans asked what the change was for and I honestly couldn't remember the
provenance of it, so I dug in.

Link: https://lore.kernel.org/linux-arm-msm/edd4bf9b-0e1b-883c-1a4d-50f4102c3924@xs4all.nl/

Add a comment so the next hapless programmer doesn't make this same
mistake.

Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Hans Verkuil 
Signed-off-by: Greg Kroah-Hartman

bpf: syzkaller found null ptr deref in unix_bpf proto add

2024-01-10T16:10:36+00:00

commit 8d6650646ce49e9a5b8c5c23eb94f74b1749f70f upstream.

I added logic to track the sock pair for stream_unix sockets so that we
ensure lifetime of the sock matches the time a sockmap could reference
the sock (see fixes tag). I forgot though that we allow af_unix unconnected
sockets into a sock{map|hash} map.

This is problematic because previous fixed expected sk_pair() to exist
and did not NULL check it. Because unconnected sockets have a NULL
sk_pair this resulted in the NULL ptr dereference found by syzkaller.

BUG: KASAN: null-ptr-deref in unix_stream_bpf_update_proto+0x72/0x430 net/unix/unix_bpf.c:171
Write of size 4 at addr 0000000000000080 by task syz-executor360/5073
Call Trace:

...
sock_hold include/net/sock.h:777 [inline]
unix_stream_bpf_update_proto+0x72/0x430 net/unix/unix_bpf.c:171
sock_map_init_proto net/core/sock_map.c:190 [inline]
sock_map_link+0xb87/0x1100 net/core/sock_map.c:294
sock_map_update_common+0xf6/0x870 net/core/sock_map.c:483
sock_map_update_elem_sys+0x5b6/0x640 net/core/sock_map.c:577
bpf_map_update_value+0x3af/0x820 kernel/bpf/syscall.c:167

We considered just checking for the null ptr and skipping taking a ref
on the NULL peer sock. But, if the socket is then connected() after
being added to the sockmap we can cause the original issue again. So
instead this patch blocks adding af_unix sockets that are not in the
ESTABLISHED state.

Reported-by: Eric Dumazet
Reported-by: syzbot+e8030702aefd3444fb9e@syzkaller.appspotmail.com
Fixes: 8866730aed51 ("bpf, sockmap: af_unix stream sockets need to hold ref for pair sock")
Acked-by: Jakub Sitnicki
Signed-off-by: John Fastabend
Link: https://lore.kernel.org/r/20231201180139.328529-2-john.fastabend@gmail.com
Signed-off-by: Martin KaFai Lau
Signed-off-by: Greg Kroah-Hartman