From: Sasha Levin Date: Sat, 7 Oct 2023 12:15:45 +0000 (-0400) Subject: Fixes for 5.15 X-Git-Tag: v4.14.327~53^2~5 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=296b23e8d4f7bcfece7ee2cd6810d40c3c9d6892;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.15 Signed-off-by: Sasha Levin --- diff --git a/queue-5.15/bpf-fix-tr-dereferencing.patch b/queue-5.15/bpf-fix-tr-dereferencing.patch new file mode 100644 index 00000000000..a8d26c862a0 --- /dev/null +++ b/queue-5.15/bpf-fix-tr-dereferencing.patch @@ -0,0 +1,42 @@ +From 3465a779fb79aa7fea2b33fd0e851e873e4cf038 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 17 Sep 2023 23:38:46 +0800 +Subject: bpf: Fix tr dereferencing + +From: Leon Hwang + +[ 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 +Reported-by: Dan Carpenter +Signed-off-by: Leon Hwang +Signed-off-by: Andrii Nakryiko +Link: https://lore.kernel.org/bpf/20230917153846.88732-1-hffilwlqm@gmail.com +Signed-off-by: Sasha Levin +--- + 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 84efd8dd139d9..9ab087d73ab34 100644 +--- a/include/linux/bpf.h ++++ b/include/linux/bpf.h +@@ -840,7 +840,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 + diff --git a/queue-5.15/bpf-sockmap-reject-sk_msg-egress-redirects-to-non-tc.patch b/queue-5.15/bpf-sockmap-reject-sk_msg-egress-redirects-to-non-tc.patch new file mode 100644 index 00000000000..345eb932cad --- /dev/null +++ b/queue-5.15/bpf-sockmap-reject-sk_msg-egress-redirects-to-non-tc.patch @@ -0,0 +1,102 @@ +From f3621510347d5b54df2ab2ab00c8b64710778831 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 20 Sep 2023 12:20:55 +0200 +Subject: bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets + +From: Jakub Sitnicki + +[ Upstream commit b80e31baa43614e086a9d29dc1151932b1bd7fc5 ] + +With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages +sent from one TCP socket (s1) to actually egress from another TCP +socket (s2): + +tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg + tcp_bpf_send_verdict(s1) // __SK_REDIRECT case + tcp_bpf_sendmsg_redir(s2) + tcp_bpf_push_locked(s2) + tcp_bpf_push(s2) + tcp_rate_check_app_limited(s2) // expects tcp_sock + tcp_sendmsg_locked(s2) // ditto + +There is a hard-coded assumption in the call-chain, that the egress +socket (s2) is a TCP socket. + +However in commit 122e6c79efe1 ("sock_map: Update sock type checks for +UDP") we have enabled redirects to non-TCP sockets. This was done for the +sake of BPF sk_skb programs. There was no indention to support sk_msg +send-to-egress use case. + +As a result, attempts to send-to-egress through a non-TCP socket lead to a +crash due to invalid downcast from sock to tcp_sock: + + BUG: kernel NULL pointer dereference, address: 000000000000002f + ... + Call Trace: + + ? show_regs+0x60/0x70 + ? __die+0x1f/0x70 + ? page_fault_oops+0x80/0x160 + ? do_user_addr_fault+0x2d7/0x800 + ? rcu_is_watching+0x11/0x50 + ? exc_page_fault+0x70/0x1c0 + ? asm_exc_page_fault+0x27/0x30 + ? tcp_tso_segs+0x14/0xa0 + tcp_write_xmit+0x67/0xce0 + __tcp_push_pending_frames+0x32/0xf0 + tcp_push+0x107/0x140 + tcp_sendmsg_locked+0x99f/0xbb0 + tcp_bpf_push+0x19d/0x3a0 + tcp_bpf_sendmsg_redir+0x55/0xd0 + tcp_bpf_send_verdict+0x407/0x550 + tcp_bpf_sendmsg+0x1a1/0x390 + inet_sendmsg+0x6a/0x70 + sock_sendmsg+0x9d/0xc0 + ? sockfd_lookup_light+0x12/0x80 + __sys_sendto+0x10e/0x160 + ? syscall_enter_from_user_mode+0x20/0x60 + ? __this_cpu_preempt_check+0x13/0x20 + ? lockdep_hardirqs_on+0x82/0x110 + __x64_sys_sendto+0x1f/0x30 + do_syscall_64+0x38/0x90 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg +program to prevent the crash. When attempted, user will receive an EACCES +error from send/sendto/sendmsg() syscall. + +Fixes: 122e6c79efe1 ("sock_map: Update sock type checks for UDP") +Signed-off-by: Jakub Sitnicki +Signed-off-by: Daniel Borkmann +Acked-by: John Fastabend +Link: https://lore.kernel.org/bpf/20230920102055.42662-1-jakub@cloudflare.com +Signed-off-by: Sasha Levin +--- + net/core/sock_map.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/net/core/sock_map.c b/net/core/sock_map.c +index caae43e66353d..ba6d5b38fb238 100644 +--- a/net/core/sock_map.c ++++ b/net/core/sock_map.c +@@ -676,6 +676,8 @@ BPF_CALL_4(bpf_msg_redirect_map, struct sk_msg *, msg, + sk = __sock_map_lookup_elem(map, key); + if (unlikely(!sk || !sock_map_redirect_allowed(sk))) + return SK_DROP; ++ if (!(flags & BPF_F_INGRESS) && !sk_is_tcp(sk)) ++ return SK_DROP; + + msg->flags = flags; + msg->sk_redir = sk; +@@ -1269,6 +1271,8 @@ BPF_CALL_4(bpf_msg_redirect_hash, struct sk_msg *, msg, + sk = __sock_hash_lookup_elem(map, key); + if (unlikely(!sk || !sock_map_redirect_allowed(sk))) + return SK_DROP; ++ if (!(flags & BPF_F_INGRESS) && !sk_is_tcp(sk)) ++ return SK_DROP; + + msg->flags = flags; + msg->sk_redir = sk; +-- +2.40.1 + diff --git a/queue-5.15/drivers-net-process-the-result-of-hdlc_open-and-add-.patch b/queue-5.15/drivers-net-process-the-result-of-hdlc_open-and-add-.patch new file mode 100644 index 00000000000..f7c771128d3 --- /dev/null +++ b/queue-5.15/drivers-net-process-the-result-of-hdlc_open-and-add-.patch @@ -0,0 +1,78 @@ +From 55514a63e9bc9b9be8971e297a3374d08ac4fa6f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Christophe Leroy +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 8305df1a3008a..44348e2dd95ea 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, +@@ -705,6 +707,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, +@@ -728,10 +731,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) +@@ -821,6 +827,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 + diff --git a/queue-5.15/hid-intel-ish-hid-ipc-disable-and-reenable-acpi-gpe-.patch b/queue-5.15/hid-intel-ish-hid-ipc-disable-and-reenable-acpi-gpe-.patch new file mode 100644 index 00000000000..62b9ee76c3c --- /dev/null +++ b/queue-5.15/hid-intel-ish-hid-ipc-disable-and-reenable-acpi-gpe-.patch @@ -0,0 +1,55 @@ +From 84ed3b0379be2af5402f4cef4920932d1a9cb8ee Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 3 Oct 2023 08:53:32 -0700 +Subject: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit + +From: Srinivas Pandruvada + +[ Upstream commit 8f02139ad9a7e6e5c05712f8c1501eebed8eacfd ] + +The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) +service, which allows to wakup device when the system is in S5 (Soft-Off +state). This OOB service can be enabled/disabled from BIOS settings. When +enabled, the ISH device gets PME wake capability. To enable PME wakeup, +driver also needs to enable ACPI GPE bit. + +On resume, BIOS will clear the wakeup bit. So driver need to re-enable it +in resume function to keep the next wakeup capability. But this BIOS +clearing of wakeup bit doesn't decrement internal OS GPE reference count, +so this reenabling on every resume will cause reference count to overflow. + +So first disable and reenable ACPI GPE bit using acpi_disable_gpe(). + +Fixes: 2e23a70edabe ("HID: intel-ish-hid: ipc: finish power flow for EHL OOB") +Reported-by: Kai-Heng Feng +Closes: https://lore.kernel.org/lkml/CAAd53p4=oLYiH2YbVSmrPNj1zpMcfp=Wxbasb5vhMXOWCArLCg@mail.gmail.com/T/ +Tested-by: Kai-Heng Feng +Signed-off-by: Srinivas Pandruvada +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/intel-ish-hid/ipc/pci-ish.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c +index 8e9d9450cb835..5916ef2933e27 100644 +--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c ++++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c +@@ -129,6 +129,14 @@ static int enable_gpe(struct device *dev) + } + wakeup = &adev->wakeup; + ++ /* ++ * Call acpi_disable_gpe(), so that reference count ++ * gpe_event_info->runtime_count doesn't overflow. ++ * When gpe_event_info->runtime_count = 0, the call ++ * to acpi_disable_gpe() simply return. ++ */ ++ acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number); ++ + acpi_sts = acpi_enable_gpe(wakeup->gpe_device, wakeup->gpe_number); + if (ACPI_FAILURE(acpi_sts)) { + dev_err(dev, "enable ose_gpe failed\n"); +-- +2.40.1 + diff --git a/queue-5.15/hid-sony-fix-a-potential-memory-leak-in-sony_probe.patch b/queue-5.15/hid-sony-fix-a-potential-memory-leak-in-sony_probe.patch new file mode 100644 index 00000000000..3f4717e3236 --- /dev/null +++ b/queue-5.15/hid-sony-fix-a-potential-memory-leak-in-sony_probe.patch @@ -0,0 +1,37 @@ +From 273173160c9073a8ebdde2c8796657275b9243e4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 3 Sep 2023 18:04:00 +0200 +Subject: HID: sony: Fix a potential memory leak in sony_probe() + +From: Christophe JAILLET + +[ Upstream commit e1cd4004cde7c9b694bbdd8def0e02288ee58c74 ] + +If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() +should be called. + +Fixes: fb1a79a6b6e1 ("HID: sony: fix freeze when inserting ghlive ps3/wii dongles") +Signed-off-by: Christophe JAILLET +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/hid-sony.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c +index 60ec2b29d54de..3ab18811b0090 100644 +--- a/drivers/hid/hid-sony.c ++++ b/drivers/hid/hid-sony.c +@@ -3074,6 +3074,9 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id) + return ret; + + err: ++ if (sc->ghl_urb) ++ usb_free_urb(sc->ghl_urb); ++ + hid_hw_stop(hdev); + return ret; + } +-- +2.40.1 + diff --git a/queue-5.15/hid-sony-remove-duplicate-null-check-before-calling-.patch b/queue-5.15/hid-sony-remove-duplicate-null-check-before-calling-.patch new file mode 100644 index 00000000000..32b9a633e40 --- /dev/null +++ b/queue-5.15/hid-sony-remove-duplicate-null-check-before-calling-.patch @@ -0,0 +1,37 @@ +From faf769d327ddb2416dbf9d0913b0bf1fe5695964 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 4 Oct 2023 21:10:41 +0200 +Subject: HID: sony: remove duplicate NULL check before calling usb_free_urb() + +From: Jiri Kosina + +[ Upstream commit b328dd02e19cb9d3b35de4322f5363516a20ac8c ] + +usb_free_urb() does the NULL check itself, so there is no need to duplicate +it prior to calling. + +Reported-by: kernel test robot +Fixes: e1cd4004cde7c9 ("HID: sony: Fix a potential memory leak in sony_probe()") +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/hid-sony.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c +index 3ab18811b0090..c330d5a20ca04 100644 +--- a/drivers/hid/hid-sony.c ++++ b/drivers/hid/hid-sony.c +@@ -3074,8 +3074,7 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id) + return ret; + + err: +- if (sc->ghl_urb) +- usb_free_urb(sc->ghl_urb); ++ usb_free_urb(sc->ghl_urb); + + hid_hw_stop(hdev); + return ret; +-- +2.40.1 + diff --git a/queue-5.15/ibmveth-remove-condition-to-recompute-tcp-header-che.patch b/queue-5.15/ibmveth-remove-condition-to-recompute-tcp-header-che.patch new file mode 100644 index 00000000000..ae0673d5890 --- /dev/null +++ b/queue-5.15/ibmveth-remove-condition-to-recompute-tcp-header-che.patch @@ -0,0 +1,72 @@ +From c339a535c13b3f91801301ebbf7026e0a642017e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 26 Sep 2023 16:42:51 -0500 +Subject: ibmveth: Remove condition to recompute TCP header checksum. + +From: David Wilder + +[ Upstream commit 51e7a66666e0ca9642c59464ef8359f0ac604d41 ] + +In some OVS environments the TCP pseudo header checksum may need to be +recomputed. Currently this is only done when the interface instance is +configured for "Trunk Mode". We found the issue also occurs in some +Kubernetes environments, these environments do not use "Trunk Mode", +therefor the condition is removed. + +Performance tests with this change show only a fractional decrease in +throughput (< 0.2%). + +Fixes: 7525de2516fb ("ibmveth: Set CHECKSUM_PARTIAL if NULL TCP CSUM.") +Signed-off-by: David Wilder +Reviewed-by: Nick Child +Reviewed-by: Jacob Keller +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/ibm/ibmveth.c | 25 ++++++++++++------------- + 1 file changed, 12 insertions(+), 13 deletions(-) + +diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c +index 05759f690e1fd..67ea2cb21e849 100644 +--- a/drivers/net/ethernet/ibm/ibmveth.c ++++ b/drivers/net/ethernet/ibm/ibmveth.c +@@ -1297,24 +1297,23 @@ static void ibmveth_rx_csum_helper(struct sk_buff *skb, + * the user space for finding a flow. During this process, OVS computes + * checksum on the first packet when CHECKSUM_PARTIAL flag is set. + * +- * So, re-compute TCP pseudo header checksum when configured for +- * trunk mode. ++ * So, re-compute TCP pseudo header checksum. + */ ++ + if (iph_proto == IPPROTO_TCP) { + struct tcphdr *tcph = (struct tcphdr *)(skb->data + iphlen); ++ + if (tcph->check == 0x0000) { + /* Recompute TCP pseudo header checksum */ +- if (adapter->is_active_trunk) { +- tcphdrlen = skb->len - iphlen; +- if (skb_proto == ETH_P_IP) +- tcph->check = +- ~csum_tcpudp_magic(iph->saddr, +- iph->daddr, tcphdrlen, iph_proto, 0); +- else if (skb_proto == ETH_P_IPV6) +- tcph->check = +- ~csum_ipv6_magic(&iph6->saddr, +- &iph6->daddr, tcphdrlen, iph_proto, 0); +- } ++ tcphdrlen = skb->len - iphlen; ++ if (skb_proto == ETH_P_IP) ++ tcph->check = ++ ~csum_tcpudp_magic(iph->saddr, ++ iph->daddr, tcphdrlen, iph_proto, 0); ++ else if (skb_proto == ETH_P_IPV6) ++ tcph->check = ++ ~csum_ipv6_magic(&iph6->saddr, ++ &iph6->daddr, tcphdrlen, iph_proto, 0); + /* Setup SKB fields for checksum offload */ + skb_partial_csum_set(skb, iphlen, + offsetof(struct tcphdr, check)); +-- +2.40.1 + diff --git a/queue-5.15/ima-finish-deprecation-of-ima_trusted_keyring-kconfi.patch b/queue-5.15/ima-finish-deprecation-of-ima_trusted_keyring-kconfi.patch new file mode 100644 index 00000000000..b3b1d0f33cf --- /dev/null +++ b/queue-5.15/ima-finish-deprecation-of-ima_trusted_keyring-kconfi.patch @@ -0,0 +1,50 @@ +From ff1c7ee528a4be6489caad0b6b04c603b20636ef Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 21 Sep 2023 06:45:05 +0000 +Subject: ima: Finish deprecation of IMA_TRUSTED_KEYRING Kconfig + +From: Oleksandr Tymoshenko + +[ 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 +Reviewed-by: Nayna Jain +Signed-off-by: Mimi Zohar +Signed-off-by: Sasha Levin +--- + 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 7bc416c172119..2200262489103 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 + diff --git a/queue-5.15/ima-rework-config_ima-dependency-block.patch b/queue-5.15/ima-rework-config_ima-dependency-block.patch new file mode 100644 index 00000000000..b3484bd85bc --- /dev/null +++ b/queue-5.15/ima-rework-config_ima-dependency-block.patch @@ -0,0 +1,141 @@ +From fab09a272ca936b0144d08d4827493784e36bc9f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Sep 2023 09:22:14 +0200 +Subject: ima: rework CONFIG_IMA dependency block + +From: Arnd Bergmann + +[ 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 +Signed-off-by: Mimi Zohar +Signed-off-by: Sasha Levin +--- + security/integrity/ima/Kconfig | 18 ++++++------------ + 1 file changed, 6 insertions(+), 12 deletions(-) + +diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig +index 2200262489103..17d1290c1b642 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 + +@@ -322,7 +315,8 @@ config IMA_SECURE_AND_OR_TRUSTED_BOOT + + config IMA_DISABLE_HTABLE + bool "Disable htable to allow measurement of duplicate records" +- depends on IMA + default n + help + This option disables htable to allow measurement of duplicate records. ++ ++endif +-- +2.40.1 + diff --git a/queue-5.15/ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch b/queue-5.15/ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch new file mode 100644 index 00000000000..e484f4fecb1 --- /dev/null +++ b/queue-5.15/ipv4-ipv6-fix-handling-of-transhdrlen-in-__ip-6-_app.patch @@ -0,0 +1,81 @@ +From 554ca41f45686daeb8f0d687756c1b9b86bd9195 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 21 Sep 2023 11:41:19 +0100 +Subject: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() + +From: David Howells + +[ 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 +Signed-off-by: David Howells +cc: Eric Dumazet +cc: Willem de Bruijn +cc: "David S. Miller" +cc: David Ahern +cc: Paolo Abeni +cc: Jakub Kicinski +cc: netdev@vger.kernel.org +cc: bpf@vger.kernel.org +cc: syzkaller-bugs@googlegroups.com +Reviewed-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/ipv4-set-offload_failed-flag-in-fibmatch-results.patch b/queue-5.15/ipv4-set-offload_failed-flag-in-fibmatch-results.patch new file mode 100644 index 00000000000..43a08fd17d8 --- /dev/null +++ b/queue-5.15/ipv4-set-offload_failed-flag-in-fibmatch-results.patch @@ -0,0 +1,57 @@ +From 398b07889724d235ad0242ccffdbe86280c35c92 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 26 Sep 2023 14:27:30 -0400 +Subject: ipv4: Set offload_failed flag in fibmatch results + +From: Benjamin Poirier + +[ Upstream commit 0add5c597f3253a9c6108a0a81d57f44ab0d9d30 ] + +Due to a small omission, the offload_failed flag is missing from ipv4 +fibmatch results. Make sure it is set correctly. + +The issue can be witnessed using the following commands: +echo "1 1" > /sys/bus/netdevsim/new_device +ip link add dummy1 up type dummy +ip route add 192.0.2.0/24 dev dummy1 +echo 1 > /sys/kernel/debug/netdevsim/netdevsim1/fib/fail_route_offload +ip route add 198.51.100.0/24 dev dummy1 +ip route + # 192.168.15.0/24 has rt_trap + # 198.51.100.0/24 has rt_offload_failed +ip route get 192.168.15.1 fibmatch + # Result has rt_trap +ip route get 198.51.100.1 fibmatch + # Result differs from the route shown by `ip route`, it is missing + # rt_offload_failed +ip link del dev dummy1 +echo 1 > /sys/bus/netdevsim/del_device + +Fixes: 36c5100e859d ("IPv4: Add "offload failed" indication to routes") +Signed-off-by: Benjamin Poirier +Reviewed-by: Ido Schimmel +Reviewed-by: Simon Horman +Reviewed-by: David Ahern +Link: https://lore.kernel.org/r/20230926182730.231208-1-bpoirier@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/route.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/ipv4/route.c b/net/ipv4/route.c +index 968cc4aa6e96c..ea5329cb0fce2 100644 +--- a/net/ipv4/route.c ++++ b/net/ipv4/route.c +@@ -3430,6 +3430,8 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh, + fa->fa_type == fri.type) { + fri.offload = READ_ONCE(fa->offload); + fri.trap = READ_ONCE(fa->trap); ++ fri.offload_failed = ++ READ_ONCE(fa->offload_failed); + break; + } + } +-- +2.40.1 + diff --git a/queue-5.15/iwlwifi-avoid-void-pointer-arithmetic.patch b/queue-5.15/iwlwifi-avoid-void-pointer-arithmetic.patch new file mode 100644 index 00000000000..0b38ed7abd6 --- /dev/null +++ b/queue-5.15/iwlwifi-avoid-void-pointer-arithmetic.patch @@ -0,0 +1,229 @@ +From abc7ba2710aeecaa3bfafdf0739585bc542dafe5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 28 Jan 2022 15:34:29 +0200 +Subject: iwlwifi: avoid void pointer arithmetic + +From: Johannes Berg + +[ Upstream commit 3827cb59b3b8ce4b1687385d35034dadcd90d7ce ] + +Avoid void pointer arithmetic since it's technically +undefined and causes warnings in some places that use +our code. + +Signed-off-by: Johannes Berg +Signed-off-by: Luca Coelho +Link: https://lore.kernel.org/r/iwlwifi.20220128153014.e349104ecd94.Iadc937f475158b9437becdfefb361a97e7eaa934@changeid +Signed-off-by: Luca Coelho +Stable-dep-of: 8ba438ef3cac ("wifi: iwlwifi: mvm: Fix a memory corruption issue") +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 2 +- + drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 2 +- + drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 2 +- + drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 +- + drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 4 ++-- + drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 4 ++-- + drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 2 +- + drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 +- + drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- + drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +- + drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 2 +- + drivers/net/wireless/intel/iwlwifi/queue/tx.c | 6 +++--- + drivers/net/wireless/intel/iwlwifi/queue/tx.h | 2 +- + 13 files changed, 17 insertions(+), 17 deletions(-) + +diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c +index c69f3fb833327..f34a02b33ccd4 100644 +--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c ++++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c +@@ -1960,7 +1960,7 @@ static u32 iwl_dump_ini_mem(struct iwl_fw_runtime *fwrt, struct list_head *list, + struct iwl_fw_ini_error_dump_header *header; + u32 type = le32_to_cpu(reg->type), id = le32_to_cpu(reg->id); + u32 num_of_ranges, i, size; +- void *range; ++ u8 *range; + + /* + * The higher part of the ID in version 2 is irrelevant for +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c +index 6dde3bd8f4416..27756e47f7caf 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c +@@ -1090,7 +1090,7 @@ static int iwl_mvm_wowlan_config_key_params(struct iwl_mvm *mvm, + sizeof(struct iwl_wowlan_kek_kck_material_cmd_v2); + /* skip the sta_id at the beginning */ + _kek_kck_cmd = (void *) +- ((u8 *)_kek_kck_cmd) + sizeof(kek_kck_cmd.sta_id); ++ ((u8 *)_kek_kck_cmd + sizeof(kek_kck_cmd.sta_id)); + } + + IWL_DEBUG_WOWLAN(mvm, "setting akm %d\n", +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c +index 0f5c4c2510ef1..3c8eeb565135a 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c +@@ -1950,7 +1950,7 @@ static ssize_t iwl_dbgfs_mem_read(struct file *file, char __user *user_buf, + goto out; + } + +- ret = len - copy_to_user(user_buf, (void *)rsp->data + delta, len); ++ ret = len - copy_to_user(user_buf, (u8 *)rsp->data + delta, len); + *ppos += ret; + + out: +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +index 6d439ae7b50b1..f347723092eee 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +@@ -686,7 +686,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm) + mvm->nvm_data->bands[0].n_channels = 1; + mvm->nvm_data->bands[0].n_bitrates = 1; + mvm->nvm_data->bands[0].bitrates = +- (void *)mvm->nvm_data->channels + 1; ++ (void *)((u8 *)mvm->nvm_data->channels + 1); + mvm->nvm_data->bands[0].bitrates->hw_value = 10; + } + +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c +index 8ef5399ad9be6..d779e5e19568b 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c +@@ -83,8 +83,8 @@ static void iwl_mvm_pass_packet_to_mac80211(struct iwl_mvm *mvm, + fraglen = len - hdrlen; + + if (fraglen) { +- int offset = (void *)hdr + hdrlen - +- rxb_addr(rxb) + rxb_offset(rxb); ++ int offset = (u8 *)hdr + hdrlen - ++ (u8 *)rxb_addr(rxb) + rxb_offset(rxb); + + skb_add_rx_frag(skb, 0, rxb_steal_page(rxb), offset, + fraglen, rxb->truesize); +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +index 411254e9e603f..2e3eb7402197f 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +@@ -220,8 +220,8 @@ static int iwl_mvm_create_skb(struct iwl_mvm *mvm, struct sk_buff *skb, + fraglen = len - headlen; + + if (fraglen) { +- int offset = (void *)hdr + headlen + pad_len - +- rxb_addr(rxb) + rxb_offset(rxb); ++ int offset = (u8 *)hdr + headlen + pad_len - ++ (u8 *)rxb_addr(rxb) + rxb_offset(rxb); + + skb_add_rx_frag(skb, 0, rxb_steal_page(rxb), offset, + fraglen, rxb->truesize); +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c +index 65e382756de68..e4fd58f043ce2 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c +@@ -2150,7 +2150,7 @@ static int iwl_mvm_scan_umac(struct iwl_mvm *mvm, struct ieee80211_vif *vif, + struct iwl_scan_req_umac *cmd = mvm->scan_cmd; + struct iwl_scan_umac_chan_param *chan_param; + void *cmd_data = iwl_mvm_get_scan_req_umac_data(mvm); +- void *sec_part = cmd_data + sizeof(struct iwl_scan_channel_cfg_umac) * ++ void *sec_part = (u8 *)cmd_data + sizeof(struct iwl_scan_channel_cfg_umac) * + mvm->fw->ucode_capa.n_scan_channels; + struct iwl_scan_req_umac_tail_v2 *tail_v2 = + (struct iwl_scan_req_umac_tail_v2 *)sec_part; +diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h +index a43e56c7689f3..6dce36d326935 100644 +--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h +@@ -363,7 +363,7 @@ struct iwl_trans_pcie { + + /* PCI bus related data */ + struct pci_dev *pci_dev; +- void __iomem *hw_base; ++ u8 __iomem *hw_base; + + bool ucode_write_complete; + bool sx_complete; +diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c +index 6c6512158813b..f82fb17450165 100644 +--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c +@@ -727,7 +727,7 @@ static int iwl_pcie_alloc_rxq_dma(struct iwl_trans *trans, + goto err; + } + +- rxq->rb_stts = trans_pcie->base_rb_stts + rxq->id * rb_stts_size; ++ rxq->rb_stts = (u8 *)trans_pcie->base_rb_stts + rxq->id * rb_stts_size; + rxq->rb_stts_dma = + trans_pcie->base_rb_stts_dma + rxq->id * rb_stts_size; + +diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c +index 04e1f3829e96b..4456aef930cf4 100644 +--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c +@@ -2798,7 +2798,7 @@ static ssize_t iwl_dbgfs_monitor_data_read(struct file *file, + { + struct iwl_trans *trans = file->private_data; + struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans); +- void *cpu_addr = (void *)trans->dbg.fw_mon.block, *curr_buf; ++ u8 *cpu_addr = (void *)trans->dbg.fw_mon.block, *curr_buf; + struct cont_rec *data = &trans_pcie->fw_mon_data; + u32 write_ptr_addr, wrap_cnt_addr, write_ptr, wrap_cnt; + ssize_t size, bytes_copied = 0; +diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c +index 4f6c187eed69c..76d25c62a28e2 100644 +--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c +@@ -154,7 +154,7 @@ static int iwl_pcie_txq_build_tfd(struct iwl_trans *trans, struct iwl_txq *txq, + void *tfd; + u32 num_tbs; + +- tfd = txq->tfds + trans->txqs.tfd.size * txq->write_ptr; ++ tfd = (u8 *)txq->tfds + trans->txqs.tfd.size * txq->write_ptr; + + if (reset) + memset(tfd, 0, trans->txqs.tfd.size); +diff --git a/drivers/net/wireless/intel/iwlwifi/queue/tx.c b/drivers/net/wireless/intel/iwlwifi/queue/tx.c +index 0f3526b0c5b00..8522cdfc9e5d3 100644 +--- a/drivers/net/wireless/intel/iwlwifi/queue/tx.c ++++ b/drivers/net/wireless/intel/iwlwifi/queue/tx.c +@@ -189,7 +189,7 @@ static struct page *get_workaround_page(struct iwl_trans *trans, + return NULL; + + /* set the chaining pointer to the previous page if there */ +- *(void **)(page_address(ret) + PAGE_SIZE - sizeof(void *)) = *page_ptr; ++ *(void **)((u8 *)page_address(ret) + PAGE_SIZE - sizeof(void *)) = *page_ptr; + *page_ptr = ret; + + return ret; +@@ -314,7 +314,7 @@ struct iwl_tso_hdr_page *get_page_hdr(struct iwl_trans *trans, size_t len, + return NULL; + p->pos = page_address(p->page); + /* set the chaining pointer to NULL */ +- *(void **)(page_address(p->page) + PAGE_SIZE - sizeof(void *)) = NULL; ++ *(void **)((u8 *)page_address(p->page) + PAGE_SIZE - sizeof(void *)) = NULL; + out: + *page_ptr = p->page; + get_page(p->page); +@@ -963,7 +963,7 @@ void iwl_txq_free_tso_page(struct iwl_trans *trans, struct sk_buff *skb) + while (next) { + struct page *tmp = next; + +- next = *(void **)(page_address(next) + PAGE_SIZE - ++ next = *(void **)((u8 *)page_address(next) + PAGE_SIZE - + sizeof(void *)); + __free_page(tmp); + } +diff --git a/drivers/net/wireless/intel/iwlwifi/queue/tx.h b/drivers/net/wireless/intel/iwlwifi/queue/tx.h +index 20efc62acf133..19178c88bb229 100644 +--- a/drivers/net/wireless/intel/iwlwifi/queue/tx.h ++++ b/drivers/net/wireless/intel/iwlwifi/queue/tx.h +@@ -41,7 +41,7 @@ static inline void *iwl_txq_get_tfd(struct iwl_trans *trans, + if (trans->trans_cfg->use_tfh) + idx = iwl_txq_get_cmd_index(txq, idx); + +- return txq->tfds + trans->txqs.tfd.size * idx; ++ return (u8 *)txq->tfds + trans->txqs.tfd.size * idx; + } + + int iwl_txq_alloc(struct iwl_trans *trans, struct iwl_txq *txq, int slots_num, +-- +2.40.1 + diff --git a/queue-5.15/modpost-add-missing-else-to-the-of-check.patch b/queue-5.15/modpost-add-missing-else-to-the-of-check.patch new file mode 100644 index 00000000000..fb7d342eb1a --- /dev/null +++ b/queue-5.15/modpost-add-missing-else-to-the-of-check.patch @@ -0,0 +1,54 @@ +From 00e36807086373f55b0e1472fd607b41de15b943 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 28 Sep 2023 17:28:07 -0300 +Subject: modpost: add missing else to the "of" check + +From: Mauricio Faria de Oliveira + +[ 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 +Signed-off-by: Masahiro Yamada +Signed-off-by: Sasha Levin +--- + 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 49aba862073e0..05089ef5cc0ec 100644 +--- a/scripts/mod/file2alias.c ++++ b/scripts/mod/file2alias.c +@@ -1547,7 +1547,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 + diff --git a/queue-5.15/net-dsa-mv88e6xxx-avoid-eeprom-timeout-when-eeprom-i.patch b/queue-5.15/net-dsa-mv88e6xxx-avoid-eeprom-timeout-when-eeprom-i.patch new file mode 100644 index 00000000000..1139e3e53e9 --- /dev/null +++ b/queue-5.15/net-dsa-mv88e6xxx-avoid-eeprom-timeout-when-eeprom-i.patch @@ -0,0 +1,175 @@ +From fe4dce644dbff52d0e25f0d00f06e0373166cba2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 22 Sep 2023 09:47:41 -0300 +Subject: net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent + +From: Fabio Estevam + +[ 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 +Signed-off-by: Fabio Estevam +Reviewed-by: Florian Fainelli +Reviewed-by: Andrew Lunn +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 7e93b72f9b541..30fba1ea933e3 100644 +--- a/drivers/net/dsa/mv88e6xxx/chip.c ++++ b/drivers/net/dsa/mv88e6xxx/chip.c +@@ -2594,14 +2594,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 5848112036b08..964928285782c 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 4f3dbb015f77b..6f41762eff3e6 100644 +--- a/drivers/net/dsa/mv88e6xxx/global1.h ++++ b/drivers/net/dsa/mv88e6xxx/global1.h +@@ -280,7 +280,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 ec49939968fac..ac302a935ce69 100644 +--- a/drivers/net/dsa/mv88e6xxx/global2.c ++++ b/drivers/net/dsa/mv88e6xxx/global2.c +@@ -340,7 +340,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 89ba09b663a26..f492048db0c13 100644 +--- a/drivers/net/dsa/mv88e6xxx/global2.h ++++ b/drivers/net/dsa/mv88e6xxx/global2.h +@@ -357,6 +357,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 + diff --git a/queue-5.15/net-ethernet-ti-am65-cpsw-fix-error-code-in-am65_cps.patch b/queue-5.15/net-ethernet-ti-am65-cpsw-fix-error-code-in-am65_cps.patch new file mode 100644 index 00000000000..45041f45e36 --- /dev/null +++ b/queue-5.15/net-ethernet-ti-am65-cpsw-fix-error-code-in-am65_cps.patch @@ -0,0 +1,37 @@ +From 91b1c5dbdbf8bb09dd826cd3ee9675fec582c77f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Roger Quadros +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 daf0779261f3e..4aa9477ac5977 100644 +--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c ++++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c +@@ -1619,6 +1619,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 + diff --git a/queue-5.15/net-fix-possible-store-tearing-in-neigh_periodic_wor.patch b/queue-5.15/net-fix-possible-store-tearing-in-neigh_periodic_wor.patch new file mode 100644 index 00000000000..3a966980358 --- /dev/null +++ b/queue-5.15/net-fix-possible-store-tearing-in-neigh_periodic_wor.patch @@ -0,0 +1,48 @@ +From 3621dbbc760dba332199abc5dd8de07dc4653879 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 21 Sep 2023 08:46:26 +0000 +Subject: net: fix possible store tearing in neigh_periodic_work() + +From: Eric Dumazet + +[ 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 +Reviewed-by: David Ahern +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + 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 af022db48b7a9..a385086091fd3 100644 +--- a/net/core/neighbour.c ++++ b/net/core/neighbour.c +@@ -930,7 +930,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 + diff --git a/queue-5.15/net-nfc-llcp-add-lock-when-modifying-device-list.patch b/queue-5.15/net-nfc-llcp-add-lock-when-modifying-device-list.patch new file mode 100644 index 00000000000..1557dad1196 --- /dev/null +++ b/queue-5.15/net-nfc-llcp-add-lock-when-modifying-device-list.patch @@ -0,0 +1,41 @@ +From 35c81a8d7f26ae1a25e91e3163e28732321f8e54 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 8 Sep 2023 19:58:53 -0400 +Subject: net: nfc: llcp: Add lock when modifying device list + +From: Jeremy Cline + +[ 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 +Reviewed-by: Simon Horman +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/net-stmmac-dwmac-stm32-fix-resume-on-stm32-mcu.patch b/queue-5.15/net-stmmac-dwmac-stm32-fix-resume-on-stm32-mcu.patch new file mode 100644 index 00000000000..72d13056162 --- /dev/null +++ b/queue-5.15/net-stmmac-dwmac-stm32-fix-resume-on-stm32-mcu.patch @@ -0,0 +1,68 @@ +From 1e24ea893798c57d3f26d76efa39f7c07b5fb91b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Sep 2023 13:57:49 -0400 +Subject: net: stmmac: dwmac-stm32: fix resume on STM32 MCU + +From: Ben Wolsieffer + +[ 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 +Reviewed-by: Jacob Keller +Link: https://lore.kernel.org/r/20230927175749.1419774-1-ben.wolsieffer@hefring.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 2b38a499a4045..533f5245ad945 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 + diff --git a/queue-5.15/net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch b/queue-5.15/net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch new file mode 100644 index 00000000000..b5cf3c0aeac --- /dev/null +++ b/queue-5.15/net-usb-smsc75xx-fix-uninit-value-access-in-__smsc75.patch @@ -0,0 +1,99 @@ +From 546b15f2e9263233659ad7cce73f67999b33b4ab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 24 Sep 2023 02:35:49 +0900 +Subject: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg + +From: Shigeru Yoshida + +[ 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 +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20230923173549.3284502-1-syoshida@redhat.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + 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 7c3e866514199..301d979d0d08c 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 + diff --git a/queue-5.15/netfilter-handle-the-connecting-collision-properly-i.patch b/queue-5.15/netfilter-handle-the-connecting-collision-properly-i.patch new file mode 100644 index 00000000000..8a72c22d9d3 --- /dev/null +++ b/queue-5.15/netfilter-handle-the-connecting-collision-properly-i.patch @@ -0,0 +1,175 @@ +From 809b9b5f30a109b4cecc214cdbe3f37e74971de4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 3 Oct 2023 13:17:53 -0400 +Subject: netfilter: handle the connecting collision properly in + nf_conntrack_proto_sctp + +From: Xin Long + +[ 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 +Signed-off-by: Florian Westphal +Signed-off-by: Sasha Levin +--- + 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 7247af51bdfc4..c94a9971d790c 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 + diff --git a/queue-5.15/netfilter-nf_tables-nft_set_rbtree-fix-spurious-inse.patch b/queue-5.15/netfilter-nf_tables-nft_set_rbtree-fix-spurious-inse.patch new file mode 100644 index 00000000000..73dadb44980 --- /dev/null +++ b/queue-5.15/netfilter-nf_tables-nft_set_rbtree-fix-spurious-inse.patch @@ -0,0 +1,181 @@ +From 0887bf989bc6bc8468581d9b2b91dd48131e77da Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 28 Sep 2023 15:12:44 +0200 +Subject: netfilter: nf_tables: nft_set_rbtree: fix spurious insertion failure + +From: Florian Westphal + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 487572dcd6144..2660ceab3759d 100644 +--- a/net/netfilter/nft_set_rbtree.c ++++ b/net/netfilter/nft_set_rbtree.c +@@ -233,10 +233,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); +@@ -246,7 +245,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 +@@ -261,6 +260,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); +@@ -272,7 +272,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); + } +@@ -280,13 +280,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, +@@ -314,7 +314,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 +@@ -363,9 +363,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; + } +@@ -486,11 +491,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 + diff --git a/queue-5.15/nfsv4-fix-a-nfs4_state_manager-race.patch b/queue-5.15/nfsv4-fix-a-nfs4_state_manager-race.patch new file mode 100644 index 00000000000..70003b0ce3e --- /dev/null +++ b/queue-5.15/nfsv4-fix-a-nfs4_state_manager-race.patch @@ -0,0 +1,43 @@ +From 23ab5907b1fefd631ebcc5c892fb08a2b9242a64 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 17 Sep 2023 19:05:50 -0400 +Subject: NFSv4: Fix a nfs4_state_manager() race + +From: Trond Myklebust + +[ 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 +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4state.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c +index 7590d059eb78e..258e6b167285c 100644 +--- a/fs/nfs/nfs4state.c ++++ b/fs/nfs/nfs4state.c +@@ -2699,6 +2699,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 + diff --git a/queue-5.15/ptp-ocp-fix-error-handling-in-ptp_ocp_device_init.patch b/queue-5.15/ptp-ocp-fix-error-handling-in-ptp_ocp_device_init.patch new file mode 100644 index 00000000000..1ef4ce7c57c --- /dev/null +++ b/queue-5.15/ptp-ocp-fix-error-handling-in-ptp_ocp_device_init.patch @@ -0,0 +1,37 @@ +From f05fd4630eac62fc8d3fb645acbab3e86047b66a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 22 Sep 2023 17:40:44 +0800 +Subject: ptp: ocp: Fix error handling in ptp_ocp_device_init + +From: Dinghao Liu + +[ Upstream commit caa0578c1d487d39e4bb947a1b4965417053b409 ] + +When device_add() fails, ptp_ocp_dev_release() will be called +after put_device(). Therefore, it seems that the +ptp_ocp_dev_release() before put_device() is redundant. + +Fixes: 773bda964921 ("ptp: ocp: Expose various resources on the timecard.") +Signed-off-by: Dinghao Liu +Reviewed-by: Vadim Feodrenko +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/ptp/ptp_ocp.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/drivers/ptp/ptp_ocp.c b/drivers/ptp/ptp_ocp.c +index e238ae8e94709..7a4a06148515a 100644 +--- a/drivers/ptp/ptp_ocp.c ++++ b/drivers/ptp/ptp_ocp.c +@@ -1292,7 +1292,6 @@ ptp_ocp_device_init(struct ptp_ocp *bp, struct pci_dev *pdev) + return 0; + + out: +- ptp_ocp_dev_release(&bp->dev); + put_device(&bp->dev); + return err; + } +-- +2.40.1 + diff --git a/queue-5.15/regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch b/queue-5.15/regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch new file mode 100644 index 00000000000..b2561bec387 --- /dev/null +++ b/queue-5.15/regmap-rbtree-fix-wrong-register-marked-as-in-cache-.patch @@ -0,0 +1,50 @@ +From 05875b0fa7af0a5a4830ee435d9f72012da27ad2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.15/scsi-target-core-fix-deadlock-due-to-recursive-locki.patch b/queue-5.15/scsi-target-core-fix-deadlock-due-to-recursive-locki.patch new file mode 100644 index 00000000000..0a6b8f430b9 --- /dev/null +++ b/queue-5.15/scsi-target-core-fix-deadlock-due-to-recursive-locki.patch @@ -0,0 +1,98 @@ +From d9c5f3f59529ba01d922cd008a4cac84cbcf6fa0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 18 Sep 2023 15:58:48 -0700 +Subject: scsi: target: core: Fix deadlock due to recursive locking + +From: Junxiao Bi + +[ 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 +Link: https://lore.kernel.org/r/20230918225848.66463-1-junxiao.bi@oracle.com +Reviewed-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + 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 e18617371a9b2..813de805f815a 100644 +--- a/drivers/target/target_core_device.c ++++ b/drivers/target/target_core_device.c +@@ -875,7 +875,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; + }; +@@ -885,11 +884,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 +@@ -899,12 +896,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; +@@ -927,7 +925,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 + diff --git a/queue-5.15/sctp-update-hb-timer-immediately-after-users-change-.patch b/queue-5.15/sctp-update-hb-timer-immediately-after-users-change-.patch new file mode 100644 index 00000000000..712a0756405 --- /dev/null +++ b/queue-5.15/sctp-update-hb-timer-immediately-after-users-change-.patch @@ -0,0 +1,48 @@ +From fb48a278e86ef882dfc4c831ba877fa77008c6b0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 1 Oct 2023 11:04:20 -0400 +Subject: sctp: update hb timer immediately after users change hb_interval + +From: Xin Long + +[ 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 +Reviewed-by: Simon Horman +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 +Signed-off-by: Sasha Levin +--- + net/sctp/socket.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/sctp/socket.c b/net/sctp/socket.c +index 36a37fef27719..57acf7ed80de3 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 + diff --git a/queue-5.15/sctp-update-transport-state-when-processing-a-dupcoo.patch b/queue-5.15/sctp-update-transport-state-when-processing-a-dupcoo.patch new file mode 100644 index 00000000000..513ba60dbb2 --- /dev/null +++ b/queue-5.15/sctp-update-transport-state-when-processing-a-dupcoo.patch @@ -0,0 +1,67 @@ +From 49db7a3d254d0fea465b3757c5979bd81ad02284 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 1 Oct 2023 10:58:45 -0400 +Subject: sctp: update transport state when processing a dupcook packet + +From: Xin Long + +[ 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 +Reviewed-by: Simon Horman +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 +Signed-off-by: Sasha Levin +--- + 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 3460abceba443..2965a12fe8aa2 100644 +--- a/net/sctp/associola.c ++++ b/net/sctp/associola.c +@@ -1161,8 +1161,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 + diff --git a/queue-5.15/series b/queue-5.15/series index 06e4d74079b..13216f5d3bb 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -16,3 +16,38 @@ rbd-decouple-parent-info-read-in-from-updating-rbd_d.patch rbd-take-header_rwsem-in-rbd_dev_refresh-only-when-u.patch block-fix-use-after-free-of-q-q_usage_counter.patch revert-clk-imx-pll14xx-dynamically-configure-pll-for-393216000-361267200hz.patch +hid-sony-fix-a-potential-memory-leak-in-sony_probe.patch +ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch +wifi-iwlwifi-dbg_ini-fix-structure-packing.patch +iwlwifi-avoid-void-pointer-arithmetic.patch +wifi-iwlwifi-mvm-fix-a-memory-corruption-issue.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 +bpf-sockmap-reject-sk_msg-egress-redirects-to-non-tc.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 +ptp-ocp-fix-error-handling-in-ptp_ocp_device_init.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 +ibmveth-remove-condition-to-recompute-tcp-header-che.patch +netfilter-handle-the-connecting-collision-properly-i.patch +netfilter-nf_tables-nft_set_rbtree-fix-spurious-inse.patch +ipv4-set-offload_failed-flag-in-fibmatch-results.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 +hid-sony-remove-duplicate-null-check-before-calling-.patch +hid-intel-ish-hid-ipc-disable-and-reenable-acpi-gpe-.patch diff --git a/queue-5.15/tcp-fix-delayed-acks-for-mss-boundary-condition.patch b/queue-5.15/tcp-fix-delayed-acks-for-mss-boundary-condition.patch new file mode 100644 index 00000000000..6ae46c37402 --- /dev/null +++ b/queue-5.15/tcp-fix-delayed-acks-for-mss-boundary-condition.patch @@ -0,0 +1,99 @@ +From 071e226877f1d1ad271099a65298368519af817e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 1 Oct 2023 11:12:39 -0400 +Subject: tcp: fix delayed ACKs for MSS boundary condition + +From: Neal Cardwell + +[ 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 +Reviewed-by: Yuchung Cheng +Reviewed-by: Eric Dumazet +Cc: Xin Guo +Link: https://lore.kernel.org/r/20231001151239.1866845-2-ncardwell.sw@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 94633f499e148..d1e431ad5f619 100644 +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -243,6 +243,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 + diff --git a/queue-5.15/tcp-fix-quick-ack-counting-to-count-actual-acks-of-n.patch b/queue-5.15/tcp-fix-quick-ack-counting-to-count-actual-acks-of-n.patch new file mode 100644 index 00000000000..d5100b20129 --- /dev/null +++ b/queue-5.15/tcp-fix-quick-ack-counting-to-count-actual-acks-of-n.patch @@ -0,0 +1,102 @@ +From 4941ce9ec5d5b92c9ebc4066607c00621f266d77 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Yuchung Cheng +Reviewed-by: Eric Dumazet +Link: https://lore.kernel.org/r/20231001151239.1866845-1-ncardwell.sw@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 4aafda05a6466..4d8c915a7bfac 100644 +--- a/include/net/tcp.h ++++ b/include/net/tcp.h +@@ -340,12 +340,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 d46fb6d7057bd..880b53bb6b64d 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 + diff --git a/queue-5.15/tipc-fix-a-potential-deadlock-on-tx-lock.patch b/queue-5.15/tipc-fix-a-potential-deadlock-on-tx-lock.patch new file mode 100644 index 00000000000..2ebd77959e5 --- /dev/null +++ b/queue-5.15/tipc-fix-a-potential-deadlock-on-tx-lock.patch @@ -0,0 +1,70 @@ +From e4e572c8a62e34d98ed81883e08d6a5565780c62 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Sep 2023 18:14:14 +0000 +Subject: tipc: fix a potential deadlock on &tx->lock + +From: Chengfeng Ye + +[ 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() +--> 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) + + --> tipc_disc_timeout() + --> tipc_bearer_xmit_skb() + --> tipc_crypto_xmit() + --> tipc_ehdr_build() + --> tipc_crypto_key_revoke() + --> spin_lock(&tx->lock) + +Signed-off-by: Chengfeng Ye +Reviewed-by: Jacob Keller +Acked-by: Jon Maloy +Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") +Link: https://lore.kernel.org/r/20230927181414.59928-1-dg573847474@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + 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 32447e8d94ac9..86d1e782b8fca 100644 +--- a/net/tipc/crypto.c ++++ b/net/tipc/crypto.c +@@ -1452,14 +1452,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 + diff --git a/queue-5.15/ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch b/queue-5.15/ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch new file mode 100644 index 00000000000..a1be4cc788b --- /dev/null +++ b/queue-5.15/ubi-refuse-attaching-if-mtd-s-erasesize-is-0.patch @@ -0,0 +1,45 @@ +From 6aa800b0fa971afbe2d592b4f411c48d9219210a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 23 Apr 2023 19:10:41 +0800 +Subject: ubi: Refuse attaching if mtd's erasesize is 0 + +From: Zhihao Cheng + +[ 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 +Link: https://lore.kernel.org/lkml/977347543.226888.1682011999468.JavaMail.zimbra@nod.at/T/ +Signed-off-by: Zhihao Cheng +Reviewed-by: Miquel Raynal +Signed-off-by: Richard Weinberger +Signed-off-by: Sasha Levin +--- + 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 762dc14aef742..8b247ce73bb6e 100644 +--- a/drivers/mtd/ubi/build.c ++++ b/drivers/mtd/ubi/build.c +@@ -888,6 +888,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 + diff --git a/queue-5.15/wifi-iwlwifi-dbg_ini-fix-structure-packing.patch b/queue-5.15/wifi-iwlwifi-dbg_ini-fix-structure-packing.patch new file mode 100644 index 00000000000..a1f8d01f9e3 --- /dev/null +++ b/queue-5.15/wifi-iwlwifi-dbg_ini-fix-structure-packing.patch @@ -0,0 +1,50 @@ +From d4a69c5249897ac87b359b0a2e77466cb057a8bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Jun 2023 11:03:34 +0200 +Subject: wifi: iwlwifi: dbg_ini: fix structure packing + +From: Arnd Bergmann + +[ 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 +Acked-by: Gregory Greenman +Link: https://lore.kernel.org/r/20230616090343.2454061-1-arnd@kernel.org +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + 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 521ca2bb0e928..2cdc3caf7740d 100644 +--- a/drivers/net/wireless/intel/iwlwifi/fw/error-dump.h ++++ b/drivers/net/wireless/intel/iwlwifi/fw/error-dump.h +@@ -277,9 +277,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 + diff --git a/queue-5.15/wifi-iwlwifi-mvm-fix-a-memory-corruption-issue.patch b/queue-5.15/wifi-iwlwifi-mvm-fix-a-memory-corruption-issue.patch new file mode 100644 index 00000000000..b526e28e458 --- /dev/null +++ b/queue-5.15/wifi-iwlwifi-mvm-fix-a-memory-corruption-issue.patch @@ -0,0 +1,63 @@ +From e3020ca60fea8ebe513177c8913236191b18f7d2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 23 Jul 2023 22:24:59 +0200 +Subject: wifi: iwlwifi: mvm: Fix a memory corruption issue + +From: Christophe JAILLET + +[ Upstream commit 8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d ] + +A few lines above, space is kzalloc()'ed for: + sizeof(struct iwl_nvm_data) + + sizeof(struct ieee80211_channel) + + sizeof(struct ieee80211_rate) + +'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. + +At the end of this structure, there is the 'channels' flex array. +Each element is of type 'struct ieee80211_channel'. +So only 1 element is allocated in this array. + +When doing: + mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; +We point at the first element of the 'channels' flex array. +So this is fine. + +However, when doing: + mvm->nvm_data->bands[0].bitrates = + (void *)((u8 *)mvm->nvm_data->channels + 1); +because of the "(u8 *)" cast, we add only 1 to the address of the beginning +of the flex array. + +It is likely that we want point at the 'struct ieee80211_rate' allocated +just after. + +Remove the spurious casting so that the pointer arithmetic works as +expected. + +Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver") +Signed-off-by: Christophe JAILLET +Acked-by: Gregory Greenman +Link: https://lore.kernel.org/r/23f0ec986ef1529055f4f93dcb3940a6cf8d9a94.1690143750.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +index f347723092eee..d22a5628f9e0d 100644 +--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c +@@ -686,7 +686,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm) + mvm->nvm_data->bands[0].n_channels = 1; + mvm->nvm_data->bands[0].n_bitrates = 1; + mvm->nvm_data->bands[0].bitrates = +- (void *)((u8 *)mvm->nvm_data->channels + 1); ++ (void *)(mvm->nvm_data->channels + 1); + mvm->nvm_data->bands[0].bitrates->hw_value = 10; + } + +-- +2.40.1 + diff --git a/queue-5.15/wifi-mt76-mt76x02-fix-mt76x0-external-lna-gain-handl.patch b/queue-5.15/wifi-mt76-mt76x02-fix-mt76x0-external-lna-gain-handl.patch new file mode 100644 index 00000000000..fcc10cf6e5d --- /dev/null +++ b/queue-5.15/wifi-mt76-mt76x02-fix-mt76x0-external-lna-gain-handl.patch @@ -0,0 +1,78 @@ +From fc2a8e396b4a8be3c92503fc03f46c981836be52 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 19 Sep 2023 21:47:47 +0200 +Subject: wifi: mt76: mt76x02: fix MT76x0 external LNA gain handling + +From: Felix Fietkau + +[ 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 +Signed-off-by: Felix Fietkau +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230919194747.31647-1-nbd@nbd.name +Signed-off-by: Sasha Levin +--- + 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 c57e05a5c65e4..91807bf662dde 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 + diff --git a/queue-5.15/wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch b/queue-5.15/wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch new file mode 100644 index 00000000000..af11fbefd18 --- /dev/null +++ b/queue-5.15/wifi-mwifiex-fix-oob-check-condition-in-mwifiex_proc.patch @@ -0,0 +1,61 @@ +From 2ef4c8c67ee41bf0c58ae86f12233d951b62a4a4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Acked-by: Brian Norris +Reviewed-by: Matthew Wang +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230908104308.1546501-1-treapking@chromium.org +Signed-off-by: Sasha Levin +--- + 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 +