From: Greg Kroah-Hartman Date: Tue, 10 Jan 2023 16:00:17 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v5.15.87~15 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=87dabc52eaf931268710ffff7ffc4632ea7a46f8;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch mptcp-dedicated-request-sock-for-subflow-in-v6.patch mptcp-use-proper-req-destructor-for-ipv6.patch revert-acpi-pm-add-support-for-upcoming-amd-upep-hid-amdi007.patch selftests-set-the-build-variable-to-absolute-path.patch --- diff --git a/queue-5.15/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch b/queue-5.15/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch new file mode 100644 index 00000000000..4e3e5aaeccd --- /dev/null +++ b/queue-5.15/ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch @@ -0,0 +1,58 @@ +From 105c78e12468413e426625831faa7db4284e1fec Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 1 Nov 2022 22:33:12 -0700 +Subject: ext4: don't allow journal inode to have encrypt flag + +From: Eric Biggers + +commit 105c78e12468413e426625831faa7db4284e1fec upstream. + +Mounting a filesystem whose journal inode has the encrypt flag causes a +NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' +mount option is used. + +The problem is that when jbd2_journal_init_inode() calls bmap(), it +eventually finds its way into ext4_iomap_begin(), which calls +fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if +the inode is encrypted, then its encryption key must already be set up. +That's not the case here, since the journal inode is never "opened" like +a normal file would be. Hence the crash. + +A reproducer is: + + mkfs.ext4 -F /dev/vdb + debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808" + mount /dev/vdb /mnt -o inlinecrypt + +To fix this, make ext4 consider journal inodes with the encrypt flag to +be invalid. (Note, maybe other flags should be rejected on the journal +inode too. For now, this is just the minimal fix for the above issue.) + +I've marked this as fixing the commit that introduced the call to +fscrypt_limit_io_blocks(), since that's what made an actual crash start +being possible. But this fix could be applied to any version of ext4 +that supports the encrypt feature. + +Reported-by: syzbot+ba9dac45bc76c490b7c3@syzkaller.appspotmail.com +Fixes: 38ea50daa7a4 ("ext4: support direct I/O with fscrypt using blk-crypto") +Cc: stable@vger.kernel.org +Signed-off-by: Eric Biggers +Link: https://lore.kernel.org/r/20221102053312.189962-1-ebiggers@kernel.org +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/super.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -5157,7 +5157,7 @@ static struct inode *ext4_get_journal_in + + ext4_debug("Journal inode found at %p: %lld bytes\n", + journal_inode, journal_inode->i_size); +- if (!S_ISREG(journal_inode->i_mode)) { ++ if (!S_ISREG(journal_inode->i_mode) || IS_ENCRYPTED(journal_inode)) { + ext4_msg(sb, KERN_ERR, "invalid journal inode"); + iput(journal_inode); + return NULL; diff --git a/queue-5.15/mptcp-dedicated-request-sock-for-subflow-in-v6.patch b/queue-5.15/mptcp-dedicated-request-sock-for-subflow-in-v6.patch new file mode 100644 index 00000000000..e723a504241 --- /dev/null +++ b/queue-5.15/mptcp-dedicated-request-sock-for-subflow-in-v6.patch @@ -0,0 +1,129 @@ +From 34b21d1ddc8ace77a8fa35c1b1e06377209e0dae Mon Sep 17 00:00:00 2001 +From: Matthieu Baerts +Date: Fri, 9 Dec 2022 16:28:09 -0800 +Subject: mptcp: dedicated request sock for subflow in v6 + +From: Matthieu Baerts + +commit 34b21d1ddc8ace77a8fa35c1b1e06377209e0dae upstream. + +tcp_request_sock_ops structure is specific to IPv4. It should then not +be used with MPTCP subflows on top of IPv6. + +For example, it contains the 'family' field, initialised to AF_INET. +This 'family' field is used by TCP FastOpen code to generate the cookie +but also by TCP Metrics, SELinux and SYN Cookies. Using the wrong family +will not lead to crashes but displaying/using/checking wrong things. + +Note that 'send_reset' callback from request_sock_ops structure is used +in some error paths. It is then also important to use the correct one +for IPv4 or IPv6. + +The slab name can also be different in IPv4 and IPv6, it will be used +when printing some log messages. The slab pointer will anyway be the +same because the object size is the same for both v4 and v6. A +BUILD_BUG_ON() has also been added to make sure this size is the same. + +Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") +Reviewed-by: Mat Martineau +Cc: stable@vger.kernel.org +Signed-off-by: Matthieu Baerts +Signed-off-by: Mat Martineau +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/subflow.c | 34 ++++++++++++++++++++++++++-------- + 1 file changed, 26 insertions(+), 8 deletions(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -483,7 +483,7 @@ do_reset: + mptcp_subflow_reset(sk); + } + +-static struct request_sock_ops mptcp_subflow_request_sock_ops __ro_after_init; ++static struct request_sock_ops mptcp_subflow_v4_request_sock_ops __ro_after_init; + static struct tcp_request_sock_ops subflow_request_sock_ipv4_ops __ro_after_init; + + static int subflow_v4_conn_request(struct sock *sk, struct sk_buff *skb) +@@ -496,7 +496,7 @@ static int subflow_v4_conn_request(struc + if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST)) + goto drop; + +- return tcp_conn_request(&mptcp_subflow_request_sock_ops, ++ return tcp_conn_request(&mptcp_subflow_v4_request_sock_ops, + &subflow_request_sock_ipv4_ops, + sk, skb); + drop: +@@ -505,6 +505,7 @@ drop: + } + + #if IS_ENABLED(CONFIG_MPTCP_IPV6) ++static struct request_sock_ops mptcp_subflow_v6_request_sock_ops __ro_after_init; + static struct tcp_request_sock_ops subflow_request_sock_ipv6_ops __ro_after_init; + static struct inet_connection_sock_af_ops subflow_v6_specific __ro_after_init; + static struct inet_connection_sock_af_ops subflow_v6m_specific __ro_after_init; +@@ -527,7 +528,7 @@ static int subflow_v6_conn_request(struc + return 0; + } + +- return tcp_conn_request(&mptcp_subflow_request_sock_ops, ++ return tcp_conn_request(&mptcp_subflow_v6_request_sock_ops, + &subflow_request_sock_ipv6_ops, sk, skb); + + drop: +@@ -540,7 +541,12 @@ struct request_sock *mptcp_subflow_reqsk + struct sock *sk_listener, + bool attach_listener) + { +- ops = &mptcp_subflow_request_sock_ops; ++ if (ops->family == AF_INET) ++ ops = &mptcp_subflow_v4_request_sock_ops; ++#if IS_ENABLED(CONFIG_MPTCP_IPV6) ++ else if (ops->family == AF_INET6) ++ ops = &mptcp_subflow_v6_request_sock_ops; ++#endif + + return inet_reqsk_alloc(ops, sk_listener, attach_listener); + } +@@ -1791,7 +1797,6 @@ static struct tcp_ulp_ops subflow_ulp_op + static int subflow_ops_init(struct request_sock_ops *subflow_ops) + { + subflow_ops->obj_size = sizeof(struct mptcp_subflow_request_sock); +- subflow_ops->slab_name = "request_sock_subflow"; + + subflow_ops->slab = kmem_cache_create(subflow_ops->slab_name, + subflow_ops->obj_size, 0, +@@ -1808,9 +1813,10 @@ static int subflow_ops_init(struct reque + + void __init mptcp_subflow_init(void) + { +- mptcp_subflow_request_sock_ops = tcp_request_sock_ops; +- if (subflow_ops_init(&mptcp_subflow_request_sock_ops) != 0) +- panic("MPTCP: failed to init subflow request sock ops\n"); ++ mptcp_subflow_v4_request_sock_ops = tcp_request_sock_ops; ++ mptcp_subflow_v4_request_sock_ops.slab_name = "request_sock_subflow_v4"; ++ if (subflow_ops_init(&mptcp_subflow_v4_request_sock_ops) != 0) ++ panic("MPTCP: failed to init subflow v4 request sock ops\n"); + + subflow_request_sock_ipv4_ops = tcp_request_sock_ipv4_ops; + subflow_request_sock_ipv4_ops.route_req = subflow_v4_route_req; +@@ -1824,6 +1830,18 @@ void __init mptcp_subflow_init(void) + tcp_prot_override.release_cb = tcp_release_cb_override; + + #if IS_ENABLED(CONFIG_MPTCP_IPV6) ++ /* In struct mptcp_subflow_request_sock, we assume the TCP request sock ++ * structures for v4 and v6 have the same size. It should not changed in ++ * the future but better to make sure to be warned if it is no longer ++ * the case. ++ */ ++ BUILD_BUG_ON(sizeof(struct tcp_request_sock) != sizeof(struct tcp6_request_sock)); ++ ++ mptcp_subflow_v6_request_sock_ops = tcp6_request_sock_ops; ++ mptcp_subflow_v6_request_sock_ops.slab_name = "request_sock_subflow_v6"; ++ if (subflow_ops_init(&mptcp_subflow_v6_request_sock_ops) != 0) ++ panic("MPTCP: failed to init subflow v6 request sock ops\n"); ++ + subflow_request_sock_ipv6_ops = tcp_request_sock_ipv6_ops; + subflow_request_sock_ipv6_ops.route_req = subflow_v6_route_req; + diff --git a/queue-5.15/mptcp-use-proper-req-destructor-for-ipv6.patch b/queue-5.15/mptcp-use-proper-req-destructor-for-ipv6.patch new file mode 100644 index 00000000000..2326c68d8f1 --- /dev/null +++ b/queue-5.15/mptcp-use-proper-req-destructor-for-ipv6.patch @@ -0,0 +1,90 @@ +From d3295fee3c756ece33ac0d935e172e68c0a4161b Mon Sep 17 00:00:00 2001 +From: Matthieu Baerts +Date: Fri, 9 Dec 2022 16:28:10 -0800 +Subject: mptcp: use proper req destructor for IPv6 + +From: Matthieu Baerts + +commit d3295fee3c756ece33ac0d935e172e68c0a4161b upstream. + +Before, only the destructor from TCP request sock in IPv4 was called +even if the subflow was IPv6. + +It is important to use the right destructor to avoid memory leaks with +some advanced IPv6 features, e.g. when the request socks contain +specific IPv6 options. + +Fixes: 79c0949e9a09 ("mptcp: Add key generation and token tree") +Reviewed-by: Mat Martineau +Cc: stable@vger.kernel.org +Signed-off-by: Matthieu Baerts +Signed-off-by: Mat Martineau +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/subflow.c | 19 ++++++++++++++++--- + 1 file changed, 16 insertions(+), 3 deletions(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -45,7 +45,6 @@ static void subflow_req_destructor(struc + sock_put((struct sock *)subflow_req->msk); + + mptcp_token_destroy_request(req); +- tcp_request_sock_ops.destructor(req); + } + + static void subflow_generate_hmac(u64 key1, u64 key2, u32 nonce1, u32 nonce2, +@@ -504,6 +503,12 @@ drop: + return 0; + } + ++static void subflow_v4_req_destructor(struct request_sock *req) ++{ ++ subflow_req_destructor(req); ++ tcp_request_sock_ops.destructor(req); ++} ++ + #if IS_ENABLED(CONFIG_MPTCP_IPV6) + static struct request_sock_ops mptcp_subflow_v6_request_sock_ops __ro_after_init; + static struct tcp_request_sock_ops subflow_request_sock_ipv6_ops __ro_after_init; +@@ -535,6 +540,12 @@ drop: + tcp_listendrop(sk); + return 0; /* don't send reset */ + } ++ ++static void subflow_v6_req_destructor(struct request_sock *req) ++{ ++ subflow_req_destructor(req); ++ tcp6_request_sock_ops.destructor(req); ++} + #endif + + struct request_sock *mptcp_subflow_reqsk_alloc(const struct request_sock_ops *ops, +@@ -1806,8 +1817,6 @@ static int subflow_ops_init(struct reque + if (!subflow_ops->slab) + return -ENOMEM; + +- subflow_ops->destructor = subflow_req_destructor; +- + return 0; + } + +@@ -1815,6 +1824,8 @@ void __init mptcp_subflow_init(void) + { + mptcp_subflow_v4_request_sock_ops = tcp_request_sock_ops; + mptcp_subflow_v4_request_sock_ops.slab_name = "request_sock_subflow_v4"; ++ mptcp_subflow_v4_request_sock_ops.destructor = subflow_v4_req_destructor; ++ + if (subflow_ops_init(&mptcp_subflow_v4_request_sock_ops) != 0) + panic("MPTCP: failed to init subflow v4 request sock ops\n"); + +@@ -1839,6 +1850,8 @@ void __init mptcp_subflow_init(void) + + mptcp_subflow_v6_request_sock_ops = tcp6_request_sock_ops; + mptcp_subflow_v6_request_sock_ops.slab_name = "request_sock_subflow_v6"; ++ mptcp_subflow_v6_request_sock_ops.destructor = subflow_v6_req_destructor; ++ + if (subflow_ops_init(&mptcp_subflow_v6_request_sock_ops) != 0) + panic("MPTCP: failed to init subflow v6 request sock ops\n"); + diff --git a/queue-5.15/revert-acpi-pm-add-support-for-upcoming-amd-upep-hid-amdi007.patch b/queue-5.15/revert-acpi-pm-add-support-for-upcoming-amd-upep-hid-amdi007.patch new file mode 100644 index 00000000000..53866c5d5c1 --- /dev/null +++ b/queue-5.15/revert-acpi-pm-add-support-for-upcoming-amd-upep-hid-amdi007.patch @@ -0,0 +1,76 @@ +From mario.limonciello@amd.com Tue Jan 10 16:44:08 2023 +From: Mario Limonciello +Date: Thu, 5 Jan 2023 14:10:50 -0600 +Subject: Revert "ACPI: PM: Add support for upcoming AMD uPEP HID AMDI007" +To: +Cc: Mario Limonciello +Message-ID: <20230105201050.20602-1-mario.limonciello@amd.com> + +From: Mario Limonciello + +A number of AMD based Rembrandt laptops are not working properly in +suspend/resume. This has been root caused to be from the BIOS +implementation not populating code for the AMD GUID in uPEP, but +instead only the Microsoft one. + +In later kernels this has been fixed by using the Microsoft GUID +instead. + +The following series of patches has fixed it in newer kernels: + +commit ed470febf837 ("ACPI: PM: s2idle: Add support for upcoming AMD uPEP HID AMDI008") +commit 1a2dcab517cb ("ACPI: PM: s2idle: Use LPS0 idle if ACPI_FADT_LOW_POWER_S0 is unset") +commit 100a57379380 ("ACPI: x86: s2idle: Move _HID handling for AMD systems into structures") +commit fd894f05cf30 ("ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt") +commit a0bc002393d4 ("ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID") +commit d0f61e89f08d ("ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE") +commit ddeea2c3cb88 ("ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14") +commit 888ca9c7955e ("ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7") +commit 631b54519e8e ("ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13") +commit 39f81776c680 ("ACPI: x86: s2idle: Fix a NULL pointer dereference") +commit 54bd1e548701 ("ACPI: x86: s2idle: Add another ID to s2idle_dmi_table") +commit 577821f756cf ("ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865") +commit e6d180a35bc0 ("ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+") + +This is needlessly complex for 5.15.y though. To accomplish the same +effective result revert commit f0c6225531e4 ("ACPI: PM: Add support for +upcoming AMD uPEP HID AMDI007") instead. + +Link: https://lore.kernel.org/stable/MN0PR12MB61015DB3D6EDBFD841157918E2F59@MN0PR12MB6101.namprd12.prod.outlook.com/ +Signed-off-by: Mario Limonciello +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/x86/s2idle.c | 10 ++-------- + 1 file changed, 2 insertions(+), 8 deletions(-) + +--- a/drivers/acpi/x86/s2idle.c ++++ b/drivers/acpi/x86/s2idle.c +@@ -378,16 +378,13 @@ static int lps0_device_attach(struct acp + * AMDI0006: + * - should use rev_id 0x0 + * - function mask = 0x3: Should use Microsoft method +- * AMDI0007: +- * - Should use rev_id 0x2 +- * - Should only use AMD method + */ + const char *hid = acpi_device_hid(adev); +- rev_id = strcmp(hid, "AMDI0007") ? 0 : 2; ++ rev_id = 0; + lps0_dsm_func_mask = validate_dsm(adev->handle, + ACPI_LPS0_DSM_UUID_AMD, rev_id, &lps0_dsm_guid); + lps0_dsm_func_mask_microsoft = validate_dsm(adev->handle, +- ACPI_LPS0_DSM_UUID_MICROSOFT, 0, ++ ACPI_LPS0_DSM_UUID_MICROSOFT, rev_id, + &lps0_dsm_guid_microsoft); + if (lps0_dsm_func_mask > 0x3 && (!strcmp(hid, "AMD0004") || + !strcmp(hid, "AMD0005") || +@@ -395,9 +392,6 @@ static int lps0_device_attach(struct acp + lps0_dsm_func_mask = (lps0_dsm_func_mask << 1) | 0x1; + acpi_handle_debug(adev->handle, "_DSM UUID %s: Adjusted function mask: 0x%x\n", + ACPI_LPS0_DSM_UUID_AMD, lps0_dsm_func_mask); +- } else if (lps0_dsm_func_mask_microsoft > 0 && !strcmp(hid, "AMDI0007")) { +- lps0_dsm_func_mask_microsoft = -EINVAL; +- acpi_handle_debug(adev->handle, "_DSM Using AMD method\n"); + } + } else { + rev_id = 1; diff --git a/queue-5.15/selftests-set-the-build-variable-to-absolute-path.patch b/queue-5.15/selftests-set-the-build-variable-to-absolute-path.patch new file mode 100644 index 00000000000..20a9e276cd8 --- /dev/null +++ b/queue-5.15/selftests-set-the-build-variable-to-absolute-path.patch @@ -0,0 +1,70 @@ +From 5ad51ab618de5d05f4e692ebabeb6fe6289aaa57 Mon Sep 17 00:00:00 2001 +From: Muhammad Usama Anjum +Date: Wed, 19 Jan 2022 15:15:22 +0500 +Subject: selftests: set the BUILD variable to absolute path + +From: Muhammad Usama Anjum + +commit 5ad51ab618de5d05f4e692ebabeb6fe6289aaa57 upstream. + +The build of kselftests fails if relative path is specified through +KBUILD_OUTPUT or O= method. BUILD variable is used to determine +the path of the output objects. When make is run from other directories +with relative paths, the exact path of the build objects is ambiguous +and build fails. + + make[1]: Entering directory '/home/usama/repos/kernel/linux_mainline2/tools/testing/selftests/alsa' + gcc mixer-test.c -L/usr/lib/x86_64-linux-gnu -lasound -o build/kselftest/alsa/mixer-test + /usr/bin/ld: cannot open output file build/kselftest/alsa/mixer-test + +Set the BUILD variable to the absolute path of the output directory. +Make the logic readable and easy to follow. Use spaces instead of tabs +for indentation as if with tab indentation is considered recipe in make. + +Signed-off-by: Muhammad Usama Anjum +Signed-off-by: Shuah Khan +Signed-off-by: Tyler Hicks (Microsoft) +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/Makefile | 26 +++++++++++++++++--------- + 1 file changed, 17 insertions(+), 9 deletions(-) + +--- a/tools/testing/selftests/Makefile ++++ b/tools/testing/selftests/Makefile +@@ -114,19 +114,27 @@ ifdef building_out_of_srctree + override LDFLAGS = + endif + +-ifneq ($(O),) +- BUILD := $(O)/kselftest ++top_srcdir ?= ../../.. ++ ++ifeq ("$(origin O)", "command line") ++ KBUILD_OUTPUT := $(O) ++endif ++ ++ifneq ($(KBUILD_OUTPUT),) ++ # Make's built-in functions such as $(abspath ...), $(realpath ...) cannot ++ # expand a shell special character '~'. We use a somewhat tedious way here. ++ abs_objtree := $(shell cd $(top_srcdir) && mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) && pwd) ++ $(if $(abs_objtree),, \ ++ $(error failed to create output directory "$(KBUILD_OUTPUT)")) ++ # $(realpath ...) resolves symlinks ++ abs_objtree := $(realpath $(abs_objtree)) ++ BUILD := $(abs_objtree)/kselftest + else +- ifneq ($(KBUILD_OUTPUT),) +- BUILD := $(KBUILD_OUTPUT)/kselftest +- else +- BUILD := $(shell pwd) +- DEFAULT_INSTALL_HDR_PATH := 1 +- endif ++ BUILD := $(CURDIR) ++ DEFAULT_INSTALL_HDR_PATH := 1 + endif + + # Prepare for headers install +-top_srcdir ?= ../../.. + include $(top_srcdir)/scripts/subarch.include + ARCH ?= $(SUBARCH) + export KSFT_KHDR_INSTALL_DONE := 1 diff --git a/queue-5.15/series b/queue-5.15/series index 9cb0fa95318..b98927d09bc 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -277,3 +277,8 @@ hfs-hfsplus-use-warn_on-for-sanity-check.patch hfs-hfsplus-avoid-warn_on-for-sanity-check-use-proper-error-handling.patch ksmbd-fix-infinite-loop-in-ksmbd_conn_handler_loop.patch ksmbd-check-nt_len-to-be-at-least-cifs_encpwd_size-in-ksmbd_decode_ntlmssp_auth_blob.patch +revert-acpi-pm-add-support-for-upcoming-amd-upep-hid-amdi007.patch +mptcp-dedicated-request-sock-for-subflow-in-v6.patch +mptcp-use-proper-req-destructor-for-ipv6.patch +ext4-don-t-allow-journal-inode-to-have-encrypt-flag.patch +selftests-set-the-build-variable-to-absolute-path.patch