From: Greg Kroah-Hartman Date: Sat, 29 Jan 2022 12:19:30 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v5.4.176~98 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=686f0e95155c43c54baa1064445c2e3eaa2cdebc;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: bluetooth-refactor-malicious-adv-data-check.patch bpf-guard-against-accessing-null-pt_regs-in-bpf_get_task_stack.patch media-venus-core-drop-second-v4l2-device-unregister.patch net-sfp-ignore-disabled-sfp-node.patch net-stmmac-skip-only-stmmac_ptp_register-when-resume-from-suspend.patch s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch s390-module-fix-loading-modules-with-a-lot-of-relocations.patch scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch udf-fix-null-ptr-deref-when-converting-from-inline-format.patch udf-restore-i_lenalloc-when-inode-expansion-fails.patch --- diff --git a/queue-5.10/bluetooth-refactor-malicious-adv-data-check.patch b/queue-5.10/bluetooth-refactor-malicious-adv-data-check.patch new file mode 100644 index 00000000000..10fbad7d818 --- /dev/null +++ b/queue-5.10/bluetooth-refactor-malicious-adv-data-check.patch @@ -0,0 +1,48 @@ +From 899663be5e75dc0174dc8bda0b5e6826edf0b29a Mon Sep 17 00:00:00 2001 +From: Brian Gix +Date: Wed, 24 Nov 2021 12:16:28 -0800 +Subject: Bluetooth: refactor malicious adv data check + +From: Brian Gix + +commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream. + +Check for out-of-bound read was being performed at the end of while +num_reports loop, and would fill journal with false positives. Added +check to beginning of loop processing so that it doesn't get checked +after ptr has been advanced. + +Signed-off-by: Brian Gix +Signed-off-by: Marcel Holtmann +Cc: syphyr +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_event.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -5661,6 +5661,11 @@ static void hci_le_adv_report_evt(struct + struct hci_ev_le_advertising_info *ev = ptr; + s8 rssi; + ++ if (ptr > (void *)skb_tail_pointer(skb) - sizeof(*ev)) { ++ bt_dev_err(hdev, "Malicious advertising data."); ++ break; ++ } ++ + if (ev->length <= HCI_MAX_AD_LENGTH && + ev->data + ev->length <= skb_tail_pointer(skb)) { + rssi = ev->data[ev->length]; +@@ -5672,11 +5677,6 @@ static void hci_le_adv_report_evt(struct + } + + ptr += sizeof(*ev) + ev->length + 1; +- +- if (ptr > (void *) skb_tail_pointer(skb) - sizeof(*ev)) { +- bt_dev_err(hdev, "Malicious advertising data. Stopping processing"); +- break; +- } + } + + hci_dev_unlock(hdev); diff --git a/queue-5.10/bpf-guard-against-accessing-null-pt_regs-in-bpf_get_task_stack.patch b/queue-5.10/bpf-guard-against-accessing-null-pt_regs-in-bpf_get_task_stack.patch new file mode 100644 index 00000000000..c7b85ea4745 --- /dev/null +++ b/queue-5.10/bpf-guard-against-accessing-null-pt_regs-in-bpf_get_task_stack.patch @@ -0,0 +1,44 @@ +From b992f01e66150fc5e90be4a96f5eb8e634c8249e Mon Sep 17 00:00:00 2001 +From: "Naveen N. Rao" +Date: Thu, 6 Jan 2022 17:15:05 +0530 +Subject: bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack() + +From: Naveen N. Rao + +commit b992f01e66150fc5e90be4a96f5eb8e634c8249e upstream. + +task_pt_regs() can return NULL on powerpc for kernel threads. This is +then used in __bpf_get_stack() to check for user mode, resulting in a +kernel oops. Guard against this by checking return value of +task_pt_regs() before trying to obtain the call chain. + +Fixes: fa28dcb82a38f8 ("bpf: Introduce helper bpf_get_task_stack()") +Cc: stable@vger.kernel.org # v5.9+ +Signed-off-by: Naveen N. Rao +Acked-by: Daniel Borkmann +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/d5ef83c361cc255494afd15ff1b4fb02a36e1dcf.1641468127.git.naveen.n.rao@linux.vnet.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/bpf/stackmap.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/kernel/bpf/stackmap.c ++++ b/kernel/bpf/stackmap.c +@@ -664,13 +664,14 @@ BPF_CALL_4(bpf_get_task_stack, struct ta + u32, size, u64, flags) + { + struct pt_regs *regs; +- long res; ++ long res = -EINVAL; + + if (!try_get_task_stack(task)) + return -EFAULT; + + regs = task_pt_regs(task); +- res = __bpf_get_stack(regs, task, NULL, buf, size, flags); ++ if (regs) ++ res = __bpf_get_stack(regs, task, NULL, buf, size, flags); + put_task_stack(task); + + return res; diff --git a/queue-5.10/media-venus-core-drop-second-v4l2-device-unregister.patch b/queue-5.10/media-venus-core-drop-second-v4l2-device-unregister.patch new file mode 100644 index 00000000000..5425a07b62b --- /dev/null +++ b/queue-5.10/media-venus-core-drop-second-v4l2-device-unregister.patch @@ -0,0 +1,33 @@ +From ddbcd0c58a6a53e2f1600b9de0ce6a20667c031c Mon Sep 17 00:00:00 2001 +From: Stanimir Varbanov +Date: Wed, 24 Mar 2021 15:59:17 +0100 +Subject: media: venus: core: Drop second v4l2 device unregister + +From: Stanimir Varbanov + +commit ddbcd0c58a6a53e2f1600b9de0ce6a20667c031c upstream. + +Wrong solution of rebase conflict leads to calling twice +v4l2_device_unregister in .venus_remove. Delete the second one. + +Signed-off-by: Stanimir Varbanov +Signed-off-by: Mauro Carvalho Chehab +Cc: Martin Faltesek +Cc: Guenter Roeck +Cc: Bryan O'Donoghue +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/core.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/media/platform/qcom/venus/core.c ++++ b/drivers/media/platform/qcom/venus/core.c +@@ -375,8 +375,6 @@ static int venus_remove(struct platform_ + + hfi_destroy(core); + +- v4l2_device_unregister(&core->v4l2_dev); +- + mutex_destroy(&core->pm_lock); + mutex_destroy(&core->lock); + venus_dbgfs_deinit(core); diff --git a/queue-5.10/net-sfp-ignore-disabled-sfp-node.patch b/queue-5.10/net-sfp-ignore-disabled-sfp-node.patch new file mode 100644 index 00000000000..aca51e3360c --- /dev/null +++ b/queue-5.10/net-sfp-ignore-disabled-sfp-node.patch @@ -0,0 +1,43 @@ +From 2148927e6ed43a1667baf7c2ae3e0e05a44b51a0 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= +Date: Wed, 19 Jan 2022 17:44:55 +0100 +Subject: net: sfp: ignore disabled SFP node +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marek Behún + +commit 2148927e6ed43a1667baf7c2ae3e0e05a44b51a0 upstream. + +Commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices +and sfp cages") added code which finds SFP bus DT node even if the node +is disabled with status = "disabled". Because of this, when phylink is +created, it ends with non-null .sfp_bus member, even though the SFP +module is not probed (because the node is disabled). + +We need to ignore disabled SFP bus node. + +Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") +Signed-off-by: Marek Behún +Cc: stable@vger.kernel.org # 2203cbf2c8b5 ("net: sfp: move fwnode parsing into sfp-bus layer") +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/sfp-bus.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/net/phy/sfp-bus.c ++++ b/drivers/net/phy/sfp-bus.c +@@ -609,6 +609,11 @@ struct sfp_bus *sfp_bus_find_fwnode(stru + else if (ret < 0) + return ERR_PTR(ret); + ++ if (!fwnode_device_is_available(ref.fwnode)) { ++ fwnode_handle_put(ref.fwnode); ++ return NULL; ++ } ++ + bus = sfp_bus_get(ref.fwnode); + fwnode_handle_put(ref.fwnode); + if (!bus) diff --git a/queue-5.10/net-stmmac-skip-only-stmmac_ptp_register-when-resume-from-suspend.patch b/queue-5.10/net-stmmac-skip-only-stmmac_ptp_register-when-resume-from-suspend.patch new file mode 100644 index 00000000000..e7746a56100 --- /dev/null +++ b/queue-5.10/net-stmmac-skip-only-stmmac_ptp_register-when-resume-from-suspend.patch @@ -0,0 +1,75 @@ +From 0735e639f129dff455aeb91da291f5c578cc33db Mon Sep 17 00:00:00 2001 +From: Mohammad Athari Bin Ismail +Date: Wed, 26 Jan 2022 17:47:23 +0800 +Subject: net: stmmac: skip only stmmac_ptp_register when resume from suspend + +From: Mohammad Athari Bin Ismail + +commit 0735e639f129dff455aeb91da291f5c578cc33db upstream. + +When resume from suspend, besides skipping PTP registration, it also +skipping PTP HW initialization. This could cause PTP clock not able to +operate properly when resume from suspend. + +To fix this, only stmmac_ptp_register() is skipped when resume from +suspend. + +Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation") +Cc: # 5.15.x +Signed-off-by: Mohammad Athari Bin Ismail +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 +++++++++----------- + 1 file changed, 9 insertions(+), 11 deletions(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +@@ -816,8 +816,6 @@ static int stmmac_init_ptp(struct stmmac + priv->hwts_tx_en = 0; + priv->hwts_rx_en = 0; + +- stmmac_ptp_register(priv); +- + return 0; + } + +@@ -2691,7 +2689,7 @@ static void stmmac_safety_feat_configura + /** + * stmmac_hw_setup - setup mac in a usable state. + * @dev : pointer to the device structure. +- * @init_ptp: initialize PTP if set ++ * @ptp_register: register PTP if set + * Description: + * this is the main function to setup the HW in a usable state because the + * dma engine is reset, the core registers are configured (e.g. AXI, +@@ -2701,7 +2699,7 @@ static void stmmac_safety_feat_configura + * 0 on success and an appropriate (-)ve integer as defined in errno.h + * file on failure. + */ +-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp) ++static int stmmac_hw_setup(struct net_device *dev, bool ptp_register) + { + struct stmmac_priv *priv = netdev_priv(dev); + u32 rx_cnt = priv->plat->rx_queues_to_use; +@@ -2757,13 +2755,13 @@ static int stmmac_hw_setup(struct net_de + + stmmac_mmc_setup(priv); + +- if (init_ptp) { +- ret = stmmac_init_ptp(priv); +- if (ret == -EOPNOTSUPP) +- netdev_warn(priv->dev, "PTP not supported by HW\n"); +- else if (ret) +- netdev_warn(priv->dev, "PTP init failed\n"); +- } ++ ret = stmmac_init_ptp(priv); ++ if (ret == -EOPNOTSUPP) ++ netdev_warn(priv->dev, "PTP not supported by HW\n"); ++ else if (ret) ++ netdev_warn(priv->dev, "PTP init failed\n"); ++ else if (ptp_register) ++ stmmac_ptp_register(priv); + + priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS; + diff --git a/queue-5.10/s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch b/queue-5.10/s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch new file mode 100644 index 00000000000..8a2a60e1939 --- /dev/null +++ b/queue-5.10/s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch @@ -0,0 +1,51 @@ +From 663d34c8df98740f1e90241e78e456d00b3c6cad Mon Sep 17 00:00:00 2001 +From: Vasily Gorbik +Date: Thu, 20 Jan 2022 16:23:19 +0100 +Subject: s390/hypfs: include z/VM guests with access control group set + +From: Vasily Gorbik + +commit 663d34c8df98740f1e90241e78e456d00b3c6cad upstream. + +Currently if z/VM guest is allowed to retrieve hypervisor performance +data globally for all guests (privilege class B) the query is formed in a +way to include all guests but the group name is left empty. This leads to +that z/VM guests which have access control group set not being included +in the results (even local vm). + +Change the query group identifier from empty to "any" to retrieve +information about all guests from any groups (or without a group set). + +Cc: stable@vger.kernel.org +Fixes: 31cb4bd31a48 ("[S390] Hypervisor filesystem (s390_hypfs) for z/VM") +Reviewed-by: Gerald Schaefer +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/hypfs/hypfs_vm.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/arch/s390/hypfs/hypfs_vm.c ++++ b/arch/s390/hypfs/hypfs_vm.c +@@ -20,6 +20,7 @@ + + static char local_guest[] = " "; + static char all_guests[] = "* "; ++static char *all_groups = all_guests; + static char *guest_query; + + struct diag2fc_data { +@@ -62,10 +63,11 @@ static int diag2fc(int size, char* query + + memcpy(parm_list.userid, query, NAME_LEN); + ASCEBC(parm_list.userid, NAME_LEN); +- parm_list.addr = (unsigned long) addr ; ++ memcpy(parm_list.aci_grp, all_groups, NAME_LEN); ++ ASCEBC(parm_list.aci_grp, NAME_LEN); ++ parm_list.addr = (unsigned long)addr; + parm_list.size = size; + parm_list.fmt = 0x02; +- memset(parm_list.aci_grp, 0x40, NAME_LEN); + rc = -1; + + diag_stat_inc(DIAG_STAT_X2FC); diff --git a/queue-5.10/s390-module-fix-loading-modules-with-a-lot-of-relocations.patch b/queue-5.10/s390-module-fix-loading-modules-with-a-lot-of-relocations.patch new file mode 100644 index 00000000000..2097c910ced --- /dev/null +++ b/queue-5.10/s390-module-fix-loading-modules-with-a-lot-of-relocations.patch @@ -0,0 +1,84 @@ +From f3b7e73b2c6619884351a3a0a7468642f852b8a2 Mon Sep 17 00:00:00 2001 +From: Ilya Leoshkevich +Date: Wed, 19 Jan 2022 19:26:37 +0100 +Subject: s390/module: fix loading modules with a lot of relocations + +From: Ilya Leoshkevich + +commit f3b7e73b2c6619884351a3a0a7468642f852b8a2 upstream. + +If the size of the PLT entries generated by apply_rela() exceeds +64KiB, the first ones can no longer reach __jump_r1 with brc. Fix by +using brcl. An alternative solution is to add a __jump_r1 copy after +every 64KiB, however, the space savings are quite small and do not +justify the additional complexity. + +Fixes: f19fbd5ed642 ("s390: introduce execute-trampolines for branches") +Cc: stable@vger.kernel.org +Reported-by: Andrea Righi +Signed-off-by: Ilya Leoshkevich +Reviewed-by: Heiko Carstens +Cc: Vasily Gorbik +Cc: Christian Borntraeger +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/kernel/module.c | 37 ++++++++++++++++++------------------- + 1 file changed, 18 insertions(+), 19 deletions(-) + +--- a/arch/s390/kernel/module.c ++++ b/arch/s390/kernel/module.c +@@ -30,7 +30,7 @@ + #define DEBUGP(fmt , ...) + #endif + +-#define PLT_ENTRY_SIZE 20 ++#define PLT_ENTRY_SIZE 22 + + void *module_alloc(unsigned long size) + { +@@ -330,27 +330,26 @@ static int apply_rela(Elf_Rela *rela, El + case R_390_PLTOFF32: /* 32 bit offset from GOT to PLT. */ + case R_390_PLTOFF64: /* 16 bit offset from GOT to PLT. */ + if (info->plt_initialized == 0) { +- unsigned int insn[5]; +- unsigned int *ip = me->core_layout.base + +- me->arch.plt_offset + +- info->plt_offset; +- +- insn[0] = 0x0d10e310; /* basr 1,0 */ +- insn[1] = 0x100a0004; /* lg 1,10(1) */ ++ unsigned char insn[PLT_ENTRY_SIZE]; ++ char *plt_base; ++ char *ip; ++ ++ plt_base = me->core_layout.base + me->arch.plt_offset; ++ ip = plt_base + info->plt_offset; ++ *(int *)insn = 0x0d10e310; /* basr 1,0 */ ++ *(int *)&insn[4] = 0x100c0004; /* lg 1,12(1) */ + if (IS_ENABLED(CONFIG_EXPOLINE) && !nospec_disable) { +- unsigned int *ij; +- ij = me->core_layout.base + +- me->arch.plt_offset + +- me->arch.plt_size - PLT_ENTRY_SIZE; +- insn[2] = 0xa7f40000 + /* j __jump_r1 */ +- (unsigned int)(u16) +- (((unsigned long) ij - 8 - +- (unsigned long) ip) / 2); ++ char *jump_r1; ++ ++ jump_r1 = plt_base + me->arch.plt_size - ++ PLT_ENTRY_SIZE; ++ /* brcl 0xf,__jump_r1 */ ++ *(short *)&insn[8] = 0xc0f4; ++ *(int *)&insn[10] = (jump_r1 - (ip + 8)) / 2; + } else { +- insn[2] = 0x07f10000; /* br %r1 */ ++ *(int *)&insn[8] = 0x07f10000; /* br %r1 */ + } +- insn[3] = (unsigned int) (val >> 32); +- insn[4] = (unsigned int) val; ++ *(long *)&insn[14] = val; + + write(ip, insn, sizeof(insn)); + info->plt_initialized = 1; diff --git a/queue-5.10/scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch b/queue-5.10/scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch new file mode 100644 index 00000000000..470f6a4b6e1 --- /dev/null +++ b/queue-5.10/scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch @@ -0,0 +1,111 @@ +From 8c9db6679be4348b8aae108e11d4be2f83976e30 Mon Sep 17 00:00:00 2001 +From: Steffen Maier +Date: Tue, 18 Jan 2022 17:58:03 +0100 +Subject: scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices + +From: Steffen Maier + +commit 8c9db6679be4348b8aae108e11d4be2f83976e30 upstream. + +Suppose we have an environment with a number of non-NPIV FCP devices +(virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical +FCP channel (HBA port) and its I_T nexus. Plus a number of storage target +ports zoned to such shared channel. Now one target port logs out of the +fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port +recovery depending on the ADISC result. This happens on all such FCP +devices (in different Linux images) concurrently as they all receive a copy +of this RSCN. In the following we look at one of those FCP devices. + +Requests other than FSF_QTCB_FCP_CMND can be slow until they get a +response. + +Depending on which requests are affected by slow responses, there are +different recovery outcomes. Here we want to fix failed recoveries on port +or adapter level by avoiding recovery requests that can be slow. + +We need the cached N_Port_ID for the remote port "link" test with ADISC. +Just before sending the ADISC, we now intentionally forget the old cached +N_Port_ID. The idea is that on receiving an RSCN for a port, we have to +assume that any cached information about this port is stale. This forces a +fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for +the same port. Since we typically can still communicate with the nameserver +efficiently, we now reach steady state quicker: Either the nameserver still +does not know about the port so we stop recovery, or the nameserver already +knows the port potentially with a new N_Port_ID and we can successfully and +quickly perform open port recovery. For the one case, where ADISC returns +successfully, we re-initialize port->d_id because that case does not +involve any port recovery. + +This also solves a problem if the storage WWPN quickly logs into the fabric +again but with a different N_Port_ID. Such as on virtual WWPN takeover +during target NPIV failover. +[https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the +RSCN from the storage FDISC was ignored by zfcp and we could not +successfully recover the failover. On some later failback on the storage, +we could have been lucky if the virtual WWPN got the same old N_Port_ID +from the SAN switch as we still had cached. Then the related RSCN +triggered a successful port reopen recovery. However, there is no +guarantee to get the same N_Port_ID on NPIV FDISC. + +Even though NPIV-enabled FCP devices are not affected by this problem, this +code change optimizes recovery time for gone remote ports as a side effect. +The timely drop of cached N_Port_IDs prevents unnecessary slow open port +attempts. + +While the problem might have been in code before v2.6.32 commit +799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix +depends on the gid_pn_work introduced with that commit, so we mark it as +culprit to satisfy fix dependencies. + +Note: Point-to-point remote port is already handled separately and gets its +N_Port_ID from the cached peer_d_id. So resetting port->d_id in general +does not affect PtP. + +Link: https://lore.kernel.org/r/20220118165803.3667947-1-maier@linux.ibm.com +Fixes: 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") +Cc: #2.6.32+ +Suggested-by: Benjamin Block +Reviewed-by: Benjamin Block +Signed-off-by: Steffen Maier +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/scsi/zfcp_fc.c | 13 ++++++++++++- + 1 file changed, 12 insertions(+), 1 deletion(-) + +--- a/drivers/s390/scsi/zfcp_fc.c ++++ b/drivers/s390/scsi/zfcp_fc.c +@@ -521,6 +521,8 @@ static void zfcp_fc_adisc_handler(void * + goto out; + } + ++ /* re-init to undo drop from zfcp_fc_adisc() */ ++ port->d_id = ntoh24(adisc_resp->adisc_port_id); + /* port is good, unblock rport without going through erp */ + zfcp_scsi_schedule_rport_register(port); + out: +@@ -534,6 +536,7 @@ static int zfcp_fc_adisc(struct zfcp_por + struct zfcp_fc_req *fc_req; + struct zfcp_adapter *adapter = port->adapter; + struct Scsi_Host *shost = adapter->scsi_host; ++ u32 d_id; + int ret; + + fc_req = kmem_cache_zalloc(zfcp_fc_req_cache, GFP_ATOMIC); +@@ -558,7 +561,15 @@ static int zfcp_fc_adisc(struct zfcp_por + fc_req->u.adisc.req.adisc_cmd = ELS_ADISC; + hton24(fc_req->u.adisc.req.adisc_port_id, fc_host_port_id(shost)); + +- ret = zfcp_fsf_send_els(adapter, port->d_id, &fc_req->ct_els, ++ d_id = port->d_id; /* remember as destination for send els below */ ++ /* ++ * Force fresh GID_PN lookup on next port recovery. ++ * Must happen after request setup and before sending request, ++ * to prevent race with port->d_id re-init in zfcp_fc_adisc_handler(). ++ */ ++ port->d_id = 0; ++ ++ ret = zfcp_fsf_send_els(adapter, d_id, &fc_req->ct_els, + ZFCP_FC_CTELS_TMO); + if (ret) + kmem_cache_free(zfcp_fc_req_cache, fc_req); diff --git a/queue-5.10/series b/queue-5.10/series new file mode 100644 index 00000000000..d902a82b1cc --- /dev/null +++ b/queue-5.10/series @@ -0,0 +1,10 @@ +bluetooth-refactor-malicious-adv-data-check.patch +media-venus-core-drop-second-v4l2-device-unregister.patch +net-sfp-ignore-disabled-sfp-node.patch +net-stmmac-skip-only-stmmac_ptp_register-when-resume-from-suspend.patch +s390-module-fix-loading-modules-with-a-lot-of-relocations.patch +s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch +bpf-guard-against-accessing-null-pt_regs-in-bpf_get_task_stack.patch +scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch +udf-restore-i_lenalloc-when-inode-expansion-fails.patch +udf-fix-null-ptr-deref-when-converting-from-inline-format.patch diff --git a/queue-5.10/udf-fix-null-ptr-deref-when-converting-from-inline-format.patch b/queue-5.10/udf-fix-null-ptr-deref-when-converting-from-inline-format.patch new file mode 100644 index 00000000000..ba9cbb7e886 --- /dev/null +++ b/queue-5.10/udf-fix-null-ptr-deref-when-converting-from-inline-format.patch @@ -0,0 +1,64 @@ +From 7fc3b7c2981bbd1047916ade327beccb90994eee Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Mon, 17 Jan 2022 18:22:13 +0100 +Subject: udf: Fix NULL ptr deref when converting from inline format + +From: Jan Kara + +commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream. + +udf_expand_file_adinicb() calls directly ->writepage to write data +expanded into a page. This however misses to setup inode for writeback +properly and so we can crash on inode->i_wb dereference when submitting +page for IO like: + + BUG: kernel NULL pointer dereference, address: 0000000000000158 + #PF: supervisor read access in kernel mode +... + + __folio_start_writeback+0x2ac/0x350 + __block_write_full_page+0x37d/0x490 + udf_expand_file_adinicb+0x255/0x400 [udf] + udf_file_write_iter+0xbe/0x1b0 [udf] + new_sync_write+0x125/0x1c0 + vfs_write+0x28e/0x400 + +Fix the problem by marking the page dirty and going through the standard +writeback path to write the page. Strictly speaking we would not even +have to write the page but we want to catch e.g. ENOSPC errors early. + +Reported-by: butt3rflyh4ck +CC: stable@vger.kernel.org +Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks") +Reviewed-by: Christoph Hellwig +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + fs/udf/inode.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/fs/udf/inode.c ++++ b/fs/udf/inode.c +@@ -257,10 +257,6 @@ int udf_expand_file_adinicb(struct inode + char *kaddr; + struct udf_inode_info *iinfo = UDF_I(inode); + int err; +- struct writeback_control udf_wbc = { +- .sync_mode = WB_SYNC_NONE, +- .nr_to_write = 1, +- }; + + WARN_ON_ONCE(!inode_is_locked(inode)); + if (!iinfo->i_lenAlloc) { +@@ -304,8 +300,10 @@ int udf_expand_file_adinicb(struct inode + iinfo->i_alloc_type = ICBTAG_FLAG_AD_LONG; + /* from now on we have normal address_space methods */ + inode->i_data.a_ops = &udf_aops; ++ set_page_dirty(page); ++ unlock_page(page); + up_write(&iinfo->i_data_sem); +- err = inode->i_data.a_ops->writepage(page, &udf_wbc); ++ err = filemap_fdatawrite(inode->i_mapping); + if (err) { + /* Restore everything back so that we don't lose data... */ + lock_page(page); diff --git a/queue-5.10/udf-restore-i_lenalloc-when-inode-expansion-fails.patch b/queue-5.10/udf-restore-i_lenalloc-when-inode-expansion-fails.patch new file mode 100644 index 00000000000..9c726ae4c26 --- /dev/null +++ b/queue-5.10/udf-restore-i_lenalloc-when-inode-expansion-fails.patch @@ -0,0 +1,34 @@ +From ea8569194b43f0f01f0a84c689388542c7254a1f Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Tue, 18 Jan 2022 09:57:25 +0100 +Subject: udf: Restore i_lenAlloc when inode expansion fails + +From: Jan Kara + +commit ea8569194b43f0f01f0a84c689388542c7254a1f upstream. + +When we fail to expand inode from inline format to a normal format, we +restore inode to contain the original inline formatting but we forgot to +set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then +causing further problems such as warnings and lost data down the line. + +Reported-by: butt3rflyh4ck +CC: stable@vger.kernel.org +Fixes: 7e49b6f2480c ("udf: Convert UDF to new truncate calling sequence") +Reviewed-by: Christoph Hellwig +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + fs/udf/inode.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/udf/inode.c ++++ b/fs/udf/inode.c +@@ -316,6 +316,7 @@ int udf_expand_file_adinicb(struct inode + unlock_page(page); + iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB; + inode->i_data.a_ops = &udf_adinicb_aops; ++ iinfo->i_lenAlloc = inode->i_size; + up_write(&iinfo->i_data_sem); + } + put_page(page);