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

Linux 6.1.1

2022-12-21T16:48:12Z

Link: https://lore.kernel.org/r/20221219182943.395169070@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Rudi Heitbaum Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Jon Hunter Tested-by: Allen Pais Tested-by: Slade Watkins Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman

KEYS: encrypted: fix key instantiation with user-provided data

2022-12-21T16:48:11Z

commit 5adedd42245af0860ebda8fe0949f24f5204c1b1 upstream. Commit cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") added key instantiation with user provided decrypted data. The user data is hex-ascii-encoded but was just memcpy'ed to the binary buffer. Fix this to use hex2bin instead. Old keys created from user provided decrypted data saved with "keyctl pipe" are still valid, however if the key is recreated from decrypted data the old key must be converted to the correct format. This can be done with a small shell script, e.g.: BROKENKEY=abcdefABCDEF1234567890aaaaaaaaaa NEWKEY=$(echo -ne $BROKENKEY | xxd -p -c32) keyctl add user masterkey "$(cat masterkey.bin)" @u keyctl add encrypted testkey "new user:masterkey 32 $NEWKEY" @u However, NEWKEY is still broken: If for BROKENKEY 32 bytes were specified, a brute force attacker knowing the key properties would only need to try at most 2^(16*8) keys, as if the key was only 16 bytes long. The security issue is a result of the combination of limiting the input range to hex-ascii and using memcpy() instead of hex2bin(). It could have been fixed either by allowing binary input or using hex2bin() (and doubling the ascii input key length). This patch implements the latter. The corresponding test for the Linux Test Project ltp has also been fixed (see link below). Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") Cc: stable@kernel.org Link: https://lore.kernel.org/ltp/20221006081709.92303897@mail.steuer-voss.de/ Reviewed-by: Mimi Zohar Signed-off-by: Nikolaus Voss Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman

cifs: fix oops during encryption

2022-12-21T16:48:11Z

commit f7f291e14dde32a07b1f0aa06921d28f875a7b54 upstream. When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses. Signed-off-by: Paulo Alcantara (SUSE) Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

usb: dwc3: pci: Update PCIe device ID for USB3 controller on CPU sub-system for Raptor Lake

2022-12-21T16:48:10Z

commit f05f80f217bf52443a2582bca19fd78188333f25 upstream. The device ID 0xa70e is defined for the USB3 device controller in the CPU sub-system of Raptor Lake platform. Hence updating the ID accordingly. Fixes: bad0d1d726ac ("usb: dwc3: pci: Add support for Intel Raptor Lake") Cc: stable Reviewed-by: Heikki Krogerus Signed-off-by: Shruthi Sanil Link: https://lore.kernel.org/r/20221125105327.27945-1-shruthi.sanil@intel.com Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Resume in separate work

2022-12-21T16:48:10Z

commit e0dced9c7d4763fd97c86a13902d135f03cc42eb upstream. It can take more than one second to check each connector when the system is resumed. So if you have, say, eight connectors, it may take eight seconds for ucsi_resume() to finish. That's a bit too much. This will modify ucsi_resume() so that it schedules a work where the interface is actually resumed instead of checking the connectors directly. The connections will also be checked in separate tasks which are queued for each connector separately. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216706 Fixes: 99f6d4361113 ("usb: typec: ucsi: Check the connection on resume") Cc: Reported-by: Todd Brandt Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221123093021.25981-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman

igb: Initialize mailbox message for VF reset

2022-12-21T16:48:10Z

commit de5dc44370fbd6b46bd7f1a1e00369be54a041c8 upstream. When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address") Reported-by: Akihiko Odaki Signed-off-by: Tony Nguyen Reviewed-by: Akihiko Odaki Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221212190031.3983342-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

staging: r8188eu: fix led register settings

2022-12-21T16:48:09Z

commit 12c6223fc1804fd9295dc50d358294539b4a4184 upstream. Using an InterTech DMG-02 dongle, the led remains on when the system goes into standby mode. After wakeup, it's no longer possible to control the led. It turned out that the register settings to enable or disable the led were not correct. They worked for some dongles like the Edimax V2 but not for others like the InterTech DMG-02. This patch fixes the register settings. Bit 3 in the led_cfg2 register controls the led status, bit 5 must always be set to be able to control the led, bit 6 has no influence on the led. Setting the mac_pinmux_cfg register is not necessary. These settings were tested with Edimax V2 and InterTech DMG-02. Cc: stable@vger.kernel.org Fixes: 8cd574e6af54 ("staging: r8188eu: introduce new hal dir for RTL8188eu driver") Suggested-by: Michael Straube Signed-off-by: Martin Kaiser Tested-by: Michael Straube # InterTech DMG-02, Tested-by: Philipp Hortmann # Edimax N150 Link: https://lore.kernel.org/r/20221015151115.232095-2-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman

xhci: Apply XHCI_RESET_TO_DEFAULT quirk to ADL-N

2022-12-21T16:48:09Z

commit fed70b61ef2c0aed54456db3d485b215f6cc3209 upstream. ADL-N systems have the same issue as ADL-P, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to ADL-N as well. This patch depends on commit 34cd2db408d5 ("xhci: Add quirk to reset host back to default state at shutdown"). The issue it fixes is a ~20s boot time delay when booting from S5. It affects ADL-N devices, and ADL-N support was added starting from v5.16. Cc: stable@vger.kernel.org Signed-off-by: Reka Norman Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20221130091944.2171610-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: fix mute/micmute LEDs for a HP ProBook

2022-12-21T16:48:08Z

commit 1d8025ec722d5e011f9299c46274eb21fb54a428 upstream. There is a HP ProBook which using ALC236 codec and need the ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to make mute LED and micmute LED work. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20221128022849.13759-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

USB: serial: f81534: fix division by zero on line-speed change

2022-12-21T16:48:08Z

commit 188c9c2e0c7f4ae864113f80c40bafb394062271 upstream. The driver leaves the line speed unchanged in case a requested speed is not supported. Make sure to handle the case where the current speed is B0 (hangup) without dividing by zero when determining the clock source. Fixes: 3aacac02f385 ("USB: serial: f81534: add high baud rate support") Cc: stable@vger.kernel.org # 4.16 Cc: Ji-Ze Hong (Peter Hong) Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman