--- /dev/null
+From 0733325e29a8bb8af457e2bfcd7fbd2c95d87ee1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 17 Sep 2023 23:38:46 +0800
+Subject: bpf: Fix tr dereferencing
+
+From: Leon Hwang <hffilwlqm@gmail.com>
+
+[ Upstream commit b724a6418f1f853bcb39c8923bf14a50c7bdbd07 ]
+
+Fix 'tr' dereferencing bug when CONFIG_BPF_JIT is turned off.
+
+When CONFIG_BPF_JIT is turned off, 'bpf_trampoline_get()' returns NULL,
+which is same as the cases when CONFIG_BPF_JIT is turned on.
+
+Closes: https://lore.kernel.org/r/202309131936.5Nc8eUD0-lkp@intel.com/
+Fixes: f7b12b6fea00 ("bpf: verifier: refactor check_attach_btf_id()")
+Reported-by: kernel test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
+Signed-off-by: Leon Hwang <hffilwlqm@gmail.com>
+Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
+Link: https://lore.kernel.org/bpf/20230917153846.88732-1-hffilwlqm@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/bpf.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/linux/bpf.h b/include/linux/bpf.h
+index b010d45a1ecd5..8f4379e93ad49 100644
+--- a/include/linux/bpf.h
++++ b/include/linux/bpf.h
+@@ -725,7 +725,7 @@ static inline int bpf_trampoline_unlink_prog(struct bpf_prog *prog,
+ static inline struct bpf_trampoline *bpf_trampoline_get(u64 key,
+ struct bpf_attach_target_info *tgt_info)
+ {
+- return ERR_PTR(-EOPNOTSUPP);
++ return NULL;
+ }
+ static inline void bpf_trampoline_put(struct bpf_trampoline *tr) {}
+ #define DEFINE_BPF_DISPATCHER(name)
+--
+2.40.1
+
--- /dev/null
+From 2efbc21de5f05f3f267d5ec82efa4a6d59f83431 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 19 Sep 2023 17:25:02 +0300
+Subject: drivers/net: process the result of hdlc_open() and add call of
+ hdlc_close() in uhdlc_close()
+
+From: Alexandra Diupina <adiupina@astralinux.ru>
+
+[ Upstream commit a59addacf899b1b21a7b7449a1c52c98704c2472 ]
+
+Process the result of hdlc_open() and call uhdlc_close()
+in case of an error. It is necessary to pass the error
+code up the control flow, similar to a possible
+error in request_irq().
+Also add a hdlc_close() call to the uhdlc_close()
+because the comment to hdlc_close() says it must be called
+by the hardware driver when the HDLC device is being closed
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
+Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wan/fsl_ucc_hdlc.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
+index ae1ae65e7f90a..bc3650c70730a 100644
+--- a/drivers/net/wan/fsl_ucc_hdlc.c
++++ b/drivers/net/wan/fsl_ucc_hdlc.c
+@@ -34,6 +34,8 @@
+ #define TDM_PPPOHT_SLIC_MAXIN
+ #define RX_BD_ERRORS (R_CD_S | R_OV_S | R_CR_S | R_AB_S | R_NO_S | R_LG_S)
+
++static int uhdlc_close(struct net_device *dev);
++
+ static struct ucc_tdm_info utdm_primary_info = {
+ .uf_info = {
+ .tsa = 0,
+@@ -708,6 +710,7 @@ static int uhdlc_open(struct net_device *dev)
+ hdlc_device *hdlc = dev_to_hdlc(dev);
+ struct ucc_hdlc_private *priv = hdlc->priv;
+ struct ucc_tdm *utdm = priv->utdm;
++ int rc = 0;
+
+ if (priv->hdlc_busy != 1) {
+ if (request_irq(priv->ut_info->uf_info.irq,
+@@ -731,10 +734,13 @@ static int uhdlc_open(struct net_device *dev)
+ napi_enable(&priv->napi);
+ netdev_reset_queue(dev);
+ netif_start_queue(dev);
+- hdlc_open(dev);
++
++ rc = hdlc_open(dev);
++ if (rc)
++ uhdlc_close(dev);
+ }
+
+- return 0;
++ return rc;
+ }
+
+ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
+@@ -824,6 +830,8 @@ static int uhdlc_close(struct net_device *dev)
+ netdev_reset_queue(dev);
+ priv->hdlc_busy = 0;
+
++ hdlc_close(dev);
++
+ return 0;
+ }
+
+--
+2.40.1
+
--- /dev/null
+From f78c2b65460cf5c50519be44ccea11add1fab7bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 Sep 2023 06:45:05 +0000
+Subject: ima: Finish deprecation of IMA_TRUSTED_KEYRING Kconfig
+
+From: Oleksandr Tymoshenko <ovt@google.com>
+
+[ Upstream commit be210c6d3597faf330cb9af33b9f1591d7b2a983 ]
+
+The removal of IMA_TRUSTED_KEYRING made IMA_LOAD_X509
+and IMA_BLACKLIST_KEYRING unavailable because the latter
+two depend on the former. Since IMA_TRUSTED_KEYRING was
+deprecated in favor of INTEGRITY_TRUSTED_KEYRING use it
+as a dependency for the two Kconfigs affected by the
+deprecation.
+
+Fixes: 5087fd9e80e5 ("ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig")
+Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
+Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ security/integrity/ima/Kconfig | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
+index 05b8f5bcc37ac..d1b490705c2e8 100644
+--- a/security/integrity/ima/Kconfig
++++ b/security/integrity/ima/Kconfig
+@@ -268,7 +268,7 @@ config IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
+ config IMA_BLACKLIST_KEYRING
+ bool "Create IMA machine owner blacklist keyrings (EXPERIMENTAL)"
+ depends on SYSTEM_TRUSTED_KEYRING
+- depends on IMA_TRUSTED_KEYRING
++ depends on INTEGRITY_TRUSTED_KEYRING
+ default n
+ help
+ This option creates an IMA blacklist keyring, which contains all
+@@ -278,7 +278,7 @@ config IMA_BLACKLIST_KEYRING
+
+ config IMA_LOAD_X509
+ bool "Load X509 certificate onto the '.ima' trusted keyring"
+- depends on IMA_TRUSTED_KEYRING
++ depends on INTEGRITY_TRUSTED_KEYRING
+ default n
+ help
+ File signature verification is based on the public keys
+--
+2.40.1
+
--- /dev/null
+From 754170512093a981eb08ec51bb26a3fd2be6e2f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Sep 2023 09:22:14 +0200
+Subject: ima: rework CONFIG_IMA dependency block
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit 91e326563ee34509c35267808a4b1b3ea3db62a8 ]
+
+Changing the direct dependencies of IMA_BLACKLIST_KEYRING and
+IMA_LOAD_X509 caused them to no longer depend on IMA, but a
+a configuration without IMA results in link failures:
+
+arm-linux-gnueabi-ld: security/integrity/iint.o: in function `integrity_load_keys':
+iint.c:(.init.text+0xd8): undefined reference to `ima_load_x509'
+
+aarch64-linux-ld: security/integrity/digsig_asymmetric.o: in function `asymmetric_verify':
+digsig_asymmetric.c:(.text+0x104): undefined reference to `ima_blacklist_keyring'
+
+Adding explicit dependencies on IMA would fix this, but a more reliable
+way to do this is to enclose the entire Kconfig file in an 'if IMA' block.
+This also allows removing the existing direct dependencies.
+
+Fixes: be210c6d3597f ("ima: Finish deprecation of IMA_TRUSTED_KEYRING Kconfig")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ security/integrity/ima/Kconfig | 17 ++++++-----------
+ 1 file changed, 6 insertions(+), 11 deletions(-)
+
+diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
+index d1b490705c2e8..d0d3ff58da491 100644
+--- a/security/integrity/ima/Kconfig
++++ b/security/integrity/ima/Kconfig
+@@ -29,9 +29,11 @@ config IMA
+ to learn more about IMA.
+ If unsure, say N.
+
++if IMA
++
+ config IMA_KEXEC
+ bool "Enable carrying the IMA measurement list across a soft boot"
+- depends on IMA && TCG_TPM && HAVE_IMA_KEXEC
++ depends on TCG_TPM && HAVE_IMA_KEXEC
+ default n
+ help
+ TPM PCRs are only reset on a hard reboot. In order to validate
+@@ -43,7 +45,6 @@ config IMA_KEXEC
+
+ config IMA_MEASURE_PCR_IDX
+ int
+- depends on IMA
+ range 8 14
+ default 10
+ help
+@@ -53,7 +54,7 @@ config IMA_MEASURE_PCR_IDX
+
+ config IMA_LSM_RULES
+ bool
+- depends on IMA && AUDIT && (SECURITY_SELINUX || SECURITY_SMACK || SECURITY_APPARMOR)
++ depends on AUDIT && (SECURITY_SELINUX || SECURITY_SMACK || SECURITY_APPARMOR)
+ default y
+ help
+ Disabling this option will disregard LSM based policy rules.
+@@ -61,7 +62,6 @@ config IMA_LSM_RULES
+ choice
+ prompt "Default template"
+ default IMA_NG_TEMPLATE
+- depends on IMA
+ help
+ Select the default IMA measurement template.
+
+@@ -80,14 +80,12 @@ endchoice
+
+ config IMA_DEFAULT_TEMPLATE
+ string
+- depends on IMA
+ default "ima-ng" if IMA_NG_TEMPLATE
+ default "ima-sig" if IMA_SIG_TEMPLATE
+
+ choice
+ prompt "Default integrity hash algorithm"
+ default IMA_DEFAULT_HASH_SHA1
+- depends on IMA
+ help
+ Select the default hash algorithm used for the measurement
+ list, integrity appraisal and audit log. The compiled default
+@@ -117,7 +115,6 @@ endchoice
+
+ config IMA_DEFAULT_HASH
+ string
+- depends on IMA
+ default "sha1" if IMA_DEFAULT_HASH_SHA1
+ default "sha256" if IMA_DEFAULT_HASH_SHA256
+ default "sha512" if IMA_DEFAULT_HASH_SHA512
+@@ -126,7 +123,6 @@ config IMA_DEFAULT_HASH
+
+ config IMA_WRITE_POLICY
+ bool "Enable multiple writes to the IMA policy"
+- depends on IMA
+ default n
+ help
+ IMA policy can now be updated multiple times. The new rules get
+@@ -137,7 +133,6 @@ config IMA_WRITE_POLICY
+
+ config IMA_READ_POLICY
+ bool "Enable reading back the current IMA policy"
+- depends on IMA
+ default y if IMA_WRITE_POLICY
+ default n if !IMA_WRITE_POLICY
+ help
+@@ -147,7 +142,6 @@ config IMA_READ_POLICY
+
+ config IMA_APPRAISE
+ bool "Appraise integrity measurements"
+- depends on IMA
+ default n
+ help
+ This option enables local measurement integrity appraisal.
+@@ -303,7 +297,6 @@ config IMA_APPRAISE_SIGNED_INIT
+
+ config IMA_MEASURE_ASYMMETRIC_KEYS
+ bool
+- depends on IMA
+ depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
+ default y
+
+@@ -319,3 +312,5 @@ config IMA_SECURE_AND_OR_TRUSTED_BOOT
+ help
+ This option is selected by architectures to enable secure and/or
+ trusted boot based on IMA runtime policies.
++
++endif
+--
+2.40.1
+
--- /dev/null
+From 346e026bd35b2f7ab76e1838d8234d684a761971 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 Sep 2023 11:41:19 +0100
+Subject: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
+
+From: David Howells <dhowells@redhat.com>
+
+[ Upstream commit 9d4c75800f61e5d75c1659ba201b6c0c7ead3070 ]
+
+Including the transhdrlen in length is a problem when the packet is
+partially filled (e.g. something like send(MSG_MORE) happened previously)
+when appending to an IPv4 or IPv6 packet as we don't want to repeat the
+transport header or account for it twice. This can happen under some
+circumstances, such as splicing into an L2TP socket.
+
+The symptom observed is a warning in __ip6_append_data():
+
+ WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800
+
+that occurs when MSG_SPLICE_PAGES is used to append more data to an already
+partially occupied skbuff. The warning occurs when 'copy' is larger than
+the amount of data in the message iterator. This is because the requested
+length includes the transport header length when it shouldn't. This can be
+triggered by, for example:
+
+ sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);
+ bind(sfd, ...); // ::1
+ connect(sfd, ...); // ::1 port 7
+ send(sfd, buffer, 4100, MSG_MORE);
+ sendfile(sfd, dfd, NULL, 1024);
+
+Fix this by only adding transhdrlen into the length if the write queue is
+empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.
+
+l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds
+the UDP packet itself.
+
+Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6")
+Reported-by: syzbot+62cbf263225ae13ff153@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/r/0000000000001c12b30605378ce8@google.com/
+Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Eric Dumazet <edumazet@google.com>
+cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
+cc: "David S. Miller" <davem@davemloft.net>
+cc: David Ahern <dsahern@kernel.org>
+cc: Paolo Abeni <pabeni@redhat.com>
+cc: Jakub Kicinski <kuba@kernel.org>
+cc: netdev@vger.kernel.org
+cc: bpf@vger.kernel.org
+cc: syzkaller-bugs@googlegroups.com
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/l2tp/l2tp_ip6.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
+index 382124d6f7647..9746c624a5503 100644
+--- a/net/l2tp/l2tp_ip6.c
++++ b/net/l2tp/l2tp_ip6.c
+@@ -508,7 +508,6 @@ static int l2tp_ip6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
+ */
+ if (len > INT_MAX - transhdrlen)
+ return -EMSGSIZE;
+- ulen = len + transhdrlen;
+
+ /* Mirror BSD error message compatibility */
+ if (msg->msg_flags & MSG_OOB)
+@@ -629,6 +628,7 @@ static int l2tp_ip6_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
+
+ back_from_confirm:
+ lock_sock(sk);
++ ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
+ err = ip6_append_data(sk, ip_generic_getfrag, msg,
+ ulen, transhdrlen, &ipc6,
+ &fl6, (struct rt6_info *)dst,
+--
+2.40.1
+
--- /dev/null
+From f98441bc70953a1be5e4fadea249dabd32b30aee Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 28 Sep 2023 17:28:07 -0300
+Subject: modpost: add missing else to the "of" check
+
+From: Mauricio Faria de Oliveira <mfo@canonical.com>
+
+[ Upstream commit cbc3d00cf88fda95dbcafee3b38655b7a8f2650a ]
+
+Without this 'else' statement, an "usb" name goes into two handlers:
+the first/previous 'if' statement _AND_ the for-loop over 'devtable',
+but the latter is useless as it has no 'usb' device_id entry anyway.
+
+Tested with allmodconfig before/after patch; no changes to *.mod.c:
+
+ git checkout v6.6-rc3
+ make -j$(nproc) allmodconfig
+ make -j$(nproc) olddefconfig
+
+ make -j$(nproc)
+ find . -name '*.mod.c' | cpio -pd /tmp/before
+
+ # apply patch
+
+ make -j$(nproc)
+ find . -name '*.mod.c' | cpio -pd /tmp/after
+
+ diff -r /tmp/before/ /tmp/after/
+ # no difference
+
+Fixes: acbef7b76629 ("modpost: fix module autoloading for OF devices with generic compatible property")
+Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/mod/file2alias.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
+index 2417dd1dee33c..da4df53ee6955 100644
+--- a/scripts/mod/file2alias.c
++++ b/scripts/mod/file2alias.c
+@@ -1490,7 +1490,7 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
+ /* First handle the "special" cases */
+ if (sym_is(name, namelen, "usb"))
+ do_usb_table(symval, sym->st_size, mod);
+- if (sym_is(name, namelen, "of"))
++ else if (sym_is(name, namelen, "of"))
+ do_of_table(symval, sym->st_size, mod);
+ else if (sym_is(name, namelen, "pnp"))
+ do_pnp_device_entry(symval, sym->st_size, mod);
+--
+2.40.1
+
--- /dev/null
+From a7a39abdaea12dcc6f6791d879d3d41324f4a121 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 22 Sep 2023 09:47:41 -0300
+Subject: net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent
+
+From: Fabio Estevam <festevam@denx.de>
+
+[ Upstream commit 6ccf50d4d4741e064ba35511a95402c63bbe21a8 ]
+
+Since commit 23d775f12dcd ("net: dsa: mv88e6xxx: Wait for EEPROM done
+before HW reset") the following error is seen on a imx8mn board with
+a 88E6320 switch:
+
+mv88e6085 30be0000.ethernet-1:00: Timeout waiting for EEPROM done
+
+This board does not have an EEPROM attached to the switch though.
+
+This problem is well explained by Andrew Lunn:
+
+"If there is an EEPROM, and the EEPROM contains a lot of data, it could
+be that when we perform a hardware reset towards the end of probe, it
+interrupts an I2C bus transaction, leaving the I2C bus in a bad state,
+and future reads of the EEPROM do not work.
+
+The work around for this was to poll the EEInt status and wait for it
+to go true before performing the hardware reset.
+
+However, we have discovered that for some boards which do not have an
+EEPROM, EEInt never indicates complete. As a result,
+mv88e6xxx_g1_wait_eeprom_done() spins for a second and then prints a
+warning.
+
+We probably need a different solution than calling
+mv88e6xxx_g1_wait_eeprom_done(). The datasheet for 6352 documents the
+EEPROM Command register:
+
+bit 15 is:
+
+ EEPROM Unit Busy. This bit must be set to a one to start an EEPROM
+ operation (see EEOp below). Only one EEPROM operation can be
+ executing at one time so this bit must be zero before setting it to
+ a one. When the requested EEPROM operation completes this bit will
+ automatically be cleared to a zero. The transition of this bit from
+ a one to a zero can be used to generate an interrupt (the EEInt in
+ Global 1, offset 0x00).
+
+and more interesting is bit 11:
+
+ Register Loader Running. This bit is set to one whenever the
+ register loader is busy executing instructions contained in the
+ EEPROM."
+
+Change to using mv88e6xxx_g2_eeprom_wait() to fix the timeout error
+when the EEPROM chip is not present.
+
+Fixes: 23d775f12dcd ("net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset")
+Suggested-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Fabio Estevam <festevam@denx.de>
+Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/mv88e6xxx/chip.c | 6 ++++--
+ drivers/net/dsa/mv88e6xxx/global1.c | 31 -----------------------------
+ drivers/net/dsa/mv88e6xxx/global1.h | 1 -
+ drivers/net/dsa/mv88e6xxx/global2.c | 2 +-
+ drivers/net/dsa/mv88e6xxx/global2.h | 1 +
+ 5 files changed, 6 insertions(+), 35 deletions(-)
+
+diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
+index 177151298d72a..53fbef9f4ce54 100644
+--- a/drivers/net/dsa/mv88e6xxx/chip.c
++++ b/drivers/net/dsa/mv88e6xxx/chip.c
+@@ -2316,14 +2316,16 @@ static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip)
+ * from the wrong location resulting in the switch booting
+ * to wrong mode and inoperable.
+ */
+- mv88e6xxx_g1_wait_eeprom_done(chip);
++ if (chip->info->ops->get_eeprom)
++ mv88e6xxx_g2_eeprom_wait(chip);
+
+ gpiod_set_value_cansleep(gpiod, 1);
+ usleep_range(10000, 20000);
+ gpiod_set_value_cansleep(gpiod, 0);
+ usleep_range(10000, 20000);
+
+- mv88e6xxx_g1_wait_eeprom_done(chip);
++ if (chip->info->ops->get_eeprom)
++ mv88e6xxx_g2_eeprom_wait(chip);
+ }
+ }
+
+diff --git a/drivers/net/dsa/mv88e6xxx/global1.c b/drivers/net/dsa/mv88e6xxx/global1.c
+index 9936ae69e5ee4..ff43d9c9a7ebf 100644
+--- a/drivers/net/dsa/mv88e6xxx/global1.c
++++ b/drivers/net/dsa/mv88e6xxx/global1.c
+@@ -75,37 +75,6 @@ static int mv88e6xxx_g1_wait_init_ready(struct mv88e6xxx_chip *chip)
+ return mv88e6xxx_g1_wait_bit(chip, MV88E6XXX_G1_STS, bit, 1);
+ }
+
+-void mv88e6xxx_g1_wait_eeprom_done(struct mv88e6xxx_chip *chip)
+-{
+- const unsigned long timeout = jiffies + 1 * HZ;
+- u16 val;
+- int err;
+-
+- /* Wait up to 1 second for the switch to finish reading the
+- * EEPROM.
+- */
+- while (time_before(jiffies, timeout)) {
+- err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_STS, &val);
+- if (err) {
+- dev_err(chip->dev, "Error reading status");
+- return;
+- }
+-
+- /* If the switch is still resetting, it may not
+- * respond on the bus, and so MDIO read returns
+- * 0xffff. Differentiate between that, and waiting for
+- * the EEPROM to be done by bit 0 being set.
+- */
+- if (val != 0xffff &&
+- val & BIT(MV88E6XXX_G1_STS_IRQ_EEPROM_DONE))
+- return;
+-
+- usleep_range(1000, 2000);
+- }
+-
+- dev_err(chip->dev, "Timeout waiting for EEPROM done");
+-}
+-
+ /* Offset 0x01: Switch MAC Address Register Bytes 0 & 1
+ * Offset 0x02: Switch MAC Address Register Bytes 2 & 3
+ * Offset 0x03: Switch MAC Address Register Bytes 4 & 5
+diff --git a/drivers/net/dsa/mv88e6xxx/global1.h b/drivers/net/dsa/mv88e6xxx/global1.h
+index e05abe61fa114..1e3546f8b0727 100644
+--- a/drivers/net/dsa/mv88e6xxx/global1.h
++++ b/drivers/net/dsa/mv88e6xxx/global1.h
+@@ -278,7 +278,6 @@ int mv88e6xxx_g1_set_switch_mac(struct mv88e6xxx_chip *chip, u8 *addr);
+ int mv88e6185_g1_reset(struct mv88e6xxx_chip *chip);
+ int mv88e6352_g1_reset(struct mv88e6xxx_chip *chip);
+ int mv88e6250_g1_reset(struct mv88e6xxx_chip *chip);
+-void mv88e6xxx_g1_wait_eeprom_done(struct mv88e6xxx_chip *chip);
+
+ int mv88e6185_g1_ppu_enable(struct mv88e6xxx_chip *chip);
+ int mv88e6185_g1_ppu_disable(struct mv88e6xxx_chip *chip);
+diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
+index 75b227d0f73b4..8607b2445e1a2 100644
+--- a/drivers/net/dsa/mv88e6xxx/global2.c
++++ b/drivers/net/dsa/mv88e6xxx/global2.c
+@@ -323,7 +323,7 @@ int mv88e6xxx_g2_pot_clear(struct mv88e6xxx_chip *chip)
+ * Offset 0x15: EEPROM Addr (for 8-bit data access)
+ */
+
+-static int mv88e6xxx_g2_eeprom_wait(struct mv88e6xxx_chip *chip)
++int mv88e6xxx_g2_eeprom_wait(struct mv88e6xxx_chip *chip)
+ {
+ int bit = __bf_shf(MV88E6XXX_G2_EEPROM_CMD_BUSY);
+ int err;
+diff --git a/drivers/net/dsa/mv88e6xxx/global2.h b/drivers/net/dsa/mv88e6xxx/global2.h
+index 1f42ee656816b..de63e3f08e5cd 100644
+--- a/drivers/net/dsa/mv88e6xxx/global2.h
++++ b/drivers/net/dsa/mv88e6xxx/global2.h
+@@ -349,6 +349,7 @@ int mv88e6xxx_g2_trunk_clear(struct mv88e6xxx_chip *chip);
+
+ int mv88e6xxx_g2_device_mapping_write(struct mv88e6xxx_chip *chip, int target,
+ int port);
++int mv88e6xxx_g2_eeprom_wait(struct mv88e6xxx_chip *chip);
+
+ extern const struct mv88e6xxx_irq_ops mv88e6097_watchdog_ops;
+ extern const struct mv88e6xxx_irq_ops mv88e6250_watchdog_ops;
+--
+2.40.1
+
--- /dev/null
+From 11a4ac71f29acbacac9e19dad1ba8168b5d632bb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 26 Sep 2023 17:04:43 +0300
+Subject: net: ethernet: ti: am65-cpsw: Fix error code in
+ am65_cpsw_nuss_init_tx_chns()
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+[ Upstream commit 37d4f55567982e445f86dc0ff4ecfa72921abfe8 ]
+
+This accidentally returns success, but it should return a negative error
+code.
+
+Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Roger Quadros <rogerq@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/ti/am65-cpsw-nuss.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+index e4af1f506b833..d103244313542 100644
+--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
++++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+@@ -1496,6 +1496,7 @@ static int am65_cpsw_nuss_init_tx_chns(struct am65_cpsw_common *common)
+ if (tx_chn->irq <= 0) {
+ dev_err(dev, "Failed to get tx dma irq %d\n",
+ tx_chn->irq);
++ ret = tx_chn->irq ?: -ENXIO;
+ goto err;
+ }
+
+--
+2.40.1
+
--- /dev/null
+From 6af58a7a65dc43f9612c8da052ebb124455b9fdb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 21 Sep 2023 08:46:26 +0000
+Subject: net: fix possible store tearing in neigh_periodic_work()
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 25563b581ba3a1f263a00e8c9a97f5e7363be6fd ]
+
+While looking at a related syzbot report involving neigh_periodic_work(),
+I found that I forgot to add an annotation when deleting an
+RCU protected item from a list.
+
+Readers use rcu_deference(*np), we need to use either
+rcu_assign_pointer() or WRITE_ONCE() on writer side
+to prevent store tearing.
+
+I use rcu_assign_pointer() to have lockdep support,
+this was the choice made in neigh_flush_dev().
+
+Fixes: 767e97e1e0db ("neigh: RCU conversion of struct neighbour")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/neighbour.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/core/neighbour.c b/net/core/neighbour.c
+index 3b642c412cf32..15267428c4f83 100644
+--- a/net/core/neighbour.c
++++ b/net/core/neighbour.c
+@@ -935,7 +935,9 @@ static void neigh_periodic_work(struct work_struct *work)
+ (state == NUD_FAILED ||
+ !time_in_range_open(jiffies, n->used,
+ n->used + NEIGH_VAR(n->parms, GC_STALETIME)))) {
+- *np = n->next;
++ rcu_assign_pointer(*np,
++ rcu_dereference_protected(n->next,
++ lockdep_is_held(&tbl->lock)));
+ neigh_mark_dead(n);
+ write_unlock(&n->lock);
+ neigh_cleanup_and_release(n);
+--
+2.40.1
+
--- /dev/null
+From e4ee3654677648b7d7adb14a67c056b7507a0cdf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 8 Sep 2023 19:58:53 -0400
+Subject: net: nfc: llcp: Add lock when modifying device list
+
+From: Jeremy Cline <jeremy@jcline.org>
+
+[ Upstream commit dfc7f7a988dad34c3bf4c053124fb26aa6c5f916 ]
+
+The device list needs its associated lock held when modifying it, or the
+list could become corrupted, as syzbot discovered.
+
+Reported-and-tested-by: syzbot+c1d0a03d305972dbbe14@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=c1d0a03d305972dbbe14
+Signed-off-by: Jeremy Cline <jeremy@jcline.org>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Fixes: 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by nfc_llcp_find_local")
+Link: https://lore.kernel.org/r/20230908235853.1319596-1-jeremy@jcline.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/nfc/llcp_core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
+index ddfd159f64e13..b1107570eaee8 100644
+--- a/net/nfc/llcp_core.c
++++ b/net/nfc/llcp_core.c
+@@ -1646,7 +1646,9 @@ int nfc_llcp_register_device(struct nfc_dev *ndev)
+ timer_setup(&local->sdreq_timer, nfc_llcp_sdreq_timer, 0);
+ INIT_WORK(&local->sdreq_timeout_work, nfc_llcp_sdreq_timeout_work);
+
++ spin_lock(&llcp_devices_lock);
+ list_add(&local->list, &llcp_devices);
++ spin_unlock(&llcp_devices_lock);
+
+ return 0;
+ }
+--
+2.40.1
+
--- /dev/null
+From 724552de45d082e416bf5480c3617e69e6d1220b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Sep 2023 13:57:49 -0400
+Subject: net: stmmac: dwmac-stm32: fix resume on STM32 MCU
+
+From: Ben Wolsieffer <ben.wolsieffer@hefring.com>
+
+[ Upstream commit 6f195d6b0da3b689922ba9e302af2f49592fa9fc ]
+
+The STM32MP1 keeps clk_rx enabled during suspend, and therefore the
+driver does not enable the clock in stm32_dwmac_init() if the device was
+suspended. The problem is that this same code runs on STM32 MCUs, which
+do disable clk_rx during suspend, causing the clock to never be
+re-enabled on resume.
+
+This patch adds a variant flag to indicate that clk_rx remains enabled
+during suspend, and uses this to decide whether to enable the clock in
+stm32_dwmac_init() if the device was suspended.
+
+This approach fixes this specific bug with limited opportunity for
+unintended side-effects, but I have a follow up patch that will refactor
+the clock configuration and hopefully make it less error prone.
+
+Fixes: 6528e02cc9ff ("net: ethernet: stmmac: add adaptation for stm32mp157c.")
+Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Link: https://lore.kernel.org/r/20230927175749.1419774-1-ben.wolsieffer@hefring.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+index 5d4df4c5254ed..6623f5a079275 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+@@ -105,6 +105,7 @@ struct stm32_ops {
+ int (*parse_data)(struct stm32_dwmac *dwmac,
+ struct device *dev);
+ u32 syscfg_eth_mask;
++ bool clk_rx_enable_in_suspend;
+ };
+
+ static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
+@@ -122,7 +123,8 @@ static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
+ if (ret)
+ return ret;
+
+- if (!dwmac->dev->power.is_suspended) {
++ if (!dwmac->ops->clk_rx_enable_in_suspend ||
++ !dwmac->dev->power.is_suspended) {
+ ret = clk_prepare_enable(dwmac->clk_rx);
+ if (ret) {
+ clk_disable_unprepare(dwmac->clk_tx);
+@@ -515,7 +517,8 @@ static struct stm32_ops stm32mp1_dwmac_data = {
+ .suspend = stm32mp1_suspend,
+ .resume = stm32mp1_resume,
+ .parse_data = stm32mp1_parse_data,
+- .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK
++ .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK,
++ .clk_rx_enable_in_suspend = true
+ };
+
+ static const struct of_device_id stm32_dwmac_match[] = {
+--
+2.40.1
+
--- /dev/null
+From 75aad3907778f40f47fc94fb80382f36a0c5f436 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 24 Sep 2023 02:35:49 +0900
+Subject: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
+
+From: Shigeru Yoshida <syoshida@redhat.com>
+
+[ Upstream commit e9c65989920f7c28775ec4e0c11b483910fb67b8 ]
+
+syzbot reported the following uninit-value access issue:
+
+=====================================================
+BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
+BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
+CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Workqueue: usb_hub_wq hub_event
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0x21c/0x280 lib/dump_stack.c:118
+ kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
+ __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
+ smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
+ smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
+ usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
+ usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
+ really_probe+0xf20/0x20b0 drivers/base/dd.c:529
+ driver_probe_device+0x293/0x390 drivers/base/dd.c:701
+ __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
+ bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
+ __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
+ device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
+ bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
+ device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
+ usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
+ usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
+ usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
+ really_probe+0xf20/0x20b0 drivers/base/dd.c:529
+ driver_probe_device+0x293/0x390 drivers/base/dd.c:701
+ __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
+ bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
+ __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
+ device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
+ bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
+ device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
+ usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
+ hub_port_connect drivers/usb/core/hub.c:5208 [inline]
+ hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
+ port_event drivers/usb/core/hub.c:5494 [inline]
+ hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
+ process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
+ worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
+ kthread+0x551/0x590 kernel/kthread.c:292
+ ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
+
+Local variable ----buf.i87@smsc75xx_bind created at:
+ __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
+ smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
+ smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
+ __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
+ smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
+ smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
+
+This issue is caused because usbnet_read_cmd() reads less bytes than requested
+(zero byte in the reproducer). In this case, 'buf' is not properly filled.
+
+This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
+less bytes than requested.
+
+Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
+Reported-and-tested-by: syzbot+6966546b78d050bb0b5d@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=6966546b78d050bb0b5d
+Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/20230923173549.3284502-1-syoshida@redhat.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/smsc75xx.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
+index fb1389bd09392..6310841aeac72 100644
+--- a/drivers/net/usb/smsc75xx.c
++++ b/drivers/net/usb/smsc75xx.c
+@@ -90,7 +90,9 @@ static int __must_check __smsc75xx_read_reg(struct usbnet *dev, u32 index,
+ ret = fn(dev, USB_VENDOR_REQUEST_READ_REGISTER, USB_DIR_IN
+ | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ 0, index, &buf, 4);
+- if (unlikely(ret < 0)) {
++ if (unlikely(ret < 4)) {
++ ret = ret < 0 ? ret : -ENODATA;
++
+ netdev_warn(dev->net, "Failed to read reg index 0x%08x: %d\n",
+ index, ret);
+ return ret;
+--
+2.40.1
+
--- /dev/null
+From 12900c2587ff2dbf0378c811a53714b3c5cca30c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 3 Oct 2023 13:17:53 -0400
+Subject: netfilter: handle the connecting collision properly in
+ nf_conntrack_proto_sctp
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 8e56b063c86569e51eed1c5681ce6361fa97fc7a ]
+
+In Scenario A and B below, as the delayed INIT_ACK always changes the peer
+vtag, SCTP ct with the incorrect vtag may cause packet loss.
+
+Scenario A: INIT_ACK is delayed until the peer receives its own INIT_ACK
+
+ 192.168.1.2 > 192.168.1.1: [INIT] [init tag: 1328086772]
+ 192.168.1.1 > 192.168.1.2: [INIT] [init tag: 1414468151]
+ 192.168.1.2 > 192.168.1.1: [INIT ACK] [init tag: 1328086772]
+ 192.168.1.1 > 192.168.1.2: [INIT ACK] [init tag: 1650211246] *
+ 192.168.1.2 > 192.168.1.1: [COOKIE ECHO]
+ 192.168.1.1 > 192.168.1.2: [COOKIE ECHO]
+ 192.168.1.2 > 192.168.1.1: [COOKIE ACK]
+
+Scenario B: INIT_ACK is delayed until the peer completes its own handshake
+
+ 192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
+ 192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO]
+ 192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021] *
+
+This patch fixes it as below:
+
+In SCTP_CID_INIT processing:
+- clear ct->proto.sctp.init[!dir] if ct->proto.sctp.init[dir] &&
+ ct->proto.sctp.init[!dir]. (Scenario E)
+- set ct->proto.sctp.init[dir].
+
+In SCTP_CID_INIT_ACK processing:
+- drop it if !ct->proto.sctp.init[!dir] && ct->proto.sctp.vtag[!dir] &&
+ ct->proto.sctp.vtag[!dir] != ih->init_tag. (Scenario B, Scenario C)
+- drop it if ct->proto.sctp.init[dir] && ct->proto.sctp.init[!dir] &&
+ ct->proto.sctp.vtag[!dir] != ih->init_tag. (Scenario A)
+
+In SCTP_CID_COOKIE_ACK processing:
+- clear ct->proto.sctp.init[dir] and ct->proto.sctp.init[!dir].
+ (Scenario D)
+
+Also, it's important to allow the ct state to move forward with cookie_echo
+and cookie_ack from the opposite dir for the collision scenarios.
+
+There are also other Scenarios where it should allow the packet through,
+addressed by the processing above:
+
+Scenario C: new CT is created by INIT_ACK.
+
+Scenario D: start INIT on the existing ESTABLISHED ct.
+
+Scenario E: start INIT after the old collision on the existing ESTABLISHED
+ct.
+
+ 192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
+ (both side are stopped, then start new connection again in hours)
+ 192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 242308742]
+
+Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/netfilter/nf_conntrack_sctp.h | 1 +
+ net/netfilter/nf_conntrack_proto_sctp.c | 43 ++++++++++++++++-----
+ 2 files changed, 34 insertions(+), 10 deletions(-)
+
+diff --git a/include/linux/netfilter/nf_conntrack_sctp.h b/include/linux/netfilter/nf_conntrack_sctp.h
+index 625f491b95de8..fb31312825ae5 100644
+--- a/include/linux/netfilter/nf_conntrack_sctp.h
++++ b/include/linux/netfilter/nf_conntrack_sctp.h
+@@ -9,6 +9,7 @@ struct ip_ct_sctp {
+ enum sctp_conntrack state;
+
+ __be32 vtag[IP_CT_DIR_MAX];
++ u8 init[IP_CT_DIR_MAX];
+ u8 last_dir;
+ u8 flags;
+ };
+diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
+index 21cbaf6dac331..e7545bcca805e 100644
+--- a/net/netfilter/nf_conntrack_proto_sctp.c
++++ b/net/netfilter/nf_conntrack_proto_sctp.c
+@@ -112,7 +112,7 @@ static const u8 sctp_conntracks[2][11][SCTP_CONNTRACK_MAX] = {
+ /* shutdown_ack */ {sSA, sCL, sCW, sCE, sES, sSA, sSA, sSA, sSA},
+ /* error */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA, sCL},/* Can't have Stale cookie*/
+ /* cookie_echo */ {sCL, sCL, sCE, sCE, sES, sSS, sSR, sSA, sCL},/* 5.2.4 - Big TODO */
+-/* cookie_ack */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA, sCL},/* Can't come in orig dir */
++/* cookie_ack */ {sCL, sCL, sCW, sES, sES, sSS, sSR, sSA, sCL},/* Can't come in orig dir */
+ /* shutdown_comp*/ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sCL, sCL},
+ /* heartbeat */ {sHS, sCL, sCW, sCE, sES, sSS, sSR, sSA, sHS},
+ /* heartbeat_ack*/ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA, sHS},
+@@ -126,7 +126,7 @@ static const u8 sctp_conntracks[2][11][SCTP_CONNTRACK_MAX] = {
+ /* shutdown */ {sIV, sCL, sCW, sCE, sSR, sSS, sSR, sSA, sIV},
+ /* shutdown_ack */ {sIV, sCL, sCW, sCE, sES, sSA, sSA, sSA, sIV},
+ /* error */ {sIV, sCL, sCW, sCL, sES, sSS, sSR, sSA, sIV},
+-/* cookie_echo */ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sSA, sIV},/* Can't come in reply dir */
++/* cookie_echo */ {sIV, sCL, sCE, sCE, sES, sSS, sSR, sSA, sIV},/* Can't come in reply dir */
+ /* cookie_ack */ {sIV, sCL, sCW, sES, sES, sSS, sSR, sSA, sIV},
+ /* shutdown_comp*/ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sCL, sIV},
+ /* heartbeat */ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sSA, sHS},
+@@ -426,6 +426,9 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
+ /* (D) vtag must be same as init_vtag as found in INIT_ACK */
+ if (sh->vtag != ct->proto.sctp.vtag[dir])
+ goto out_unlock;
++ } else if (sch->type == SCTP_CID_COOKIE_ACK) {
++ ct->proto.sctp.init[dir] = 0;
++ ct->proto.sctp.init[!dir] = 0;
+ } else if (sch->type == SCTP_CID_HEARTBEAT) {
+ if (ct->proto.sctp.vtag[dir] == 0) {
+ pr_debug("Setting %d vtag %x for dir %d\n", sch->type, sh->vtag, dir);
+@@ -474,16 +477,18 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
+ }
+
+ /* If it is an INIT or an INIT ACK note down the vtag */
+- if (sch->type == SCTP_CID_INIT ||
+- sch->type == SCTP_CID_INIT_ACK) {
+- struct sctp_inithdr _inithdr, *ih;
++ if (sch->type == SCTP_CID_INIT) {
++ struct sctp_inithdr _ih, *ih;
+
+- ih = skb_header_pointer(skb, offset + sizeof(_sch),
+- sizeof(_inithdr), &_inithdr);
+- if (ih == NULL)
++ ih = skb_header_pointer(skb, offset + sizeof(_sch), sizeof(*ih), &_ih);
++ if (!ih)
+ goto out_unlock;
+- pr_debug("Setting vtag %x for dir %d\n",
+- ih->init_tag, !dir);
++
++ if (ct->proto.sctp.init[dir] && ct->proto.sctp.init[!dir])
++ ct->proto.sctp.init[!dir] = 0;
++ ct->proto.sctp.init[dir] = 1;
++
++ pr_debug("Setting vtag %x for dir %d\n", ih->init_tag, !dir);
+ ct->proto.sctp.vtag[!dir] = ih->init_tag;
+
+ /* don't renew timeout on init retransmit so
+@@ -494,6 +499,24 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
+ old_state == SCTP_CONNTRACK_CLOSED &&
+ nf_ct_is_confirmed(ct))
+ ignore = true;
++ } else if (sch->type == SCTP_CID_INIT_ACK) {
++ struct sctp_inithdr _ih, *ih;
++ __be32 vtag;
++
++ ih = skb_header_pointer(skb, offset + sizeof(_sch), sizeof(*ih), &_ih);
++ if (!ih)
++ goto out_unlock;
++
++ vtag = ct->proto.sctp.vtag[!dir];
++ if (!ct->proto.sctp.init[!dir] && vtag && vtag != ih->init_tag)
++ goto out_unlock;
++ /* collision */
++ if (ct->proto.sctp.init[dir] && ct->proto.sctp.init[!dir] &&
++ vtag != ih->init_tag)
++ goto out_unlock;
++
++ pr_debug("Setting vtag %x for dir %d\n", ih->init_tag, !dir);
++ ct->proto.sctp.vtag[!dir] = ih->init_tag;
+ }
+
+ ct->proto.sctp.state = new_state;
+--
+2.40.1
+
--- /dev/null
+From aa3916160fb1fd6378f71ac5594d9ee3cbbdb2c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 28 Sep 2023 15:12:44 +0200
+Subject: netfilter: nf_tables: nft_set_rbtree: fix spurious insertion failure
+
+From: Florian Westphal <fw@strlen.de>
+
+[ Upstream commit 087388278e0f301f4c61ddffb1911d3a180f84b8 ]
+
+nft_rbtree_gc_elem() walks back and removes the end interval element that
+comes before the expired element.
+
+There is a small chance that we've cached this element as 'rbe_ge'.
+If this happens, we hold and test a pointer that has been queued for
+freeing.
+
+It also causes spurious insertion failures:
+
+$ cat test-testcases-sets-0044interval_overlap_0.1/testout.log
+Error: Could not process rule: File exists
+add element t s { 0 - 2 }
+ ^^^^^^
+Failed to insert 0 - 2 given:
+table ip t {
+ set s {
+ type inet_service
+ flags interval,timeout
+ timeout 2s
+ gc-interval 2s
+ }
+}
+
+The set (rbtree) is empty. The 'failure' doesn't happen on next attempt.
+
+Reason is that when we try to insert, the tree may hold an expired
+element that collides with the range we're adding.
+While we do evict/erase this element, we can trip over this check:
+
+if (rbe_ge && nft_rbtree_interval_end(rbe_ge) && nft_rbtree_interval_end(new))
+ return -ENOTEMPTY;
+
+rbe_ge was erased by the synchronous gc, we should not have done this
+check. Next attempt won't find it, so retry results in successful
+insertion.
+
+Restart in-kernel to avoid such spurious errors.
+
+Such restart are rare, unless userspace intentionally adds very large
+numbers of elements with very short timeouts while setting a huge
+gc interval.
+
+Even in this case, this cannot loop forever, on each retry an existing
+element has been removed.
+
+As the caller is holding the transaction mutex, its impossible
+for a second entity to add more expiring elements to the tree.
+
+After this it also becomes feasible to remove the async gc worker
+and perform all garbage collection from the commit path.
+
+Fixes: c9e6978e2725 ("netfilter: nft_set_rbtree: Switch to node list walk for overlap detection")
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nft_set_rbtree.c | 46 +++++++++++++++++++++-------------
+ 1 file changed, 29 insertions(+), 17 deletions(-)
+
+diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
+index cc32e19b4041a..17abf17b673e2 100644
+--- a/net/netfilter/nft_set_rbtree.c
++++ b/net/netfilter/nft_set_rbtree.c
+@@ -235,10 +235,9 @@ static void nft_rbtree_gc_remove(struct net *net, struct nft_set *set,
+ rb_erase(&rbe->node, &priv->root);
+ }
+
+-static int nft_rbtree_gc_elem(const struct nft_set *__set,
+- struct nft_rbtree *priv,
+- struct nft_rbtree_elem *rbe,
+- u8 genmask)
++static const struct nft_rbtree_elem *
++nft_rbtree_gc_elem(const struct nft_set *__set, struct nft_rbtree *priv,
++ struct nft_rbtree_elem *rbe, u8 genmask)
+ {
+ struct nft_set *set = (struct nft_set *)__set;
+ struct rb_node *prev = rb_prev(&rbe->node);
+@@ -248,7 +247,7 @@ static int nft_rbtree_gc_elem(const struct nft_set *__set,
+
+ gc = nft_trans_gc_alloc(set, 0, GFP_ATOMIC);
+ if (!gc)
+- return -ENOMEM;
++ return ERR_PTR(-ENOMEM);
+
+ /* search for end interval coming before this element.
+ * end intervals don't carry a timeout extension, they
+@@ -263,6 +262,7 @@ static int nft_rbtree_gc_elem(const struct nft_set *__set,
+ prev = rb_prev(prev);
+ }
+
++ rbe_prev = NULL;
+ if (prev) {
+ rbe_prev = rb_entry(prev, struct nft_rbtree_elem, node);
+ nft_rbtree_gc_remove(net, set, priv, rbe_prev);
+@@ -274,7 +274,7 @@ static int nft_rbtree_gc_elem(const struct nft_set *__set,
+ */
+ gc = nft_trans_gc_queue_sync(gc, GFP_ATOMIC);
+ if (WARN_ON_ONCE(!gc))
+- return -ENOMEM;
++ return ERR_PTR(-ENOMEM);
+
+ nft_trans_gc_elem_add(gc, rbe_prev);
+ }
+@@ -282,13 +282,13 @@ static int nft_rbtree_gc_elem(const struct nft_set *__set,
+ nft_rbtree_gc_remove(net, set, priv, rbe);
+ gc = nft_trans_gc_queue_sync(gc, GFP_ATOMIC);
+ if (WARN_ON_ONCE(!gc))
+- return -ENOMEM;
++ return ERR_PTR(-ENOMEM);
+
+ nft_trans_gc_elem_add(gc, rbe);
+
+ nft_trans_gc_queue_sync_done(gc);
+
+- return 0;
++ return rbe_prev;
+ }
+
+ static bool nft_rbtree_update_first(const struct nft_set *set,
+@@ -316,7 +316,7 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
+ struct nft_rbtree *priv = nft_set_priv(set);
+ u8 cur_genmask = nft_genmask_cur(net);
+ u8 genmask = nft_genmask_next(net);
+- int d, err;
++ int d;
+
+ /* Descend the tree to search for an existing element greater than the
+ * key value to insert that is greater than the new element. This is the
+@@ -365,9 +365,14 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
+ */
+ if (nft_set_elem_expired(&rbe->ext) &&
+ nft_set_elem_active(&rbe->ext, cur_genmask)) {
+- err = nft_rbtree_gc_elem(set, priv, rbe, genmask);
+- if (err < 0)
+- return err;
++ const struct nft_rbtree_elem *removed_end;
++
++ removed_end = nft_rbtree_gc_elem(set, priv, rbe, genmask);
++ if (IS_ERR(removed_end))
++ return PTR_ERR(removed_end);
++
++ if (removed_end == rbe_le || removed_end == rbe_ge)
++ return -EAGAIN;
+
+ continue;
+ }
+@@ -488,11 +493,18 @@ static int nft_rbtree_insert(const struct net *net, const struct nft_set *set,
+ struct nft_rbtree_elem *rbe = elem->priv;
+ int err;
+
+- write_lock_bh(&priv->lock);
+- write_seqcount_begin(&priv->count);
+- err = __nft_rbtree_insert(net, set, rbe, ext);
+- write_seqcount_end(&priv->count);
+- write_unlock_bh(&priv->lock);
++ do {
++ if (fatal_signal_pending(current))
++ return -EINTR;
++
++ cond_resched();
++
++ write_lock_bh(&priv->lock);
++ write_seqcount_begin(&priv->count);
++ err = __nft_rbtree_insert(net, set, rbe, ext);
++ write_seqcount_end(&priv->count);
++ write_unlock_bh(&priv->lock);
++ } while (err == -EAGAIN);
+
+ return err;
+ }
+--
+2.40.1
+
--- /dev/null
+From 49cf37cae1edb92aa82316019e03e47f6fe6772b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 17 Sep 2023 19:05:50 -0400
+Subject: NFSv4: Fix a nfs4_state_manager() race
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+[ Upstream commit ed1cc05aa1f7fe8197d300e914afc28ab9818f89 ]
+
+If the NFS4CLNT_RUN_MANAGER flag got set just before we cleared
+NFS4CLNT_MANAGER_RUNNING, then we might have won the race against
+nfs4_schedule_state_manager(), and are responsible for handling the
+recovery situation.
+
+Fixes: aeabb3c96186 ("NFSv4: Fix a NFSv4 state manager deadlock")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4state.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
+index 10946b24c66f9..afb617a4a7e42 100644
+--- a/fs/nfs/nfs4state.c
++++ b/fs/nfs/nfs4state.c
+@@ -2690,6 +2690,13 @@ static void nfs4_state_manager(struct nfs_client *clp)
+ nfs4_end_drain_session(clp);
+ nfs4_clear_state_manager_bit(clp);
+
++ if (test_bit(NFS4CLNT_RUN_MANAGER, &clp->cl_state) &&
++ !test_and_set_bit(NFS4CLNT_MANAGER_RUNNING,
++ &clp->cl_state)) {
++ memflags = memalloc_nofs_save();
++ continue;
++ }
++
+ if (!test_and_set_bit(NFS4CLNT_RECALL_RUNNING, &clp->cl_state)) {
+ if (test_and_clear_bit(NFS4CLNT_DELEGRETURN, &clp->cl_state)) {
+ nfs_client_return_marked_delegations(clp);
+--
+2.40.1
+
--- /dev/null
+From 9878ad967443a12f3801ce464df82e9c8b3e7d7c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 22 Sep 2023 16:37:11 +0100
+Subject: regmap: rbtree: Fix wrong register marked as in-cache when creating
+ new node
+
+From: Richard Fitzgerald <rf@opensource.cirrus.com>
+
+[ Upstream commit 7a795ac8d49e2433e1b97caf5e99129daf8e1b08 ]
+
+When regcache_rbtree_write() creates a new rbtree_node it was passing the
+wrong bit number to regcache_rbtree_set_register(). The bit number is the
+offset __in number of registers__, but in the case of creating a new block
+regcache_rbtree_write() was not dividing by the address stride to get the
+number of registers.
+
+Fix this by dividing by map->reg_stride.
+Compare with regcache_rbtree_read() where the bit is checked.
+
+This bug meant that the wrong register was marked as present. The register
+that was written to the cache could not be read from the cache because it
+was not marked as cached. But a nearby register could be marked as having
+a cached value even if it was never written to the cache.
+
+Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
+Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node")
+Link: https://lore.kernel.org/r/20230922153711.28103-1-rf@opensource.cirrus.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/base/regmap/regcache-rbtree.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/base/regmap/regcache-rbtree.c b/drivers/base/regmap/regcache-rbtree.c
+index ae6b8788d5f3f..d65715b9e129e 100644
+--- a/drivers/base/regmap/regcache-rbtree.c
++++ b/drivers/base/regmap/regcache-rbtree.c
+@@ -453,7 +453,8 @@ static int regcache_rbtree_write(struct regmap *map, unsigned int reg,
+ if (!rbnode)
+ return -ENOMEM;
+ regcache_rbtree_set_register(map, rbnode,
+- reg - rbnode->base_reg, value);
++ (reg - rbnode->base_reg) / map->reg_stride,
++ value);
+ regcache_rbtree_insert(map, &rbtree_ctx->root, rbnode);
+ rbtree_ctx->cached_rbnode = rbnode;
+ }
+--
+2.40.1
+
--- /dev/null
+From 20169ee841f24a0ee805598ab78279316a3e93c2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 18 Sep 2023 15:58:48 -0700
+Subject: scsi: target: core: Fix deadlock due to recursive locking
+
+From: Junxiao Bi <junxiao.bi@oracle.com>
+
+[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ]
+
+The following call trace shows a deadlock issue due to recursive locking of
+mutex "device_mutex". First lock acquire is in target_for_each_device() and
+second in target_free_device().
+
+ PID: 148266 TASK: ffff8be21ffb5d00 CPU: 10 COMMAND: "iscsi_ttx"
+ #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f
+ #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224
+ #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee
+ #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7
+ #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3
+ #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c
+ #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod]
+ #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod]
+ #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f
+ #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583
+ #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod]
+ #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc
+ #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod]
+ #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod]
+ #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod]
+ #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod]
+ #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07
+ #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod]
+ #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod]
+ #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080
+ #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364
+
+Fixes: 36d4cb460bcb ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion")
+Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
+Link: https://lore.kernel.org/r/20230918225848.66463-1-junxiao.bi@oracle.com
+Reviewed-by: Mike Christie <michael.christie@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/target/target_core_device.c | 11 ++++-------
+ 1 file changed, 4 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c
+index 4664330fb55dd..9aeedcff7d02e 100644
+--- a/drivers/target/target_core_device.c
++++ b/drivers/target/target_core_device.c
+@@ -867,7 +867,6 @@ sector_t target_to_linux_sector(struct se_device *dev, sector_t lb)
+ EXPORT_SYMBOL(target_to_linux_sector);
+
+ struct devices_idr_iter {
+- struct config_item *prev_item;
+ int (*fn)(struct se_device *dev, void *data);
+ void *data;
+ };
+@@ -877,11 +876,9 @@ static int target_devices_idr_iter(int id, void *p, void *data)
+ {
+ struct devices_idr_iter *iter = data;
+ struct se_device *dev = p;
++ struct config_item *item;
+ int ret;
+
+- config_item_put(iter->prev_item);
+- iter->prev_item = NULL;
+-
+ /*
+ * We add the device early to the idr, so it can be used
+ * by backend modules during configuration. We do not want
+@@ -891,12 +888,13 @@ static int target_devices_idr_iter(int id, void *p, void *data)
+ if (!target_dev_configured(dev))
+ return 0;
+
+- iter->prev_item = config_item_get_unless_zero(&dev->dev_group.cg_item);
+- if (!iter->prev_item)
++ item = config_item_get_unless_zero(&dev->dev_group.cg_item);
++ if (!item)
+ return 0;
+ mutex_unlock(&device_mutex);
+
+ ret = iter->fn(dev, iter->data);
++ config_item_put(item);
+
+ mutex_lock(&device_mutex);
+ return ret;
+@@ -919,7 +917,6 @@ int target_for_each_device(int (*fn)(struct se_device *dev, void *data),
+ mutex_lock(&device_mutex);
+ ret = idr_for_each(&devices_idr, target_devices_idr_iter, &iter);
+ mutex_unlock(&device_mutex);
+- config_item_put(iter.prev_item);
+ return ret;
+ }
+
+--
+2.40.1
+
--- /dev/null
+From 31114040d5c5216765a9724341ba74cd94e1fea9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 1 Oct 2023 11:04:20 -0400
+Subject: sctp: update hb timer immediately after users change hb_interval
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 1f4e803cd9c9166eb8b6c8b0b8e4124f7499fc07 ]
+
+Currently, when hb_interval is changed by users, it won't take effect
+until the next expiry of hb timer. As the default value is 30s, users
+have to wait up to 30s to wait its hb_interval update to work.
+
+This becomes pretty bad in containers where a much smaller value is
+usually set on hb_interval. This patch improves it by resetting the
+hb timer immediately once the value of hb_interval is updated by users.
+
+Note that we don't address the already existing 'problem' when sending
+a heartbeat 'on demand' if one hb has just been sent(from the timer)
+mentioned in:
+
+ https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg590224.html
+
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Link: https://lore.kernel.org/r/75465785f8ee5df2fb3acdca9b8fafdc18984098.1696172660.git.lucien.xin@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sctp/socket.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/sctp/socket.c b/net/sctp/socket.c
+index 68d53e3f0d07a..bc4fe944ef858 100644
+--- a/net/sctp/socket.c
++++ b/net/sctp/socket.c
+@@ -2452,6 +2452,7 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params,
+ if (trans) {
+ trans->hbinterval =
+ msecs_to_jiffies(params->spp_hbinterval);
++ sctp_transport_reset_hb_timer(trans);
+ } else if (asoc) {
+ asoc->hbinterval =
+ msecs_to_jiffies(params->spp_hbinterval);
+--
+2.40.1
+
--- /dev/null
+From 3954b1d479dbc69207ab2a9cfd4e70ec7c512136 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 1 Oct 2023 10:58:45 -0400
+Subject: sctp: update transport state when processing a dupcook packet
+
+From: Xin Long <lucien.xin@gmail.com>
+
+[ Upstream commit 2222a78075f0c19ca18db53fd6623afb4aff602d ]
+
+During the 4-way handshake, the transport's state is set to ACTIVE in
+sctp_process_init() when processing INIT_ACK chunk on client or
+COOKIE_ECHO chunk on server.
+
+In the collision scenario below:
+
+ 192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
+ 192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO]
+ 192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK]
+ 192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021]
+
+when processing COOKIE_ECHO on 192.168.1.2, as it's in COOKIE_WAIT state,
+sctp_sf_do_dupcook_b() is called by sctp_sf_do_5_2_4_dupcook() where it
+creates a new association and sets its transport to ACTIVE then updates
+to the old association in sctp_assoc_update().
+
+However, in sctp_assoc_update(), it will skip the transport update if it
+finds a transport with the same ipaddr already existing in the old asoc,
+and this causes the old asoc's transport state not to move to ACTIVE
+after the handshake.
+
+This means if DATA retransmission happens at this moment, it won't be able
+to enter PF state because of the check 'transport->state == SCTP_ACTIVE'
+in sctp_do_8_2_transport_strike().
+
+This patch fixes it by updating the transport in sctp_assoc_update() with
+sctp_assoc_add_peer() where it updates the transport state if there is
+already a transport with the same ipaddr exists in the old asoc.
+
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Link: https://lore.kernel.org/r/fd17356abe49713ded425250cc1ae51e9f5846c6.1696172325.git.lucien.xin@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sctp/associola.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/net/sctp/associola.c b/net/sctp/associola.c
+index 2d4ec61877553..765eb617776b3 100644
+--- a/net/sctp/associola.c
++++ b/net/sctp/associola.c
+@@ -1151,8 +1151,7 @@ int sctp_assoc_update(struct sctp_association *asoc,
+ /* Add any peer addresses from the new association. */
+ list_for_each_entry(trans, &new->peer.transport_addr_list,
+ transports)
+- if (!sctp_assoc_lookup_paddr(asoc, &trans->ipaddr) &&
+- !sctp_assoc_add_peer(asoc, &trans->ipaddr,
++ if (!sctp_assoc_add_peer(asoc, &trans->ipaddr,
+ GFP_ATOMIC, trans->state))
+ return -ENOMEM;
+
+--
+2.40.1
+
block-fix-use-after-free-of-q-q_usage_counter.patch
revert-clk-imx-pll14xx-dynamically-configure-pll-for-393216000-361267200hz.patch
revert-pci-qcom-disable-write-access-to-read-only-registers-for-ip-v2.3.3.patch
+ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch
+wifi-iwlwifi-dbg_ini-fix-structure-packing.patch
+wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch
+bpf-fix-tr-dereferencing.patch
+drivers-net-process-the-result-of-hdlc_open-and-add-.patch
+wifi-mt76-mt76x02-fix-mt76x0-external-lna-gain-handl.patch
+regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch
+ima-finish-deprecation-of-ima_trusted_keyring-kconfi.patch
+scsi-target-core-fix-deadlock-due-to-recursive-locki.patch
+ima-rework-config_ima-dependency-block.patch
+nfsv4-fix-a-nfs4_state_manager-race.patch
+modpost-add-missing-else-to-the-of-check.patch
+net-fix-possible-store-tearing-in-neigh_periodic_wor.patch
+ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch
+net-dsa-mv88e6xxx-avoid-eeprom-timeout-when-eeprom-i.patch
+net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch
+net-nfc-llcp-add-lock-when-modifying-device-list.patch
+net-ethernet-ti-am65-cpsw-fix-error-code-in-am65_cps.patch
+netfilter-handle-the-connecting-collision-properly-i.patch
+netfilter-nf_tables-nft_set_rbtree-fix-spurious-inse.patch
+net-stmmac-dwmac-stm32-fix-resume-on-stm32-mcu.patch
+tipc-fix-a-potential-deadlock-on-tx-lock.patch
+tcp-fix-quick-ack-counting-to-count-actual-acks-of-n.patch
+tcp-fix-delayed-acks-for-mss-boundary-condition.patch
+sctp-update-transport-state-when-processing-a-dupcoo.patch
+sctp-update-hb-timer-immediately-after-users-change-.patch
--- /dev/null
+From 89429bae741aed20fd0359253a2aa8d472d73d59 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 1 Oct 2023 11:12:39 -0400
+Subject: tcp: fix delayed ACKs for MSS boundary condition
+
+From: Neal Cardwell <ncardwell@google.com>
+
+[ Upstream commit 4720852ed9afb1c5ab84e96135cb5b73d5afde6f ]
+
+This commit fixes poor delayed ACK behavior that can cause poor TCP
+latency in a particular boundary condition: when an application makes
+a TCP socket write that is an exact multiple of the MSS size.
+
+The problem is that there is painful boundary discontinuity in the
+current delayed ACK behavior. With the current delayed ACK behavior,
+we have:
+
+(1) If an app reads data when > 1*MSS is unacknowledged, then
+ tcp_cleanup_rbuf() ACKs immediately because of:
+
+ tp->rcv_nxt - tp->rcv_wup > icsk->icsk_ack.rcv_mss ||
+
+(2) If an app reads all received data, and the packets were < 1*MSS,
+ and either (a) the app is not ping-pong or (b) we received two
+ packets < 1*MSS, then tcp_cleanup_rbuf() ACKs immediately beecause
+ of:
+
+ ((icsk->icsk_ack.pending & ICSK_ACK_PUSHED2) ||
+ ((icsk->icsk_ack.pending & ICSK_ACK_PUSHED) &&
+ !inet_csk_in_pingpong_mode(sk))) &&
+
+(3) *However*: if an app reads exactly 1*MSS of data,
+ tcp_cleanup_rbuf() does not send an immediate ACK. This is true
+ even if the app is not ping-pong and the 1*MSS of data had the PSH
+ bit set, suggesting the sending application completed an
+ application write.
+
+Thus if the app is not ping-pong, we have this painful case where
+>1*MSS gets an immediate ACK, and <1*MSS gets an immediate ACK, but a
+write whose last skb is an exact multiple of 1*MSS can get a 40ms
+delayed ACK. This means that any app that transfers data in one
+direction and takes care to align write size or packet size with MSS
+can suffer this problem. With receive zero copy making 4KB MSS values
+more common, it is becoming more common to have application writes
+naturally align with MSS, and more applications are likely to
+encounter this delayed ACK problem.
+
+The fix in this commit is to refine the delayed ACK heuristics with a
+simple check: immediately ACK a received 1*MSS skb with PSH bit set if
+the app reads all data. Why? If an skb has a len of exactly 1*MSS and
+has the PSH bit set then it is likely the end of an application
+write. So more data may not be arriving soon, and yet the data sender
+may be waiting for an ACK if cwnd-bound or using TX zero copy. Thus we
+set ICSK_ACK_PUSHED in this case so that tcp_cleanup_rbuf() will send
+an ACK immediately if the app reads all of the data and is not
+ping-pong. Note that this logic is also executed for the case where
+len > MSS, but in that case this logic does not matter (and does not
+hurt) because tcp_cleanup_rbuf() will always ACK immediately if the
+app reads data and there is more than an MSS of unACKed data.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Neal Cardwell <ncardwell@google.com>
+Reviewed-by: Yuchung Cheng <ycheng@google.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Cc: Xin Guo <guoxin0309@gmail.com>
+Link: https://lore.kernel.org/r/20231001151239.1866845-2-ncardwell.sw@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/tcp_input.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
+index b8d2c45edbe02..3f2b6a3adf6a9 100644
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -242,6 +242,19 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)
+ if (unlikely(len > icsk->icsk_ack.rcv_mss +
+ MAX_TCP_OPTION_SPACE))
+ tcp_gro_dev_warn(sk, skb, len);
++ /* If the skb has a len of exactly 1*MSS and has the PSH bit
++ * set then it is likely the end of an application write. So
++ * more data may not be arriving soon, and yet the data sender
++ * may be waiting for an ACK if cwnd-bound or using TX zero
++ * copy. So we set ICSK_ACK_PUSHED here so that
++ * tcp_cleanup_rbuf() will send an ACK immediately if the app
++ * reads all of the data and is not ping-pong. If len > MSS
++ * then this logic does not matter (and does not hurt) because
++ * tcp_cleanup_rbuf() will always ACK immediately if the app
++ * reads data and there is more than an MSS of unACKed data.
++ */
++ if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_PSH)
++ icsk->icsk_ack.pending |= ICSK_ACK_PUSHED;
+ } else {
+ /* Otherwise, we make more careful check taking into account,
+ * that SACKs block is variable.
+--
+2.40.1
+
--- /dev/null
+From ed11876765c650383afcabefef3786b34d25c177 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 1 Oct 2023 11:12:38 -0400
+Subject: tcp: fix quick-ack counting to count actual ACKs of new data
+
+From: Neal Cardwell <ncardwell@google.com>
+
+[ Upstream commit 059217c18be6757b95bfd77ba53fb50b48b8a816 ]
+
+This commit fixes quick-ack counting so that it only considers that a
+quick-ack has been provided if we are sending an ACK that newly
+acknowledges data.
+
+The code was erroneously using the number of data segments in outgoing
+skbs when deciding how many quick-ack credits to remove. This logic
+does not make sense, and could cause poor performance in
+request-response workloads, like RPC traffic, where requests or
+responses can be multi-segment skbs.
+
+When a TCP connection decides to send N quick-acks, that is to
+accelerate the cwnd growth of the congestion control module
+controlling the remote endpoint of the TCP connection. That quick-ack
+decision is purely about the incoming data and outgoing ACKs. It has
+nothing to do with the outgoing data or the size of outgoing data.
+
+And in particular, an ACK only serves the intended purpose of allowing
+the remote congestion control to grow the congestion window quickly if
+the ACK is ACKing or SACKing new data.
+
+The fix is simple: only count packets as serving the goal of the
+quickack mechanism if they are ACKing/SACKing new data. We can tell
+whether this is the case by checking inet_csk_ack_scheduled(), since
+we schedule an ACK exactly when we are ACKing/SACKing new data.
+
+Fixes: fc6415bcb0f5 ("[TCP]: Fix quick-ack decrementing with TSO.")
+Signed-off-by: Neal Cardwell <ncardwell@google.com>
+Reviewed-by: Yuchung Cheng <ycheng@google.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20231001151239.1866845-1-ncardwell.sw@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/net/tcp.h | 6 ++++--
+ net/ipv4/tcp_output.c | 7 +++----
+ 2 files changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/include/net/tcp.h b/include/net/tcp.h
+index b56f346020351..cb4b2fddd9eb3 100644
+--- a/include/net/tcp.h
++++ b/include/net/tcp.h
+@@ -337,12 +337,14 @@ ssize_t tcp_splice_read(struct socket *sk, loff_t *ppos,
+ struct pipe_inode_info *pipe, size_t len,
+ unsigned int flags);
+
+-static inline void tcp_dec_quickack_mode(struct sock *sk,
+- const unsigned int pkts)
++static inline void tcp_dec_quickack_mode(struct sock *sk)
+ {
+ struct inet_connection_sock *icsk = inet_csk(sk);
+
+ if (icsk->icsk_ack.quick) {
++ /* How many ACKs S/ACKing new data have we sent? */
++ const unsigned int pkts = inet_csk_ack_scheduled(sk) ? 1 : 0;
++
+ if (pkts >= icsk->icsk_ack.quick) {
+ icsk->icsk_ack.quick = 0;
+ /* Leaving quickack mode we deflate ATO. */
+diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
+index 86e896351364e..6c14d67715d15 100644
+--- a/net/ipv4/tcp_output.c
++++ b/net/ipv4/tcp_output.c
+@@ -177,8 +177,7 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
+ }
+
+ /* Account for an ACK we sent. */
+-static inline void tcp_event_ack_sent(struct sock *sk, unsigned int pkts,
+- u32 rcv_nxt)
++static inline void tcp_event_ack_sent(struct sock *sk, u32 rcv_nxt)
+ {
+ struct tcp_sock *tp = tcp_sk(sk);
+
+@@ -192,7 +191,7 @@ static inline void tcp_event_ack_sent(struct sock *sk, unsigned int pkts,
+
+ if (unlikely(rcv_nxt != tp->rcv_nxt))
+ return; /* Special ACK sent by DCTCP to reflect ECN */
+- tcp_dec_quickack_mode(sk, pkts);
++ tcp_dec_quickack_mode(sk);
+ inet_csk_clear_xmit_timer(sk, ICSK_TIME_DACK);
+ }
+
+@@ -1374,7 +1373,7 @@ static int __tcp_transmit_skb(struct sock *sk, struct sk_buff *skb,
+ sk, skb);
+
+ if (likely(tcb->tcp_flags & TCPHDR_ACK))
+- tcp_event_ack_sent(sk, tcp_skb_pcount(skb), rcv_nxt);
++ tcp_event_ack_sent(sk, rcv_nxt);
+
+ if (skb->len != tcp_header_size) {
+ tcp_event_data_sent(tp, sk);
+--
+2.40.1
+
--- /dev/null
+From 3a2ac54353beb222957a308ca9cc92662f3be49c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Sep 2023 18:14:14 +0000
+Subject: tipc: fix a potential deadlock on &tx->lock
+
+From: Chengfeng Ye <dg573847474@gmail.com>
+
+[ Upstream commit 08e50cf071847323414df0835109b6f3560d44f5 ]
+
+It seems that tipc_crypto_key_revoke() could be be invoked by
+wokequeue tipc_crypto_work_rx() under process context and
+timer/rx callback under softirq context, thus the lock acquisition
+on &tx->lock seems better use spin_lock_bh() to prevent possible
+deadlock.
+
+This flaw was found by an experimental static analysis tool I am
+developing for irq-related deadlock.
+
+tipc_crypto_work_rx() <workqueue>
+--> tipc_crypto_key_distr()
+--> tipc_bcast_xmit()
+--> tipc_bcbase_xmit()
+--> tipc_bearer_bc_xmit()
+--> tipc_crypto_xmit()
+--> tipc_ehdr_build()
+--> tipc_crypto_key_revoke()
+--> spin_lock(&tx->lock)
+<timer interrupt>
+ --> tipc_disc_timeout()
+ --> tipc_bearer_xmit_skb()
+ --> tipc_crypto_xmit()
+ --> tipc_ehdr_build()
+ --> tipc_crypto_key_revoke()
+ --> spin_lock(&tx->lock) <deadlock here>
+
+Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Acked-by: Jon Maloy <jmaloy@redhat.com>
+Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
+Link: https://lore.kernel.org/r/20230927181414.59928-1-dg573847474@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/tipc/crypto.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
+index 2784d69892117..b5aa0a835bced 100644
+--- a/net/tipc/crypto.c
++++ b/net/tipc/crypto.c
+@@ -1445,14 +1445,14 @@ static int tipc_crypto_key_revoke(struct net *net, u8 tx_key)
+ struct tipc_crypto *tx = tipc_net(net)->crypto_tx;
+ struct tipc_key key;
+
+- spin_lock(&tx->lock);
++ spin_lock_bh(&tx->lock);
+ key = tx->key;
+ WARN_ON(!key.active || tx_key != key.active);
+
+ /* Free the active key */
+ tipc_crypto_key_set_state(tx, key.passive, 0, key.pending);
+ tipc_crypto_key_detach(tx->aead[key.active], &tx->lock);
+- spin_unlock(&tx->lock);
++ spin_unlock_bh(&tx->lock);
+
+ pr_warn("%s: key is revoked\n", tx->name);
+ return -EKEYREVOKED;
+--
+2.40.1
+
--- /dev/null
+From 5a01fccabf2e95f560b91d66f0875d65f2626e85 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 23 Apr 2023 19:10:41 +0800
+Subject: ubi: Refuse attaching if mtd's erasesize is 0
+
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+
+[ Upstream commit 017c73a34a661a861712f7cc1393a123e5b2208c ]
+
+There exists mtd devices with zero erasesize, which will trigger a
+divide-by-zero exception while attaching ubi device.
+Fix it by refusing attaching if mtd's erasesize is 0.
+
+Fixes: 801c135ce73d ("UBI: Unsorted Block Images")
+Reported-by: Yu Hao <yhao016@ucr.edu>
+Link: https://lore.kernel.org/lkml/977347543.226888.1682011999468.JavaMail.zimbra@nod.at/T/
+Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mtd/ubi/build.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
+index 929ce489b0629..c689bed646287 100644
+--- a/drivers/mtd/ubi/build.c
++++ b/drivers/mtd/ubi/build.c
+@@ -889,6 +889,13 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
+ return -EINVAL;
+ }
+
++ /* UBI cannot work on flashes with zero erasesize. */
++ if (!mtd->erasesize) {
++ pr_err("ubi: refuse attaching mtd%d - zero erasesize flash is not supported\n",
++ mtd->index);
++ return -EINVAL;
++ }
++
+ if (ubi_num == UBI_DEV_NUM_AUTO) {
+ /* Search for an empty slot in the @ubi_devices array */
+ for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
+--
+2.40.1
+
--- /dev/null
+From 75bd69733e8b1caaf1ba1ecbf467cc751a07b3aa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 16 Jun 2023 11:03:34 +0200
+Subject: wifi: iwlwifi: dbg_ini: fix structure packing
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit 424c82e8ad56756bb98b08268ffcf68d12d183eb ]
+
+The iwl_fw_ini_error_dump_range structure has conflicting alignment
+requirements for the inner union and the outer struct:
+
+In file included from drivers/net/wireless/intel/iwlwifi/fw/dbg.c:9:
+drivers/net/wireless/intel/iwlwifi/fw/error-dump.h:312:2: error: field within 'struct iwl_fw_ini_error_dump_range' is less aligned than 'union iwl_fw_ini_error_dump_range::(anonymous at drivers/net/wireless/intel/iwlwifi/fw/error-dump.h:312:2)' and is usually due to 'struct iwl_fw_ini_error_dump_range' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]
+ union {
+
+As the original intention was apparently to make the entire structure
+unaligned, mark the innermost members the same way so the union
+becomes packed as well.
+
+Fixes: 973193554cae6 ("iwlwifi: dbg_ini: dump headers cleanup")
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Acked-by: Gregory Greenman <gregory.greenman@intel.com>
+Link: https://lore.kernel.org/r/20230616090343.2454061-1-arnd@kernel.org
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/wireless/intel/iwlwifi/fw/error-dump.h b/drivers/net/wireless/intel/iwlwifi/fw/error-dump.h
+index cb40f509ab612..d08750abac953 100644
+--- a/drivers/net/wireless/intel/iwlwifi/fw/error-dump.h
++++ b/drivers/net/wireless/intel/iwlwifi/fw/error-dump.h
+@@ -334,9 +334,9 @@ struct iwl_fw_ini_fifo_hdr {
+ struct iwl_fw_ini_error_dump_range {
+ __le32 range_data_size;
+ union {
+- __le32 internal_base_addr;
+- __le64 dram_base_addr;
+- __le32 page_num;
++ __le32 internal_base_addr __packed;
++ __le64 dram_base_addr __packed;
++ __le32 page_num __packed;
+ struct iwl_fw_ini_fifo_hdr fifo_hdr;
+ struct iwl_cmd_header fw_pkt_hdr;
+ };
+--
+2.40.1
+
--- /dev/null
+From 913ec7265cfd5b3516a206e203bb6ff88336c1da Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 19 Sep 2023 21:47:47 +0200
+Subject: wifi: mt76: mt76x02: fix MT76x0 external LNA gain handling
+
+From: Felix Fietkau <nbd@nbd.name>
+
+[ Upstream commit 684e45e120b82deccaf8b85633905304a3bbf56d ]
+
+On MT76x0, LNA gain should be applied for both external and internal LNA.
+On MT76x2, LNA gain should be treated as 0 for external LNA.
+Move the LNA type based logic to mt76x2 in order to fix mt76x0.
+
+Fixes: 2daa67588f34 ("mt76x0: unify lna_gain parsing")
+Reported-by: Shiji Yang <yangshiji66@outlook.com>
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20230919194747.31647-1-nbd@nbd.name
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.c | 7 -------
+ drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c | 13 +++++++++++--
+ 2 files changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.c b/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.c
+index 0acabba2d1a50..5d402cf2951cb 100644
+--- a/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.c
++++ b/drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.c
+@@ -131,15 +131,8 @@ u8 mt76x02_get_lna_gain(struct mt76x02_dev *dev,
+ s8 *lna_2g, s8 *lna_5g,
+ struct ieee80211_channel *chan)
+ {
+- u16 val;
+ u8 lna;
+
+- val = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_1);
+- if (val & MT_EE_NIC_CONF_1_LNA_EXT_2G)
+- *lna_2g = 0;
+- if (val & MT_EE_NIC_CONF_1_LNA_EXT_5G)
+- memset(lna_5g, 0, sizeof(s8) * 3);
+-
+ if (chan->band == NL80211_BAND_2GHZ)
+ lna = *lna_2g;
+ else if (chan->hw_value <= 64)
+diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c
+index 410ffce3bafff..60478116014f8 100644
+--- a/drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c
++++ b/drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c
+@@ -256,7 +256,8 @@ void mt76x2_read_rx_gain(struct mt76x02_dev *dev)
+ struct ieee80211_channel *chan = dev->mphy.chandef.chan;
+ int channel = chan->hw_value;
+ s8 lna_5g[3], lna_2g;
+- u8 lna;
++ bool use_lna;
++ u8 lna = 0;
+ u16 val;
+
+ if (chan->band == NL80211_BAND_2GHZ)
+@@ -275,7 +276,15 @@ void mt76x2_read_rx_gain(struct mt76x02_dev *dev)
+ dev->cal.rx.mcu_gain |= (lna_5g[1] & 0xff) << 16;
+ dev->cal.rx.mcu_gain |= (lna_5g[2] & 0xff) << 24;
+
+- lna = mt76x02_get_lna_gain(dev, &lna_2g, lna_5g, chan);
++ val = mt76x02_eeprom_get(dev, MT_EE_NIC_CONF_1);
++ if (chan->band == NL80211_BAND_2GHZ)
++ use_lna = !(val & MT_EE_NIC_CONF_1_LNA_EXT_2G);
++ else
++ use_lna = !(val & MT_EE_NIC_CONF_1_LNA_EXT_5G);
++
++ if (use_lna)
++ lna = mt76x02_get_lna_gain(dev, &lna_2g, lna_5g, chan);
++
+ dev->cal.rx.lna_gain = mt76x02_sign_extend(lna, 8);
+ }
+ EXPORT_SYMBOL_GPL(mt76x2_read_rx_gain);
+--
+2.40.1
+
--- /dev/null
+From 55e92aa32d6d392672030ad7f1633b7d1f7e437d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 8 Sep 2023 18:41:12 +0800
+Subject: wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
+
+From: Pin-yen Lin <treapking@chromium.org>
+
+[ Upstream commit aef7a0300047e7b4707ea0411dc9597cba108fc8 ]
+
+Only skip the code path trying to access the rfc1042 headers when the
+buffer is too small, so the driver can still process packets without
+rfc1042 headers.
+
+Fixes: 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets")
+Signed-off-by: Pin-yen Lin <treapking@chromium.org>
+Acked-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Matthew Wang <matthewmwang@chromium.org>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20230908104308.1546501-1-treapking@chromium.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/marvell/mwifiex/sta_rx.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/net/wireless/marvell/mwifiex/sta_rx.c b/drivers/net/wireless/marvell/mwifiex/sta_rx.c
+index 3c555946cb2cc..5b16e330014ac 100644
+--- a/drivers/net/wireless/marvell/mwifiex/sta_rx.c
++++ b/drivers/net/wireless/marvell/mwifiex/sta_rx.c
+@@ -98,7 +98,8 @@ int mwifiex_process_rx_packet(struct mwifiex_private *priv,
+ rx_pkt_len = le16_to_cpu(local_rx_pd->rx_pkt_length);
+ rx_pkt_hdr = (void *)local_rx_pd + rx_pkt_off;
+
+- if (sizeof(*rx_pkt_hdr) + rx_pkt_off > skb->len) {
++ if (sizeof(rx_pkt_hdr->eth803_hdr) + sizeof(rfc1042_header) +
++ rx_pkt_off > skb->len) {
+ mwifiex_dbg(priv->adapter, ERROR,
+ "wrong rx packet offset: len=%d, rx_pkt_off=%d\n",
+ skb->len, rx_pkt_off);
+@@ -107,12 +108,13 @@ int mwifiex_process_rx_packet(struct mwifiex_private *priv,
+ return -1;
+ }
+
+- if ((!memcmp(&rx_pkt_hdr->rfc1042_hdr, bridge_tunnel_header,
+- sizeof(bridge_tunnel_header))) ||
+- (!memcmp(&rx_pkt_hdr->rfc1042_hdr, rfc1042_header,
+- sizeof(rfc1042_header)) &&
+- ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_AARP &&
+- ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_IPX)) {
++ if (sizeof(*rx_pkt_hdr) + rx_pkt_off <= skb->len &&
++ ((!memcmp(&rx_pkt_hdr->rfc1042_hdr, bridge_tunnel_header,
++ sizeof(bridge_tunnel_header))) ||
++ (!memcmp(&rx_pkt_hdr->rfc1042_hdr, rfc1042_header,
++ sizeof(rfc1042_header)) &&
++ ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_AARP &&
++ ntohs(rx_pkt_hdr->rfc1042_hdr.snap_type) != ETH_P_IPX))) {
+ /*
+ * Replace the 803 header and rfc1042 header (llc/snap) with an
+ * EthernetII header, keep the src/dst and snap_type
+--
+2.40.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
