--- /dev/null
+From aeb7079be37926f18f48e8c5e92588daa20316ee Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 11 Dec 2023 21:43:52 +0000
+Subject: afs: Fix refcount underflow from error handling race
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit 52bf9f6c09fca8c74388cd41cc24e5d1bff812a9 ]
+
+If an AFS cell that has an unreachable (eg. ENETUNREACH) server listed (VL
+server or fileserver), an asynchronous probe to one of its addresses may
+fail immediately because sendmsg() returns an error. When this happens, a
+refcount underflow can happen if certain events hit a very small window.
+
+The way this occurs is:
+
+ (1) There are two levels of "call" object, the afs_call and the
+ rxrpc_call. Each of them can be transitioned to a "completed" state
+ in the event of success or failure.
+
+ (2) Asynchronous afs_calls are self-referential whilst they are active to
+ prevent them from evaporating when they're not being processed. This
+ reference is disposed of when the afs_call is completed.
+
+ Note that an afs_call may only be completed once; once completed
+ completing it again will do nothing.
+
+ (3) When a call transmission is made, the app-side rxrpc code queues a Tx
+ buffer for the rxrpc I/O thread to transmit. The I/O thread invokes
+ sendmsg() to transmit it - and in the case of failure, it transitions
+ the rxrpc_call to the completed state.
+
+ (4) When an rxrpc_call is completed, the app layer is notified. In this
+ case, the app is kafs and it schedules a work item to process events
+ pertaining to an afs_call.
+
+ (5) When the afs_call event processor is run, it goes down through the
+ RPC-specific handler to afs_extract_data() to retrieve data from rxrpc
+ - and, in this case, it picks up the error from the rxrpc_call and
+ returns it.
+
+ The error is then propagated to the afs_call and that is completed
+ too. At this point the self-reference is released.
+
+ (6) If the rxrpc I/O thread manages to complete the rxrpc_call within the
+ window between rxrpc_send_data() queuing the request packet and
+ checking for call completion on the way out, then
+ rxrpc_kernel_send_data() will return the error from sendmsg() to the
+ app.
+
+ (7) Then afs_make_call() will see an error and will jump to the error
+ handling path which will attempt to clean up the afs_call.
+
+ (8) The problem comes when the error handling path in afs_make_call()
+ tries to unconditionally drop an async afs_call's self-reference.
+ This self-reference, however, may already have been dropped by
+ afs_extract_data() completing the afs_call
+
+ (9) The refcount underflows when we return to afs_do_probe_vlserver() and
+ that tries to drop its reference on the afs_call.
+
+Fix this by making afs_make_call() attempt to complete the afs_call rather
+than unconditionally putting it. That way, if afs_extract_data() manages
+to complete the call first, afs_make_call() won't do anything.
+
+The bug can be forced by making do_udp_sendmsg() return -ENETUNREACH and
+sticking an msleep() in rxrpc_send_data() after the 'success:' label to
+widen the race window.
+
+The error message looks something like:
+
+ refcount_t: underflow; use-after-free.
+ WARNING: CPU: 3 PID: 720 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
+ ...
+ RIP: 0010:refcount_warn_saturate+0xba/0x110
+ ...
+ afs_put_call+0x1dc/0x1f0 [kafs]
+ afs_fs_get_capabilities+0x8b/0xe0 [kafs]
+ afs_fs_probe_fileserver+0x188/0x1e0 [kafs]
+ afs_lookup_server+0x3bf/0x3f0 [kafs]
+ afs_alloc_server_list+0x130/0x2e0 [kafs]
+ afs_create_volume+0x162/0x400 [kafs]
+ afs_get_tree+0x266/0x410 [kafs]
+ vfs_get_tree+0x25/0xc0
+ fc_mount+0xe/0x40
+ afs_d_automount+0x1b3/0x390 [kafs]
+ __traverse_mounts+0x8f/0x210
+ step_into+0x340/0x760
+ path_openat+0x13a/0x1260
+ do_filp_open+0xaf/0x160
+ do_sys_openat2+0xaf/0x170
+
+or something like:
+
+ refcount_t: underflow; use-after-free.
+ ...
+ RIP: 0010:refcount_warn_saturate+0x99/0xda
+ ...
+ afs_put_call+0x4a/0x175
+ afs_send_vl_probes+0x108/0x172
+ afs_select_vlserver+0xd6/0x311
+ afs_do_cell_detect_alias+0x5e/0x1e9
+ afs_cell_detect_alias+0x44/0x92
+ afs_validate_fc+0x9d/0x134
+ afs_get_tree+0x20/0x2e6
+ vfs_get_tree+0x1d/0xc9
+ fc_mount+0xe/0x33
+ afs_d_automount+0x48/0x9d
+ __traverse_mounts+0xe0/0x166
+ step_into+0x140/0x274
+ open_last_lookups+0x1c1/0x1df
+ path_openat+0x138/0x1c3
+ do_filp_open+0x55/0xb4
+ do_sys_openat2+0x6c/0xb6
+
+Fixes: 34fa47612bfe ("afs: Fix race in async call refcounting")
+Reported-by: Bill MacAllister <bill@ca-zephyr.org>
+Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052304
+Suggested-by: Jeffrey E Altman <jaltman@auristor.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: linux-afs@lists.infradead.org
+Link: https://lore.kernel.org/r/2633992.1702073229@warthog.procyon.org.uk/ # v1
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/afs/rxrpc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
+index ed1644e7683f4..d642d06a453be 100644
+--- a/fs/afs/rxrpc.c
++++ b/fs/afs/rxrpc.c
+@@ -424,7 +424,7 @@ void afs_make_call(struct afs_addr_cursor *ac, struct afs_call *call, gfp_t gfp)
+ if (call->async) {
+ if (cancel_work_sync(&call->async_work))
+ afs_put_call(call);
+- afs_put_call(call);
++ afs_set_call_complete(call, ret, 0);
+ }
+
+ ac->error = ret;
+--
+2.43.0
+
--- /dev/null
+From bf69b4f046201bfec5da7af513d7364d764e854a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 11 Dec 2023 10:00:57 +0100
+Subject: efi/x86: Avoid physical KASLR on older Dell systems
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+[ Upstream commit 50d7cdf7a9b1ab6f4f74a69c84e974d5dc0c1bf1 ]
+
+River reports boot hangs with v6.6 and v6.7, and the bisect points to
+commit
+
+ a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
+
+which moves the memory allocation and kernel decompression from the
+legacy decompressor (which executes *after* ExitBootServices()) to the
+EFI stub, using boot services for allocating the memory. The memory
+allocation succeeds but the subsequent call to decompress_kernel() never
+returns, resulting in a failed boot and a hanging system.
+
+As it turns out, this issue only occurs when physical address
+randomization (KASLR) is enabled, and given that this is a feature we
+can live without (virtual KASLR is much more important), let's disable
+the physical part of KASLR when booting on AMI UEFI firmware claiming to
+implement revision v2.0 of the specification (which was released in
+2006), as this is the version these systems advertise.
+
+Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218173
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/efi/libstub/x86-stub.c | 31 +++++++++++++++++++------
+ 1 file changed, 24 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
+index 9d5df683f8821..70b325a2f1f31 100644
+--- a/drivers/firmware/efi/libstub/x86-stub.c
++++ b/drivers/firmware/efi/libstub/x86-stub.c
+@@ -307,17 +307,20 @@ static void setup_unaccepted_memory(void)
+ efi_err("Memory acceptance protocol failed\n");
+ }
+
++static efi_char16_t *efistub_fw_vendor(void)
++{
++ unsigned long vendor = efi_table_attr(efi_system_table, fw_vendor);
++
++ return (efi_char16_t *)vendor;
++}
++
+ static const efi_char16_t apple[] = L"Apple";
+
+ static void setup_quirks(struct boot_params *boot_params)
+ {
+- efi_char16_t *fw_vendor = (efi_char16_t *)(unsigned long)
+- efi_table_attr(efi_system_table, fw_vendor);
+-
+- if (!memcmp(fw_vendor, apple, sizeof(apple))) {
+- if (IS_ENABLED(CONFIG_APPLE_PROPERTIES))
+- retrieve_apple_device_properties(boot_params);
+- }
++ if (IS_ENABLED(CONFIG_APPLE_PROPERTIES) &&
++ !memcmp(efistub_fw_vendor(), apple, sizeof(apple)))
++ retrieve_apple_device_properties(boot_params);
+ }
+
+ /*
+@@ -799,11 +802,25 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry)
+
+ if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && !efi_nokaslr) {
+ u64 range = KERNEL_IMAGE_SIZE - LOAD_PHYSICAL_ADDR - kernel_total_size;
++ static const efi_char16_t ami[] = L"American Megatrends";
+
+ efi_get_seed(seed, sizeof(seed));
+
+ virt_addr += (range * seed[1]) >> 32;
+ virt_addr &= ~(CONFIG_PHYSICAL_ALIGN - 1);
++
++ /*
++ * Older Dell systems with AMI UEFI firmware v2.0 may hang
++ * while decompressing the kernel if physical address
++ * randomization is enabled.
++ *
++ * https://bugzilla.kernel.org/show_bug.cgi?id=218173
++ */
++ if (efi_system_table->hdr.revision <= EFI_2_00_SYSTEM_TABLE_REVISION &&
++ !memcmp(efistub_fw_vendor(), ami, sizeof(ami))) {
++ efi_debug("AMI firmware v2.0 or older detected - disabling physical KASLR\n");
++ seed[0] = 0;
++ }
+ }
+
+ status = efi_random_alloc(alloc_size, CONFIG_PHYSICAL_ALIGN, &addr,
+--
+2.43.0
+
--- /dev/null
+From 8a562e59fd9305ab22dfd80196bea309087fd560 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 30 Nov 2023 10:56:53 +0100
+Subject: ext4: fix warning in ext4_dio_write_end_io()
+
+From: Jan Kara <jack@suse.cz>
+
+[ Upstream commit 619f75dae2cf117b1d07f27b046b9ffb071c4685 ]
+
+The syzbot has reported that it can hit the warning in
+ext4_dio_write_end_io() because i_size < i_disksize. Indeed the
+reproducer creates a race between DIO IO completion and truncate
+expanding the file and thus ext4_dio_write_end_io() sees an inconsistent
+inode state where i_disksize is already updated but i_size is not
+updated yet. Since we are careful when setting up DIO write and consider
+it extending (and thus performing the IO synchronously with i_rwsem held
+exclusively) whenever it goes past either of i_size or i_disksize, we
+can use the same test during IO completion without risking entering
+ext4_handle_inode_extension() without i_rwsem held. This way we make it
+obvious both i_size and i_disksize are large enough when we report DIO
+completion without relying on unreliable WARN_ON.
+
+Reported-by: <syzbot+47479b71cdfc78f56d30@syzkaller.appspotmail.com>
+Fixes: 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
+Link: https://lore.kernel.org/r/20231130095653.22679-1-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ext4/file.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+diff --git a/fs/ext4/file.c b/fs/ext4/file.c
+index 0166bb9ca160b..6aa15dafc6778 100644
+--- a/fs/ext4/file.c
++++ b/fs/ext4/file.c
+@@ -349,9 +349,10 @@ static void ext4_inode_extension_cleanup(struct inode *inode, ssize_t count)
+ return;
+ }
+ /*
+- * If i_disksize got extended due to writeback of delalloc blocks while
+- * the DIO was running we could fail to cleanup the orphan list in
+- * ext4_handle_inode_extension(). Do it now.
++ * If i_disksize got extended either due to writeback of delalloc
++ * blocks or extending truncate while the DIO was running we could fail
++ * to cleanup the orphan list in ext4_handle_inode_extension(). Do it
++ * now.
+ */
+ if (!list_empty(&EXT4_I(inode)->i_orphan) && inode->i_nlink) {
+ handle_t *handle = ext4_journal_start(inode, EXT4_HT_INODE, 2);
+@@ -386,10 +387,11 @@ static int ext4_dio_write_end_io(struct kiocb *iocb, ssize_t size,
+ * blocks. But the code in ext4_iomap_alloc() is careful to use
+ * zeroed/unwritten extents if this is possible; thus we won't leave
+ * uninitialized blocks in a file even if we didn't succeed in writing
+- * as much as we intended.
++ * as much as we intended. Also we can race with truncate or write
++ * expanding the file so we have to be a bit careful here.
+ */
+- WARN_ON_ONCE(i_size_read(inode) < READ_ONCE(EXT4_I(inode)->i_disksize));
+- if (pos + size <= READ_ONCE(EXT4_I(inode)->i_disksize))
++ if (pos + size <= READ_ONCE(EXT4_I(inode)->i_disksize) &&
++ pos + size <= i_size_read(inode))
+ return size;
+ return ext4_handle_inode_extension(inode, pos, size);
+ }
+--
+2.43.0
+
--- /dev/null
+From b919bb0846dd17e905ac45abf6e60e94c887a4df Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 12 Dec 2023 15:31:48 +0200
+Subject: HID: lenovo: Restrict detection of patched firmware only to USB
+ cptkbd
+
+From: Mikhail Khvainitski <me@khvoinitsky.org>
+
+[ Upstream commit 43527a0094c10dfbf0d5a2e7979395a38de3ff65 ]
+
+Commit 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and
+stop applying workaround") introduced a regression for ThinkPad
+TrackPoint Keyboard II which has similar quirks to cptkbd (so it uses
+the same workarounds) but slightly different so that there are
+false-positives during detecting well-behaving firmware. This commit
+restricts detecting well-behaving firmware to the only model which
+known to have one and have stable enough quirks to not cause
+false-positives.
+
+Fixes: 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround")
+Link: https://lore.kernel.org/linux-input/ZXRiiPsBKNasioqH@jekhomev/
+Link: https://bbs.archlinux.org/viewtopic.php?pid=2135468#p2135468
+Signed-off-by: Mikhail Khvainitski <me@khvoinitsky.org>
+Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hid/hid-lenovo.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
+index 7c1b33be9d134..149a3c74346b4 100644
+--- a/drivers/hid/hid-lenovo.c
++++ b/drivers/hid/hid-lenovo.c
+@@ -692,7 +692,8 @@ static int lenovo_event_cptkbd(struct hid_device *hdev,
+ * so set middlebutton_state to 3
+ * to never apply workaround anymore
+ */
+- if (cptkbd_data->middlebutton_state == 1 &&
++ if (hdev->product == USB_DEVICE_ID_LENOVO_CUSBKBD &&
++ cptkbd_data->middlebutton_state == 1 &&
+ usage->type == EV_REL &&
+ (usage->code == REL_X || usage->code == REL_Y)) {
+ cptkbd_data->middlebutton_state = 3;
+--
+2.43.0
+
--- /dev/null
+From 286ba35caaa733e89fd93699f95a5f6366e6af3e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 1 Dec 2023 22:50:48 +0800
+Subject: ksmbd: fix memory leak in smb2_lock()
+
+From: Zizhi Wo <wozizhi@huawei.com>
+
+[ Upstream commit 8f1752723019db900fb60a5b9d0dfd3a2bdea36c ]
+
+In smb2_lock(), if setup_async_work() executes successfully,
+work->cancel_argv will bind the argv that generated by kmalloc(). And
+release_async_work() is called in ksmbd_conn_try_dequeue_request() or
+smb2_lock() to release argv.
+However, when setup_async_work function fails, work->cancel_argv has not
+been bound to the argv, resulting in the previously allocated argv not
+being released. Call kfree() to fix it.
+
+Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
+Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
+Acked-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/smb/server/smb2pdu.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
+index 269fbfb3cd678..2b248d45d40ae 100644
+--- a/fs/smb/server/smb2pdu.c
++++ b/fs/smb/server/smb2pdu.c
+@@ -7074,6 +7074,7 @@ int smb2_lock(struct ksmbd_work *work)
+ smb2_remove_blocked_lock,
+ argv);
+ if (rc) {
++ kfree(argv);
+ err = -ENOMEM;
+ goto out;
+ }
+--
+2.43.0
+
--- /dev/null
+From 61637f2ff11cb99b241e72c7da259f6331ba2aa7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 2 Dec 2023 17:17:12 -0800
+Subject: r8152: add vendor/device ID pair for ASUS USB-C2500
+
+From: Kelly Kane <kelly@hawknetworks.com>
+
+[ Upstream commit 7037d95a047cd89b1f680eed253c6ab586bef1ed ]
+
+The ASUS USB-C2500 is an RTL8156 based 2.5G Ethernet controller.
+
+Add the vendor and product ID values to the driver. This makes Ethernet
+work with the adapter.
+
+Signed-off-by: Kelly Kane <kelly@hawknetworks.com>
+Link: https://lore.kernel.org/r/20231203011712.6314-1-kelly@hawknetworks.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/r8152.c | 1 +
+ include/linux/usb/r8152.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
+index 7611c406fdb96..127b34dcc5b37 100644
+--- a/drivers/net/usb/r8152.c
++++ b/drivers/net/usb/r8152.c
+@@ -10016,6 +10016,7 @@ static const struct usb_device_id rtl8152_table[] = {
+ { USB_DEVICE(VENDOR_ID_NVIDIA, 0x09ff) },
+ { USB_DEVICE(VENDOR_ID_TPLINK, 0x0601) },
+ { USB_DEVICE(VENDOR_ID_DLINK, 0xb301) },
++ { USB_DEVICE(VENDOR_ID_ASUS, 0x1976) },
+ {}
+ };
+
+diff --git a/include/linux/usb/r8152.h b/include/linux/usb/r8152.h
+index 287e9d83fb8bc..33a4c146dc19c 100644
+--- a/include/linux/usb/r8152.h
++++ b/include/linux/usb/r8152.h
+@@ -30,6 +30,7 @@
+ #define VENDOR_ID_NVIDIA 0x0955
+ #define VENDOR_ID_TPLINK 0x2357
+ #define VENDOR_ID_DLINK 0x2001
++#define VENDOR_ID_ASUS 0x0b05
+
+ #if IS_REACHABLE(CONFIG_USB_RTL8152)
+ extern u8 rtl8152_get_version(struct usb_interface *intf);
+--
+2.43.0
+
--- /dev/null
+r8152-add-vendor-device-id-pair-for-asus-usb-c2500.patch
+ext4-fix-warning-in-ext4_dio_write_end_io.patch
+ksmbd-fix-memory-leak-in-smb2_lock.patch
+efi-x86-avoid-physical-kaslr-on-older-dell-systems.patch
+afs-fix-refcount-underflow-from-error-handling-race.patch
+hid-lenovo-restrict-detection-of-patched-firmware-on.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
