--- /dev/null
+From 105c78e12468413e426625831faa7db4284e1fec Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 1 Nov 2022 22:33:12 -0700
+Subject: ext4: don't allow journal inode to have encrypt flag
+
+From: Eric Biggers <ebiggers@google.com>
+
+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 <ebiggers@google.com>
+Link: https://lore.kernel.org/r/20221102053312.189962-1-ebiggers@kernel.org
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 34b21d1ddc8ace77a8fa35c1b1e06377209e0dae Mon Sep 17 00:00:00 2001
+From: Matthieu Baerts <matthieu.baerts@tessares.net>
+Date: Fri, 9 Dec 2022 16:28:09 -0800
+Subject: mptcp: dedicated request sock for subflow in v6
+
+From: Matthieu Baerts <matthieu.baerts@tessares.net>
+
+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 <mathew.j.martineau@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From d3295fee3c756ece33ac0d935e172e68c0a4161b Mon Sep 17 00:00:00 2001
+From: Matthieu Baerts <matthieu.baerts@tessares.net>
+Date: Fri, 9 Dec 2022 16:28:10 -0800
+Subject: mptcp: use proper req destructor for IPv6
+
+From: Matthieu Baerts <matthieu.baerts@tessares.net>
+
+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 <mathew.j.martineau@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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");
+
--- /dev/null
+From mario.limonciello@amd.com Tue Jan 10 16:44:08 2023
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 5 Jan 2023 14:10:50 -0600
+Subject: Revert "ACPI: PM: Add support for upcoming AMD uPEP HID AMDI007"
+To: <stable@vger.kernel.org>
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Message-ID: <20230105201050.20602-1-mario.limonciello@amd.com>
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+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 <mario.limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 5ad51ab618de5d05f4e692ebabeb6fe6289aaa57 Mon Sep 17 00:00:00 2001
+From: Muhammad Usama Anjum <usama.anjum@collabora.com>
+Date: Wed, 19 Jan 2022 15:15:22 +0500
+Subject: selftests: set the BUILD variable to absolute path
+
+From: Muhammad Usama Anjum <usama.anjum@collabora.com>
+
+commit 5ad51ab618de5d05f4e692ebabeb6fe6289aaa57 upstream.
+
+The build of kselftests fails if relative path is specified through
+KBUILD_OUTPUT or O=<path> 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 <usama.anjum@collabora.com>
+Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Tyler Hicks (Microsoft) <code@tyhicks.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
