]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 29 Jan 2022 12:32:38 +0000 (13:32 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 29 Jan 2022 12:32:38 +0000 (13:32 +0100)
added patches:
bluetooth-refactor-malicious-adv-data-check.patch
s390-hypfs-include-z-vm-guests-with-access-control-group-set.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

queue-4.4/bluetooth-refactor-malicious-adv-data-check.patch [new file with mode: 0644]
queue-4.4/s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch [new file with mode: 0644]
queue-4.4/scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch [new file with mode: 0644]
queue-4.4/series
queue-4.4/udf-fix-null-ptr-deref-when-converting-from-inline-format.patch [new file with mode: 0644]
queue-4.4/udf-restore-i_lenalloc-when-inode-expansion-fails.patch [new file with mode: 0644]

diff --git a/queue-4.4/bluetooth-refactor-malicious-adv-data-check.patch b/queue-4.4/bluetooth-refactor-malicious-adv-data-check.patch
new file mode 100644 (file)
index 0000000..7ccfeed
--- /dev/null
@@ -0,0 +1,48 @@
+From 899663be5e75dc0174dc8bda0b5e6826edf0b29a Mon Sep 17 00:00:00 2001
+From: Brian Gix <brian.gix@intel.com>
+Date: Wed, 24 Nov 2021 12:16:28 -0800
+Subject: Bluetooth: refactor malicious adv data check
+
+From: Brian Gix <brian.gix@intel.com>
+
+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 <brian.gix@intel.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Cc: syphyr <syphyr@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -4940,6 +4940,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];
+@@ -4951,11 +4956,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-4.4/s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch b/queue-4.4/s390-hypfs-include-z-vm-guests-with-access-control-group-set.patch
new file mode 100644 (file)
index 0000000..9057413
--- /dev/null
@@ -0,0 +1,51 @@
+From 663d34c8df98740f1e90241e78e456d00b3c6cad Mon Sep 17 00:00:00 2001
+From: Vasily Gorbik <gor@linux.ibm.com>
+Date: Thu, 20 Jan 2022 16:23:19 +0100
+Subject: s390/hypfs: include z/VM guests with access control group set
+
+From: Vasily Gorbik <gor@linux.ibm.com>
+
+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 <gerald.schaefer@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -19,6 +19,7 @@
+ static char local_guest[] = "        ";
+ static char all_guests[] = "*       ";
++static char *all_groups = all_guests;
+ static char *guest_query;
+ struct diag2fc_data {
+@@ -61,10 +62,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-4.4/scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch b/queue-4.4/scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch
new file mode 100644 (file)
index 0000000..3d84b8d
--- /dev/null
@@ -0,0 +1,111 @@
+From 8c9db6679be4348b8aae108e11d4be2f83976e30 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.ibm.com>
+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 <maier@linux.ibm.com>
+
+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: <stable@vger.kernel.org> #2.6.32+
+Suggested-by: Benjamin Block <bblock@linux.ibm.com>
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Signed-off-by: Steffen Maier <maier@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -518,6 +518,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:
+@@ -531,6 +533,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);
+@@ -555,7 +558,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);
index 4db575896296905786443d6595dea4e37b960487..9effcb61160ec40874e5d3f2494e9605387464ff 100644 (file)
@@ -1 +1,6 @@
 can-bcm-fix-uaf-of-bcm-op.patch
+bluetooth-refactor-malicious-adv-data-check.patch
+s390-hypfs-include-z-vm-guests-with-access-control-group-set.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-4.4/udf-fix-null-ptr-deref-when-converting-from-inline-format.patch b/queue-4.4/udf-fix-null-ptr-deref-when-converting-from-inline-format.patch
new file mode 100644 (file)
index 0000000..f8d653e
--- /dev/null
@@ -0,0 +1,64 @@
+From 7fc3b7c2981bbd1047916ade327beccb90994eee Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 17 Jan 2022 18:22:13 +0100
+Subject: udf: Fix NULL ptr deref when converting from inline format
+
+From: Jan Kara <jack@suse.cz>
+
+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
+...
+  <TASK>
+  __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 <butterflyhuangxx@gmail.com>
+CC: stable@vger.kernel.org
+Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks")
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/inode.c |    8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/fs/udf/inode.c
++++ b/fs/udf/inode.c
+@@ -260,10 +260,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(!mutex_is_locked(&inode->i_mutex));
+       if (!iinfo->i_lenAlloc) {
+@@ -307,8 +303,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-4.4/udf-restore-i_lenalloc-when-inode-expansion-fails.patch b/queue-4.4/udf-restore-i_lenalloc-when-inode-expansion-fails.patch
new file mode 100644 (file)
index 0000000..c8fd2c3
--- /dev/null
@@ -0,0 +1,34 @@
+From ea8569194b43f0f01f0a84c689388542c7254a1f Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Tue, 18 Jan 2022 09:57:25 +0100
+Subject: udf: Restore i_lenAlloc when inode expansion fails
+
+From: Jan Kara <jack@suse.cz>
+
+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 <butterflyhuangxx@gmail.com>
+CC: stable@vger.kernel.org
+Fixes: 7e49b6f2480c ("udf: Convert UDF to new truncate calling sequence")
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/inode.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/udf/inode.c
++++ b/fs/udf/inode.c
+@@ -320,6 +320,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);
+       }
+       page_cache_release(page);