From: Sasha Levin Date: Thu, 14 Dec 2023 12:39:48 +0000 (-0500) Subject: Fixes for 6.6 X-Git-Tag: v5.15.144~66 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8b0dedf721b31b5d959329816b551986633cf383;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 6.6 Signed-off-by: Sasha Levin --- diff --git a/queue-6.6/afs-fix-refcount-underflow-from-error-handling-race.patch b/queue-6.6/afs-fix-refcount-underflow-from-error-handling-race.patch new file mode 100644 index 00000000000..db80e5e5033 --- /dev/null +++ b/queue-6.6/afs-fix-refcount-underflow-from-error-handling-race.patch @@ -0,0 +1,146 @@ +From aeb7079be37926f18f48e8c5e92588daa20316ee Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 11 Dec 2023 21:43:52 +0000 +Subject: afs: Fix refcount underflow from error handling race + +From: David Howells + +[ 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 +Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052304 +Suggested-by: Jeffrey E Altman +Signed-off-by: David Howells +Reviewed-by: Jeffrey Altman +cc: Marc Dionne +cc: linux-afs@lists.infradead.org +Link: https://lore.kernel.org/r/2633992.1702073229@warthog.procyon.org.uk/ # v1 +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/efi-x86-avoid-physical-kaslr-on-older-dell-systems.patch b/queue-6.6/efi-x86-avoid-physical-kaslr-on-older-dell-systems.patch new file mode 100644 index 00000000000..14be617b723 --- /dev/null +++ b/queue-6.6/efi-x86-avoid-physical-kaslr-on-older-dell-systems.patch @@ -0,0 +1,96 @@ +From bf69b4f046201bfec5da7af513d7364d764e854a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 11 Dec 2023 10:00:57 +0100 +Subject: efi/x86: Avoid physical KASLR on older Dell systems + +From: Ard Biesheuvel + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/ext4-fix-warning-in-ext4_dio_write_end_io.patch b/queue-6.6/ext4-fix-warning-in-ext4_dio_write_end_io.patch new file mode 100644 index 00000000000..dd23e294fc4 --- /dev/null +++ b/queue-6.6/ext4-fix-warning-in-ext4_dio_write_end_io.patch @@ -0,0 +1,69 @@ +From 8a562e59fd9305ab22dfd80196bea309087fd560 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 30 Nov 2023 10:56:53 +0100 +Subject: ext4: fix warning in ext4_dio_write_end_io() + +From: Jan Kara + +[ 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: +Fixes: 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") +Signed-off-by: Jan Kara +Reviewed-by: Ritesh Harjani (IBM) +Link: https://lore.kernel.org/r/20231130095653.22679-1-jack@suse.cz +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/hid-lenovo-restrict-detection-of-patched-firmware-on.patch b/queue-6.6/hid-lenovo-restrict-detection-of-patched-firmware-on.patch new file mode 100644 index 00000000000..860509f2c06 --- /dev/null +++ b/queue-6.6/hid-lenovo-restrict-detection-of-patched-firmware-on.patch @@ -0,0 +1,47 @@ +From b919bb0846dd17e905ac45abf6e60e94c887a4df Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 12 Dec 2023 15:31:48 +0200 +Subject: HID: lenovo: Restrict detection of patched firmware only to USB + cptkbd + +From: Mikhail Khvainitski + +[ 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 +Tested-by: Yauhen Kharuzhy +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/ksmbd-fix-memory-leak-in-smb2_lock.patch b/queue-6.6/ksmbd-fix-memory-leak-in-smb2_lock.patch new file mode 100644 index 00000000000..cb1e33fcb30 --- /dev/null +++ b/queue-6.6/ksmbd-fix-memory-leak-in-smb2_lock.patch @@ -0,0 +1,41 @@ +From 286ba35caaa733e89fd93699f95a5f6366e6af3e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 1 Dec 2023 22:50:48 +0800 +Subject: ksmbd: fix memory leak in smb2_lock() + +From: Zizhi Wo + +[ 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 +Acked-by: Namjae Jeon +Signed-off-by: Steve French +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/r8152-add-vendor-device-id-pair-for-asus-usb-c2500.patch b/queue-6.6/r8152-add-vendor-device-id-pair-for-asus-usb-c2500.patch new file mode 100644 index 00000000000..d6d05c92d3b --- /dev/null +++ b/queue-6.6/r8152-add-vendor-device-id-pair-for-asus-usb-c2500.patch @@ -0,0 +1,50 @@ +From 61637f2ff11cb99b241e72c7da259f6331ba2aa7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 2 Dec 2023 17:17:12 -0800 +Subject: r8152: add vendor/device ID pair for ASUS USB-C2500 + +From: Kelly Kane + +[ 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 +Link: https://lore.kernel.org/r/20231203011712.6314-1-kelly@hawknetworks.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.6/series b/queue-6.6/series new file mode 100644 index 00000000000..ab7f0d064ac --- /dev/null +++ b/queue-6.6/series @@ -0,0 +1,6 @@ +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