user/sven/linux.git, branch v6.5.9

Linux 6.5.9

2023-10-25T10:16:30Z

Link: https://lore.kernel.org/r/20231023104833.832874523@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Ricardo B. Marliere Tested-by: Ronald Warsow Tested-by: Justin M. Forbes Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Miguel Ojeda # Rust Signed-off-by: Greg Kroah-Hartman

selftests: mptcp: join: correctly check for no RST

2023-10-25T10:16:30Z

commit b134a5805455d1886662a6516c965cdb9df9fbcc upstream. The commit mentioned below was more tolerant with the number of RST seen during a test because in some uncontrollable situations, multiple RST can be generated. But it was not taking into account the case where no RST are expected: this validation was then no longer reporting issues for the 0 RST case because it is not possible to have less than 0 RST in the counter. This patch fixes the issue by adding a specific condition. Fixes: 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-1-17ecb002e41d@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts Signed-off-by: Greg Kroah-Hartman

mptcp: avoid sending RST when closing the initial subflow

2023-10-25T10:16:30Z

commit 14c56686a64c65ba716ff48f1f4b19c85f4cb2a9 upstream. When closing the first subflow, the MPTCP protocol unconditionally calls tcp_disconnect(), which in turn generates a reset if the subflow is established. That is unexpected and different from what MPTCP does with MPJ subflows, where resets are generated only on FASTCLOSE and other edge scenarios. We can't reuse for the first subflow the same code in place for MPJ subflows, as MPTCP clean them up completely via a tcp_close() call, while must keep the first subflow socket alive for later re-usage, due to implementation constraints. This patch adds a new helper __mptcp_subflow_disconnect() that encapsulates, a logic similar to tcp_close, issuing a reset only when the MPTCP_CF_FASTCLOSE flag is set, and performing a clean shutdown otherwise. Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures") Cc: stable@vger.kernel.org Reviewed-by: Matthieu Baerts Co-developed-by: Paolo Abeni Signed-off-by: Paolo Abeni Signed-off-by: Geliang Tang Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-4-17ecb002e41d@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Matthieu Baerts Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_sock: Correctly bounds check and pad HCI_MON_NEW_INDEX name

2023-10-25T10:16:30Z

commit cb3871b1cd135a6662b732fbc6b3db4afcdb4a64 upstream. The code pattern of memcpy(dst, src, strlen(src)) is almost always wrong. In this case it is wrong because it leaves memory uninitialized if it is less than sizeof(ni->name), and overflows ni->name when longer. Normally strtomem_pad() could be used here, but since ni->name is a trailing array in struct hci_mon_new_index, compilers that don't support -fstrict-flex-arrays=3 can't tell how large this array is via __builtin_object_size(). Instead, open-code the helper and use sizeof() since it will work correctly. Additionally mark ni->name as __nonstring since it appears to not be a %NUL terminated C string. Cc: Luiz Augusto von Dentz Cc: Edward AD Cc: Marcel Holtmann Cc: Johan Hedberg Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Fixes: 18f547f3fc07 ("Bluetooth: hci_sock: fix slab oob read in create_monitor_event") Link: https://lore.kernel.org/lkml/202310110908.F2639D3276@keescook/ Signed-off-by: Kees Cook Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman

kbuild: remove old Rust docs output path

2023-10-25T10:16:30Z

commit 1db773da58df20772dcc037a47163ce472d39c4d upstream. The Rust code documentation output path moved from `rust/doc` to `Documentation/output/rust/rustdoc`. The `make cleandocs` target takes care of cleaning it now since it is integrated with the rest of the documentation. Thus remove the old reference. Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it") Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20231018160145.1017340-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

docs: rust: update Rust docs output path

2023-10-25T10:16:30Z

commit bd9e54a42ce26026d67963c21b3fdfe8c7e68430 upstream. The Rust code documentation output path moved from `rust/doc` to `Documentation/output/rust/rustdoc`, thus update the old reference. Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it") Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20231018160145.1017340-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

net: rfkill: reduce data->mtx scope in rfkill_fop_open

2023-10-25T10:16:30Z

commit f2ac54ebf85615a6d78f5eb213a8bbeeb17ebe5d upstream. In syzbot runs, lockdep reports that there's a (potential) deadlock here of data->mtx being locked recursively. This isn't really a deadlock since they are different instances, but lockdep cannot know, and teaching it would be far more difficult than other fixes. At the same time we don't even really _need_ the mutex to be locked in rfkill_fop_open(), since we're modifying only a completely fresh instance of 'data' (struct rfkill_data) that's not yet added to the global list. However, to avoid any reordering etc. within the globally locked section, and to make the code look more symmetric, we should still lock the data->events list manipulation, but also need to lock _only_ that. So do that. Reported-by: syzbot+509238e523e032442b80@syzkaller.appspotmail.com Fixes: 2c3dfba4cf84 ("rfkill: sync before userspace visibility/changes") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

Bluetooth: hci_sock: fix slab oob read in create_monitor_event

2023-10-25T10:16:30Z

commit 18f547f3fc074500ab5d419cf482240324e73a7e upstream. When accessing hdev->name, the actual string length should prevail Reported-by: syzbot+c90849c50ed209d77689@syzkaller.appspotmail.com Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings") Signed-off-by: Edward AD Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman

net: move altnames together with the netdevice

2023-10-25T10:16:30Z

commit 8e15aee621618a3ee3abecaf1fd8c1428098b7ef upstream. The altname nodes are currently not moved to the new netns when netdevice itself moves: [ ~]# ip netns add test [ ~]# ip -netns test link add name eth0 type dummy [ ~]# ip -netns test link property add dev eth0 altname some-name [ ~]# ip -netns test link show dev some-name 2: eth0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 1e:67:ed:19:3d:24 brd ff:ff:ff:ff:ff:ff altname some-name [ ~]# ip -netns test link set dev eth0 netns 1 [ ~]# ip link ... 3: eth0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:40:88:62:ec:b8 brd ff:ff:ff:ff:ff:ff altname some-name [ ~]# ip li show dev some-name Device "some-name" does not exist. Remove them from the hash table when device is unlisted and add back when listed again. Fixes: 36fbf1e52bd3 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames") Reviewed-by: Jiri Pirko Signed-off-by: Jakub Kicinski Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman

efi/unaccepted: Fix soft lockups caused by parallel memory acceptance

2023-10-25T10:16:30Z

[ Upstream commit 50e782a86c980d4f8292ef82ed8139282ca07a98 ] Michael reported soft lockups on a system that has unaccepted memory. This occurs when a user attempts to allocate and accept memory on multiple CPUs simultaneously. The root cause of the issue is that memory acceptance is serialized with a spinlock, allowing only one CPU to accept memory at a time. The other CPUs spin and wait for their turn, leading to starvation and soft lockup reports. To address this, the code has been modified to release the spinlock while accepting memory. This allows for parallel memory acceptance on multiple CPUs. A newly introduced "accepting_list" keeps track of which memory is currently being accepted. This is necessary to prevent parallel acceptance of the same memory block. If a collision occurs, the lock is released and the process is retried. Such collisions should rarely occur. The main path for memory acceptance is the page allocator, which accepts memory in MAX_ORDER chunks. As long as MAX_ORDER is equal to or larger than the unit_size, collisions will never occur because the caller fully owns the memory block being accepted. Aside from the page allocator, only memblock and deferered_free_range() accept memory, but this only happens during boot. The code has been tested with unit_size == 128MiB to trigger collisions and validate the retry codepath. Fixes: 2053bc57f367 ("efi: Add unaccepted memory support") Signed-off-by: Kirill A. Shutemov Reported-by: Michael Roth Reviewed-by: Vlastimil Babka Tested-by: Michael Roth [ardb: drop unnecessary cpu_relax() call] Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin