4.9.269-rc1 review

PATCH In review Greg Kroah-Hartman 6 participants 246 messages May 20, 2021 – May 21, 2021 Page 1 of 2

Subsystems (2)

Stable branch Tegra architecture support

lore

Share & tools

lore

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #1 lore raw

PATCH 1/240 net: usb: ax88179_178a: initialize local variables before use

In reply to Greg Kroah-Hartman

From: Phillip Potter <[email protected]>

commit bd78980be1a68d14524c51c4b4170782fada622b upstream.

Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug reported by syzbot at:
https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa

Reported-by [email protected]

Signed-off-by Phillip Potter <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/usb/ax88179_178a.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/usb/ax88179_178a.c +2 -2

@@ -307,12 +307,12 @@ static int ax88179_read_cmd(struct usbne
 	int ret;
 
 	if (2 == size) {
-		u16 buf;
+		u16 buf = 0;
 		ret = __ax88179_read_cmd(dev, cmd, value, index, size, &buf, 0);
 		le16_to_cpus(&buf);
 		*((u16 *)data) = buf;
 	} else if (4 == size) {
-		u32 buf;
+		u32 buf = 0;
 		ret = __ax88179_read_cmd(dev, cmd, value, index, size, &buf, 0);
 		le32_to_cpus(&buf);
 		*((u32 *)data) = buf;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #10 lore raw

PATCH 10/240 arm64: dts: mt8173: fix property typo of phys in dsi node

In reply to Greg Kroah-Hartman

From: Chunfeng Yun <[email protected]>

commit e4e5d030bd779fb8321d3b8bd65406fbe0827037 upstream.

Use 'phys' instead of 'phy'.

Fixes 81ad4dbaf7af ("arm64: dts: mt8173: Add display subsystem related nodes")

Signed-off-by Chunfeng Yun <[email protected]>

Reviewed-by Chun-Kuang Hu <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Matthias Brugger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/mediatek/mt8173.dtsi +1 -1

@@ -914,7 +914,7 @@
 				 <&mmsys CLK_MM_DSI1_DIGITAL>,
 				 <&mipi_tx1>;
 			clock-names = "engine", "digital", "hs";
-			phy = <&mipi_tx1>;
+			phys = <&mipi_tx1>;
 			phy-names = "dphy";
 			status = "disabled";
 		};

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #11 lore raw

PATCH 11/240 ecryptfs: fix kernel panic with null dev_name

In reply to Greg Kroah-Hartman

From: Jeffrey Mitchell <[email protected]>

commit 9046625511ad8dfbc8c6c2de16b3532c43d68d48 upstream.

When mounting eCryptfs, a null "dev_name" argument to ecryptfs_mount() causes a kernel panic if the parsed options are valid. The easiest way to reproduce this is to call mount() from userspace with an existing eCryptfs mount's options and a "source" argument of 0.

Error out if "dev_name" is null in ecryptfs_mount()

Fixes 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")

Cc [email protected]

Signed-off-by Jeffrey Mitchell <[email protected]>

Signed-off-by Tyler Hicks <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ecryptfs/main.c |    6 ++++++
 1 file changed, 6 insertions(+)

fs/ecryptfs/main.c +6 -0

@@ -506,6 +506,12 @@ static struct dentry *ecryptfs_mount(str
 		goto out;
 	}
 
+	if (!dev_name) {
+		rc = -EINVAL;
+		err = "Device name cannot be null";
+		goto out;
+	}
+
 	rc = ecryptfs_parse_options(sbi, raw_data, &check_ruid);
 	if (rc) {
 		err = "Error parsing options";

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #12 lore raw

PATCH 12/240 mmc: core: Do a power cycle when the CMD11 fails

In reply to Greg Kroah-Hartman

From: DooHyun Hwang <[email protected]>

commit 147186f531ae49c18b7a9091a2c40e83b3d95649 upstream.

A CMD11 is sent to the SD/SDIO card to start the voltage switch procedure into 1.8V I/O. According to the SD spec a power cycle is needed of the card, if it turns out that the CMD11 fails. Let's fix this, to allow a retry of the initialization without the voltage switch, to succeed.

Note that, whether it makes sense to also retry with the voltage switch after the power cycle is a bit more difficult to know. At this point, we treat it like the CMD11 isn't supported and therefore we skip it when retrying.

Signed-off-by DooHyun Hwang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Cc [email protected]

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/core/core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mmc/core/core.c +1 -1

@@ -1691,7 +1691,7 @@ int mmc_set_signal_voltage(struct mmc_ho
 
 	err = mmc_wait_for_cmd(host, &cmd, 0);
 	if (err)
-		return err;
+		goto power_cycle;
 
 	if (!mmc_host_is_spi(host) && (cmd.resp[0] & R1_ERROR))
 		return -EIO;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #13 lore raw

PATCH 13/240 mmc: core: Set read only for SD cards with permanent write protect bit

In reply to Greg Kroah-Hartman

From: Seunghui Lee <[email protected]>

commit 917a5336f2c27928be270226ab374ed0cbf3805d upstream.

Some of SD cards sets permanent write protection bit in their CSD register, due to lifespan or internal problem. To avoid unnecessary I/O write operations, let's parse the bits in the CSD during initialization and mark the card as read only for this case.

Signed-off-by Seunghui Lee <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Cc [email protected]

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/core/sd.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/mmc/core/sd.c +6 -0

@@ -136,6 +136,9 @@ static int mmc_decode_csd(struct mmc_car
 			csd->erase_size = UNSTUFF_BITS(resp, 39, 7) + 1;
 			csd->erase_size <<= csd->write_blkbits - 9;
 		}
+
+		if (UNSTUFF_BITS(resp, 13, 1))
+			mmc_card_set_readonly(card);
 		break;
 	case 1:
 		/*

@@ -170,6 +173,9 @@ static int mmc_decode_csd(struct mmc_car
 		csd->write_blkbits = 9;
 		csd->write_partial = 0;
 		csd->erase_size = 1;
+
+		if (UNSTUFF_BITS(resp, 13, 1))
+			mmc_card_set_readonly(card);
 		break;
 	default:
 		pr_err("%s: unrecognised CSD structure version %d\n",

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #14 lore raw

PATCH 14/240 btrfs: fix metadata extent leak after failure to create subvolume

In reply to Greg Kroah-Hartman

From: Filipe Manana <[email protected]>

commit 67addf29004c5be9fa0383c82a364bb59afc7f84 upstream.

When creating a subvolume we allocate an extent buffer for its root node after starting a transaction. We setup a root item for the subvolume that points to that extent buffer and then attempt to insert the root item into the root tree - however if that fails, due to ENOMEM for example, we do not free the extent buffer previously allocated and we do not abort the transaction (as at that point we did nothing that can not be undone).

This means that we effectively do not return the metadata extent back to the free space cache/tree and we leave a delayed reference for it which causes a metadata extent item to be added to the extent tree, in the next transaction commit, without having backreferences. When this happens 'btrfs check' reports the following:

  $ btrfs check /dev/sdi
  Opening filesystem to check...
  Checking filesystem on /dev/sdi
  UUID: dce2cb9d-025f-4b05-a4bf-cee0ad3785eb
  [1/7] checking root items
  [2/7] checking extents
  ref mismatch on [30425088 16384] extent item 1, found 0
  backref 30425088 root 256 not referenced back 0x564a91c23d70
  incorrect global backref count on 30425088 found 1 wanted 0
  backpointer mismatch on [30425088 16384]
  owner ref check failed [30425088 16384]
  ERROR: errors found in extent allocation tree or chunk allocation
  [3/7] checking free space cache
  [4/7] checking fs roots
  [5/7] checking only csums items (without verifying data)
  [6/7] checking root refs
  [7/7] checking quota groups skipped (not enabled on this FS)
  found 212992 bytes used, error(s) found
  total csum bytes: 0
  total tree bytes: 131072
  total fs tree bytes: 32768
  total extent tree bytes: 16384
  btree space waste bytes: 124669
  file data blocks allocated: 65536
   referenced 65536

So fix this by freeing the metadata extent if btrfs_insert_root() returns an error.

CC [email protected] # 4.4+

Signed-off-by Filipe Manana <[email protected]>

Reviewed-by David Sterba <[email protected]>

Signed-off-by David Sterba <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/ioctl.c |   18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

fs/btrfs/ioctl.c +15 -3

@@ -557,8 +557,6 @@ static noinline int create_subvol(struct
 	btrfs_set_root_otransid(root_item, trans->transid);
 
 	btrfs_tree_unlock(leaf);
-	free_extent_buffer(leaf);
-	leaf = NULL;
 
 	btrfs_set_root_dirid(root_item, new_dirid);

@@ -567,8 +565,22 @@ static noinline int create_subvol(struct
 	key.type = BTRFS_ROOT_ITEM_KEY;
 	ret = btrfs_insert_root(trans, root->fs_info->tree_root, &key,
 				root_item);
-	if (ret)
+	if (ret) {
+		/*
+		 * Since we don't abort the transaction in this case, free the
+		 * tree block so that we don't leak space and leave the
+		 * filesystem in an inconsistent state (an extent item in the
+		 * extent tree without backreferences). Also no need to have
+		 * the tree block locked since it is not in any tree at this
+		 * point, so no other task can find it and use it.
+		 */
+		btrfs_free_tree_block(trans, root, leaf, 0, 1);
+		free_extent_buffer(leaf);
 		goto fail;
+	}
+
+	free_extent_buffer(leaf);
+	leaf = NULL;
 
 	key.offset = (u64)-1;
 	new_root = btrfs_read_fs_root_no_name(root->fs_info, &key);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #15 lore raw

PATCH 15/240 fbdev: zero-fill colormap in fbcmap.c

In reply to Greg Kroah-Hartman

From: Phillip Potter <[email protected]>

commit 19ab233989d0f7ab1de19a036e247afa4a0a1e9c upstream.

Use kzalloc() rather than kmalloc() for the dynamically allocated parts of the colormap in fb_alloc_cmap_gfp, to prevent a leak of random kernel data to userspace under certain circumstances.

Fixes a KMSAN-found infoleak bug reported by syzbot at:
https://syzkaller.appspot.com/bug?id=741578659feabd108ad9e06696f0c1f2e69c4b6e

Reported-by [email protected]

Cc stable <[email protected]>

Reviewed-by Geert Uytterhoeven <[email protected]>

Signed-off-by Phillip Potter <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/core/fbcmap.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/video/fbdev/core/fbcmap.c +4 -4

@@ -101,17 +101,17 @@ int fb_alloc_cmap_gfp(struct fb_cmap *cm
 		if (!len)
 			return 0;
 
-		cmap->red = kmalloc(size, flags);
+		cmap->red = kzalloc(size, flags);
 		if (!cmap->red)
 			goto fail;
-		cmap->green = kmalloc(size, flags);
+		cmap->green = kzalloc(size, flags);
 		if (!cmap->green)
 			goto fail;
-		cmap->blue = kmalloc(size, flags);
+		cmap->blue = kzalloc(size, flags);
 		if (!cmap->blue)
 			goto fail;
 		if (transp) {
-			cmap->transp = kmalloc(size, flags);
+			cmap->transp = kzalloc(size, flags);
 			if (!cmap->transp)
 				goto fail;
 		} else {

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #16 lore raw

PATCH 16/240 staging: wimax/i2400m: fix byte-order issue

In reply to Greg Kroah-Hartman

From: karthik alapati <[email protected]>

[ Upstream commit 0c37baae130df39b19979bba88bde2ee70a33355 ]

fix sparse byte-order warnings by converting host byte-order type to __le16 byte-order types before assigning to hdr.length

Signed-off-by karthik alapati <[email protected]>

Link https://lore.kernel.org/r/0ae5c5c4c646506d8be871e7be5705542671a1d5.1613921277.git.mail@karthek.com open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wimax/i2400m/op-rfkill.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wimax/i2400m/op-rfkill.c +1 -1

index dc6fe93ce71f..e8473047b2d1 100644
@@ -101,7 +101,7 @@ int i2400m_op_rfkill_sw_toggle(struct wimax_dev *wimax_dev,
 	if (cmd == NULL)
 		goto error_alloc;
 	cmd->hdr.type = cpu_to_le16(I2400M_MT_CMD_RF_CONTROL);
-	cmd->hdr.length = sizeof(cmd->sw_rf);
+	cmd->hdr.length = cpu_to_le16(sizeof(cmd->sw_rf));
 	cmd->hdr.version = cpu_to_le16(I2400M_L3L4_VERSION);
 	cmd->sw_rf.hdr.type = cpu_to_le16(I2400M_TLV_RF_OPERATION);
 	cmd->sw_rf.hdr.length = cpu_to_le16(sizeof(cmd->sw_rf.status));

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #17 lore raw

PATCH 17/240 usb: gadget: uvc: add bInterval checking for HS mode

In reply to Greg Kroah-Hartman

From: Pawel Laszczak <[email protected]>

[ Upstream commit 26adde04acdff14a1f28d4a5dce46a8513a3038b ]

Patch adds extra checking for bInterval passed by configfs. The 5.6.4 chapter of USB Specification (rev. 2.0) say:
"A high-bandwidth endpoint must specify a period of 1x125 µs (i.e., a bInterval value of 1)."

The issue was observed during testing UVC class on CV. I treat this change as improvement because we can control bInterval by configfs.

Reviewed-by Peter Chen <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Signed-off-by Pawel Laszczak <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/function/f_uvc.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/usb/gadget/function/f_uvc.c +6 -1

index f8a1881609a2..89da34ef7b3f 100644
@@ -625,7 +625,12 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)
 
 	uvc_hs_streaming_ep.wMaxPacketSize =
 		cpu_to_le16(max_packet_size | ((max_packet_mult - 1) << 11));
-	uvc_hs_streaming_ep.bInterval = opts->streaming_interval;
+
+	/* A high-bandwidth endpoint must specify a bInterval value of 1 */
+	if (max_packet_mult > 1)
+		uvc_hs_streaming_ep.bInterval = 1;
+	else
+		uvc_hs_streaming_ep.bInterval = opts->streaming_interval;
 
 	uvc_ss_streaming_ep.wMaxPacketSize = cpu_to_le16(max_packet_size);
 	uvc_ss_streaming_ep.bInterval = opts->streaming_interval;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #18 lore raw

PATCH 18/240 usb: dwc3: gadget: Ignore EP queue requests during bus reset

In reply to Greg Kroah-Hartman

From: Wesley Cheng <[email protected]>

[ Upstream commit 71ca43f30df9c642970f9dc9b2d6f463f4967e7b ]

The current dwc3_gadget_reset_interrupt() will stop any active transfers, but only addresses blocking of EP queuing for while we are coming from a disconnected scenario, i.e. after receiving the disconnect event. If the host decides to issue a bus reset on the device, the connected parameter will still be set to true, allowing for EP queuing to continue while we are disabling the functions. To avoid this, set the connected flag to false until the stop active transfers is complete.

Signed-off-by Wesley Cheng <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/dwc3/gadget.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/usb/dwc3/gadget.c +9 -0

index e0fb7b3723c5..cca51553e0fb 100644
@@ -2409,6 +2409,15 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
 
 	dwc->connected = true;
 
+	/*
+	 * Ideally, dwc3_reset_gadget() would trigger the function
+	 * drivers to stop any active transfers through ep disable.
+	 * However, for functions which defer ep disable, such as mass
+	 * storage, we will need to rely on the call to stop active
+	 * transfers here, and avoid allowing of request queuing.
+	 */
+	dwc->connected = false;
+
 	/*
 	 * WORKAROUND: DWC3 revisions <1.88a have an issue which
 	 * would cause a missing Disconnect Event if there's a

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:45 UTC #19 lore raw

PATCH 19/240 usb: xhci: Fix port minor revision

In reply to Greg Kroah-Hartman

From: Thinh Nguyen <[email protected]>

[ Upstream commit 64364bc912c01b33bba6c22e3ccb849bfca96398 ]

Some hosts incorrectly use sub-minor version for minor version (i.e. 0x02 instead of 0x20 for bcdUSB 0x320 and 0x01 for bcdUSB 0x310). Currently the xHCI driver works around this by just checking for minor revision > 0x01 for USB 3.1 everywhere. With the addition of USB 3.2, checking this gets a bit cumbersome. Since there is no USB release with bcdUSB 0x301 to 0x309, we can assume that sub-minor version 01 to 09 is incorrect. Let's try to fix this and use the minor revision that matches with the USB/xHCI spec to help with the version checking within the driver.

Acked-by Mathias Nyman <[email protected]>

Signed-off-by Thinh Nguyen <[email protected]>

Link https://lore.kernel.org/r/ed330e95a19dc367819c5b4d78bf7a541c35aa0a.1615432770.git.Thinh.Nguyen@synopsys.com open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/host/xhci-mem.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/usb/host/xhci-mem.c +9 -0

index 3cca60b845a8..9b30936904da 100644
@@ -2159,6 +2159,15 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports,
 
 	if (major_revision == 0x03) {
 		rhub = &xhci->usb3_rhub;
+		/*
+		 * Some hosts incorrectly use sub-minor version for minor
+		 * version (i.e. 0x02 instead of 0x20 for bcdUSB 0x320 and 0x01
+		 * for bcdUSB 0x310). Since there is no USB release with sub
+		 * minor version 0x301 to 0x309, we can assume that they are
+		 * incorrect and fix it here.
+		 */
+		if (minor_revision > 0x00 && minor_revision < 0x10)
+			minor_revision <<= 4;
 	} else if (major_revision <= 0x02) {
 		rhub = &xhci->usb2_rhub;
 	} else {

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #2 lore raw

PATCH 2/240 iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()

In reply to Greg Kroah-Hartman

From: Jiri Kosina <[email protected]>

commit 2800aadc18a64c96b051bcb7da8a7df7d505db3f upstream.

It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs disabled (e.g. from LED core). We can't enable BHs in such a situation.

Turn the unconditional BH-enable/BH-disable code into hardirq-disable/conditional-enable.

This fixes the warning below.

 WARNING: CPU: 1 PID: 1139 at kernel/softirq.c:178 __local_bh_enable_ip+0xa5/0xf0
 CPU: 1 PID: 1139 Comm: NetworkManager Not tainted 5.12.0-rc1-00004-gb4ded168af79 #7
 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017
 RIP: 0010:__local_bh_enable_ip+0xa5/0xf0
 Code: f7 69 e8 ee 23 14 00 fb 66 0f 1f 44 00 00 65 8b 05 f0 f4 f7 69 85 c0 74 3f 48 83 c4 08 5b c3 65 8b 05 9b fe f7 69 85 c0 75 8e <0f> 0b eb 8a 48 89 3c 24 e8 4e 20 14 00 48 8b 3c 24 eb 91 e8 13 4e
 RSP: 0018:ffffafd580b13298 EFLAGS: 00010046
 RAX: 0000000000000000 RBX: 0000000000000201 RCX: 0000000000000000
 RDX: 0000000000000003 RSI: 0000000000000201 RDI: ffffffffc1272389
 RBP: ffff96517ae4c018 R08: 0000000000000001 R09: 0000000000000000
 R10: ffffafd580b13178 R11: 0000000000000001 R12: ffff96517b060000
 R13: 0000000000000000 R14: ffffffff80000000 R15: 0000000000000001
 FS:  00007fc604ebefc0(0000) GS:ffff965267480000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000055fb3fef13b2 CR3: 0000000109112004 CR4: 00000000003706e0
 Call Trace:
  ? _raw_spin_unlock_bh+0x1f/0x30
  iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi]
  iwl_trans_txq_send_hcmd+0x6c/0x430 [iwlwifi]
  iwl_trans_send_cmd+0x88/0x170 [iwlwifi]
  ? lock_acquire+0x277/0x3d0
  iwl_mvm_send_cmd+0x32/0x80 [iwlmvm]
  iwl_mvm_led_set+0xc2/0xe0 [iwlmvm]
  ? led_trigger_event+0x46/0x70
  led_trigger_event+0x46/0x70
  ieee80211_do_open+0x5c5/0xa20 [mac80211]
  ieee80211_open+0x67/0x90 [mac80211]
  __dev_open+0xd4/0x150
  __dev_change_flags+0x19e/0x1f0
  dev_change_flags+0x23/0x60
  do_setlink+0x30d/0x1230
  ? lock_is_held_type+0xb4/0x120
  ? __nla_validate_parse.part.7+0x57/0xcb0
  ? __lock_acquire+0x2e1/0x1a50
  __rtnl_newlink+0x560/0x910
  ? __lock_acquire+0x2e1/0x1a50
  ? __lock_acquire+0x2e1/0x1a50
  ? lock_acquire+0x277/0x3d0
  ? sock_def_readable+0x5/0x290
  ? lock_is_held_type+0xb4/0x120
  ? find_held_lock+0x2d/0x90
  ? sock_def_readable+0xb3/0x290
  ? lock_release+0x166/0x2a0
  ? lock_is_held_type+0x90/0x120
  rtnl_newlink+0x47/0x70
  rtnetlink_rcv_msg+0x25c/0x470
  ? netlink_deliver_tap+0x97/0x3e0
  ? validate_linkmsg+0x350/0x350
  netlink_rcv_skb+0x50/0x100
  netlink_unicast+0x1b2/0x280
  netlink_sendmsg+0x336/0x450
  sock_sendmsg+0x5b/0x60
  ____sys_sendmsg+0x1ed/0x250
  ? copy_msghdr_from_user+0x5c/0x90
  ___sys_sendmsg+0x88/0xd0
  ? lock_is_held_type+0xb4/0x120
  ? find_held_lock+0x2d/0x90
  ? lock_release+0x166/0x2a0
  ? __fget_files+0xfe/0x1d0
  ? __sys_sendmsg+0x5e/0xa0
  __sys_sendmsg+0x5e/0xa0
  ? lockdep_hardirqs_on_prepare+0xd9/0x170
  do_syscall_64+0x33/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fc605c9572d
 Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 da ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 2e ef ff ff 48
 RSP: 002b:00007fffc83789f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
 RAX: ffffffffffffffda RBX: 000055ef468570c0 RCX: 00007fc605c9572d
 RDX: 0000000000000000 RSI: 00007fffc8378a30 RDI: 000000000000000c
 RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
 R13: 00007fffc8378b80 R14: 00007fffc8378b7c R15: 0000000000000000
 irq event stamp: 170785
 hardirqs last  enabled at (170783): [<ffffffff9609a8c2>] __local_bh_enable_ip+0x82/0xf0
 hardirqs last disabled at (170784): [<ffffffff96a8613d>] _raw_read_lock_irqsave+0x8d/0x90
 softirqs last  enabled at (170782): [<ffffffffc1272389>] iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi]
 softirqs last disabled at (170785): [<ffffffffc1271ec6>] iwl_pcie_enqueue_hcmd+0x116/0xa00 [iwlwifi]

Signed-off-by Jiri Kosina <[email protected]>

Tested-by Sedat Dilek <[email protected]> # LLVM/Clang v12.0.0-rc3

Acked-by Luca Coelho <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jari Ruusu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/net/wireless/intel/iwlwifi/pcie/tx.c +4 -3

@@ -1510,6 +1510,7 @@ static int iwl_pcie_enqueue_hcmd(struct
 	u32 cmd_pos;
 	const u8 *cmddata[IWL_MAX_CMD_TBS_PER_TFD];
 	u16 cmdlen[IWL_MAX_CMD_TBS_PER_TFD];
+	unsigned long flags2;
 
 	if (WARN(!trans->wide_cmd_header &&
 		 group_id > IWL_ALWAYS_LONG_GROUP,

@@ -1593,10 +1594,10 @@ static int iwl_pcie_enqueue_hcmd(struct
 		goto free_dup_buf;
 	}
 
-	spin_lock_bh(&txq->lock);
+	spin_lock_irqsave(&txq->lock, flags2);
 
 	if (iwl_queue_space(txq) < ((cmd->flags & CMD_ASYNC) ? 2 : 1)) {
-		spin_unlock_bh(&txq->lock);
+		spin_unlock_irqrestore(&txq->lock, flags2);
 
 		IWL_ERR(trans, "No space in command queue\n");
 		iwl_op_mode_cmd_queue_full(trans->op_mode);

@@ -1757,7 +1758,7 @@ static int iwl_pcie_enqueue_hcmd(struct
 	spin_unlock_irqrestore(&trans_pcie->reg_lock, flags);
 
  out:
-	spin_unlock_bh(&txq->lock);
+	spin_unlock_irqrestore(&txq->lock, flags2);
  free_dup_buf:
 	if (idx < 0)
 		kfree(dup_buf);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #20 lore raw

PATCH 20/240 PCI: PM: Do not read power state in pci_enable_device_flags()

In reply to Greg Kroah-Hartman

From: Rafael J. Wysocki <[email protected]>

[ Upstream commit 4514d991d99211f225d83b7e640285f29f0755d0 ]

It should not be necessary to update the current_state field of struct pci_dev in pci_enable_device_flags() before calling do_pci_enable_device() for the device, because none of the code between that point and the pci_set_power_state() call in do_pci_enable_device() invoked later depends on it.

Moreover, doing that is actively harmful in some cases. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward.

To avoid such issues it is better to leave the current_state value as is until it is changed to PCI_D0 by do_pci_enable_device() as appropriate. However, the power state of the device is not changed to PCI_D0 if it is already enabled when pci_enable_device_flags() gets called for it, so update its current_state in that case, but use pci_update_current_state() covering platform PM too for that.

Link https://lore.kernel.org/lkml/[email protected]/ open here

Reported-by Maximilian Luz <[email protected]>

Tested-by Maximilian Luz <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Reviewed-by Mika Westerberg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pci/pci.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

drivers/pci/pci.c +3 ~~-13~~

index e09653c73ab4..acd89fa9820c 100644
@@ -1378,20 +1378,10 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
 	int err;
 	int i, bars = 0;
 
-	/*
-	 * Power state could be unknown at this point, either due to a fresh
-	 * boot or a device removal call.  So get the current power state
-	 * so that things like MSI message writing will behave as expected
-	 * (e.g. if the device really is in D0 at enable time).
-	 */
-	if (dev->pm_cap) {
-		u16 pmcsr;
-		pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &pmcsr);
-		dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
-	}
-
-	if (atomic_inc_return(&dev->enable_cnt) > 1)
+	if (atomic_inc_return(&dev->enable_cnt) > 1) {
+		pci_update_current_state(dev, dev->current_state);
 		return 0;		/* already enabled */
+	}
 
 	bridge = pci_upstream_bridge(dev);
 	if (bridge)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #22 lore raw

PATCH 22/240 spi: dln2: Fix reference leak to master

In reply to Greg Kroah-Hartman

From: Wei Yongjun <[email protected]>

[ Upstream commit 9b844b087124c1538d05f40fda8a4fec75af55be ]

Call spi_master_get() holds the reference count to master device, thus we need an additional spi_master_put() call to reduce the reference count, otherwise we will leak a reference to master.

This commit fix it by removing the unnecessary spi_master_get().

Reported-by Hulk Robot <[email protected]>

Signed-off-by Wei Yongjun <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-dln2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/spi/spi-dln2.c +1 -1

index b62a99caacc0..a41adea48618 100644
@@ -783,7 +783,7 @@ exit_free_master:
 
 static int dln2_spi_remove(struct platform_device *pdev)
 {
-	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+	struct spi_master *master = platform_get_drvdata(pdev);
 	struct dln2_spi *dln2 = spi_master_get_devdata(master);
 
 	pm_runtime_disable(&pdev->dev);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #21 lore raw

PATCH 21/240 x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)

In reply to Greg Kroah-Hartman

From: John Millikin <[email protected]>

[ Upstream commit 8abe7fc26ad8f28bfdf78adbed56acd1fa93f82d ]

When cross-compiling with Clang, the $(CLANG_FLAGS)' variable contains additional flags needed to build C and assembly sources for the target platform. Normally this variable is automatically included in $(KBUILD_CFLAGS)' via the top-level Makefile.

The x86 real-mode makefile builds `$(REALMODE_CFLAGS)' from a plain assignment and therefore drops the Clang flags. This causes Clang to not recognize x86-specific assembler directives:

arch/x86/realmode/rm/header.S:36:1: error: unknown directive .type real_mode_header STT_OBJECT ; .size real_mode_header, .-real_mode_header ^

Explicit propagation of $(CLANG_FLAGS)' to $(REALMODE_CFLAGS)', which is inherited by real-mode make rules, fixes cross-compilation with Clang for x86 targets.

Relevant flags:

* --target' sets the target architecture when cross-compiling. This flag must be set for both compilation and assembly (KBUILD_AFLAGS') to support architecture-specific assembler directives.

* -no-integrated-as' tells clang to assemble with GNU Assembler instead of its built-in LLVM assembler. This flag is set by default unless LLVM_IAS=1' is set, because the LLVM assembler can't yet parse certain GNU extensions.

Signed-off-by John Millikin <[email protected]>

Signed-off-by Nathan Chancellor <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

Acked-by Ard Biesheuvel <[email protected]>

Tested-by Sedat Dilek <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/Makefile | 1 +
 1 file changed, 1 insertion(+)

arch/x86/Makefile +1 -0

index 9ebbd4892557..0bc35e3e6c5c 100644
@@ -40,6 +40,7 @@ REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -ffreestanding
 REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -fno-stack-protector)
 REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -Wno-address-of-packed-member)
 REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align4))
+REALMODE_CFLAGS += $(CLANG_FLAGS)
 export REALMODE_CFLAGS
 
 # BITS is used as extension for files which are available in a 32 bit

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #23 lore raw

PATCH 23/240 spi: omap-100k: Fix reference leak to master

In reply to Greg Kroah-Hartman

From: Wei Yongjun <[email protected]>

[ Upstream commit a23faea76d4cf5f75decb574491e66f9ecd707e7 ]

Call spi_master_get() holds the reference count to master device, thus we need an additional spi_master_put() call to reduce the reference count, otherwise we will leak a reference to master.

This commit fix it by removing the unnecessary spi_master_get().

Reported-by Hulk Robot <[email protected]>

Signed-off-by Wei Yongjun <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-omap-100k.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/spi/spi-omap-100k.c +3 -3

index 76a8425be227..1eccdc4a4581 100644
@@ -435,7 +435,7 @@ err:
 
 static int omap1_spi100k_remove(struct platform_device *pdev)
 {
-	struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+	struct spi_master *master = platform_get_drvdata(pdev);
 	struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
 
 	pm_runtime_disable(&pdev->dev);

@@ -449,7 +449,7 @@ static int omap1_spi100k_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM
 static int omap1_spi100k_runtime_suspend(struct device *dev)
 {
-	struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+	struct spi_master *master = dev_get_drvdata(dev);
 	struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
 
 	clk_disable_unprepare(spi100k->ick);

@@ -460,7 +460,7 @@ static int omap1_spi100k_runtime_suspend(struct device *dev)
 
 static int omap1_spi100k_runtime_resume(struct device *dev)
 {
-	struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+	struct spi_master *master = dev_get_drvdata(dev);
 	struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
 	int ret;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #24 lore raw

PATCH 24/240 intel_th: Consistency and off-by-one fix

In reply to Greg Kroah-Hartman

From: Pavel Machek <[email protected]>

[ Upstream commit 18ffbc47d45a1489b664dd68fb3a7610a6e1dea3 ]

Consistently use "< ... +1" in for loops.

Fix of-by-one in for_each_set_bit().

Signed-off-by Pavel Machek <[email protected]>

Signed-off-by Alexander Shishkin <[email protected]>

Link https://lore.kernel.org/lkml/20190724095841.GA6952@amd/ open here

Reviewed-by Andy Shevchenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwtracing/intel_th/gth.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/hwtracing/intel_th/gth.c +2 -2

index 98a4cb5d4993..9c236c88bc7b 100644
@@ -485,7 +485,7 @@ static void intel_th_gth_disable(struct intel_th_device *thdev,
 	output->active = false;
 
 	for_each_set_bit(master, gth->output[output->port].master,
-			 TH_CONFIGURABLE_MASTERS) {
+			 TH_CONFIGURABLE_MASTERS + 1) {
 		gth_master_set(gth, master, -1);
 	}
 	spin_unlock(&gth->gth_lock);

@@ -605,7 +605,7 @@ static void intel_th_gth_unassign(struct intel_th_device *thdev,
 	othdev->output.port = -1;
 	othdev->output.active = false;
 	gth->output[port].output = NULL;
-	for (master = 0; master <= TH_CONFIGURABLE_MASTERS; master++)
+	for (master = 0; master < TH_CONFIGURABLE_MASTERS + 1; master++)
 		if (gth->master[master] == port)
 			gth->master[master] = -1;
 	spin_unlock(&gth->gth_lock);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #25 lore raw

PATCH 25/240 phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit e1723d8b87b73ab363256e7ca3af3ddb75855680 ]

This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free.

Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself.

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/phy/phy-twl4030-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/phy/phy-twl4030-usb.c +1 -1

index ddb530ee2255..9d57695e1f21 100644
@@ -798,7 +798,7 @@ static int twl4030_usb_remove(struct platform_device *pdev)
 
 	usb_remove_phy(&twl->phy);
 	pm_runtime_get_sync(twl->dev);
-	cancel_delayed_work(&twl->id_workaround_work);
+	cancel_delayed_work_sync(&twl->id_workaround_work);
 	device_remove_file(twl->dev, &dev_attr_vbus);
 
 	/* set transceiver mode to power on defaults */

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:46 UTC #26 lore raw

PATCH 26/240 btrfs: convert logic BUG_ON()s in replace_path to ASSERT()s

In reply to Greg Kroah-Hartman

From: Josef Bacik <[email protected]>

[ Upstream commit 7a9213a93546e7eaef90e6e153af6b8fc7553f10 ]

A few BUG_ON()'s in replace_path are purely to keep us from making logical mistakes, so replace them with ASSERT()'s.

Reviewed-by Qu Wenruo <[email protected]>

Signed-off-by Josef Bacik <[email protected]>

Reviewed-by David Sterba <[email protected]>

Signed-off-by David Sterba <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/btrfs/relocation.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

fs/btrfs/relocation.c +3 -3

index cd5b86d80e7a..5caf4dbdd801 100644
@@ -1801,8 +1801,8 @@ int replace_path(struct btrfs_trans_handle *trans,
 	int ret;
 	int slot;
 
-	BUG_ON(src->root_key.objectid != BTRFS_TREE_RELOC_OBJECTID);
-	BUG_ON(dest->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID);
+	ASSERT(src->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID);
+	ASSERT(dest->root_key.objectid != BTRFS_TREE_RELOC_OBJECTID);
 
 	last_snapshot = btrfs_root_last_snapshot(&src->root_item);
 again:

@@ -1834,7 +1834,7 @@ again:
 	parent = eb;
 	while (1) {
 		level = btrfs_header_level(parent);
-		BUG_ON(level < lowest_level);
+		ASSERT(level >= lowest_level);
 
 		ret = btrfs_bin_search(parent, &key, level, &slot);
 		if (ret && slot > 0)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #28 lore raw

PATCH 28/240 media: ite-cir: check for receive overflow

In reply to Greg Kroah-Hartman

From: Sean Young <[email protected]>

[ Upstream commit 28c7afb07ccfc0a939bb06ac1e7afe669901c65a ]

It's best if this condition is reported.

Signed-off-by Sean Young <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/rc/ite-cir.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/media/rc/ite-cir.c +7 -1

index 63165d324fff..7d3e50d94d86 100644
@@ -292,8 +292,14 @@ static irqreturn_t ite_cir_isr(int irq, void *data)
 	/* read the interrupt flags */
 	iflags = dev->params.get_irq_causes(dev);
 
+	/* Check for RX overflow */
+	if (iflags & ITE_IRQ_RX_FIFO_OVERRUN) {
+		dev_warn(&dev->rdev->dev, "receive overflow\n");
+		ir_raw_event_reset(dev->rdev);
+	}
+
 	/* check for the receive interrupt */
-	if (iflags & (ITE_IRQ_RX_FIFO | ITE_IRQ_RX_FIFO_OVERRUN)) {
+	if (iflags & ITE_IRQ_RX_FIFO) {
 		/* read the FIFO bytes */
 		rx_bytes =
 			dev->params.get_rx_bytes(dev, rx_buf,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #27 lore raw

PATCH 27/240 scsi: target: pscsi: Fix warning in pscsi_complete_cmd()

In reply to Greg Kroah-Hartman

From: Chaitanya Kulkarni <[email protected]>

[ Upstream commit fd48c056a32ed6e7754c7c475490f3bed54ed378 ]

This fixes a compilation warning in pscsi_complete_cmd():

drivers/target/target_core_pscsi.c: In function ‘pscsi_complete_cmd’:
drivers/target/target_core_pscsi.c:624:5: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Mike Christie <[email protected]>

Reviewed-by Johannes Thumshirn <[email protected]>

Signed-off-by Chaitanya Kulkarni <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/target/target_core_pscsi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/target/target_core_pscsi.c +2 -1

index 079db0bd3917..089ba39f76a2 100644
@@ -629,8 +629,9 @@ static void pscsi_transport_complete(struct se_cmd *cmd, struct scatterlist *sg,
 			unsigned char *buf;
 
 			buf = transport_kmap_data_sg(cmd);
-			if (!buf)
+			if (!buf) {
 				; /* XXX: TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE */
+			}
 
 			if (cdb[0] == MODE_SENSE_10) {
 				if (!(buf[3] & 0x80))

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #29 lore raw

PATCH 29/240 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged

In reply to Greg Kroah-Hartman

From: Hans de Goede <[email protected]>

[ Upstream commit c309a3e8793f7e01c4a4ec7960658380572cb576 ]

When the jack is partially inserted and then removed again it may be removed while the hpdet code is running. In this case the following may happen:

1. The "JACKDET rise" or ""JACKDET fall" IRQ triggers
2. arizona_jackdet runs and takes info->lock
3. The "HPDET" IRQ triggers
4. arizona_hpdet_irq runs, blocks on info->lock
5. arizona_jackdet calls arizona_stop_mic() and clears info->hpdet_done
6. arizona_jackdet releases info->lock
7. arizona_hpdet_irq now can continue running and:
7.1 Calls arizona_start_mic() (if a mic was detected)
7.2 sets info->hpdet_done

Step 7 is undesirable / a bug:
7.1 causes the device to stay in a high power-state (with MICVDD enabled) 7.2 causes hpdet to not run on the next jack insertion, which in turn
causes the EXTCON_JACK_HEADPHONE state to never get set

This fixes both issues by skipping these 2 steps when arizona_hpdet_irq runs after the jack has been unplugged.

Signed-off-by Hans de Goede <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Acked-by Charles Keepax <[email protected]>

Tested-by Charles Keepax <[email protected]>

Acked-by Chanwoo Choi <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/extcon/extcon-arizona.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

drivers/extcon/extcon-arizona.c +9 -8

index 4c0b6df8b5dd..1d06d99b8bd9 100644
@@ -601,7 +601,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
 	struct arizona *arizona = info->arizona;
 	int id_gpio = arizona->pdata.hpdet_id_gpio;
 	unsigned int report = EXTCON_JACK_HEADPHONE;
-	int ret, reading;
+	int ret, reading, state;
 	bool mic = false;
 
 	mutex_lock(&info->lock);

@@ -614,12 +614,11 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
 	}
 
 	/* If the cable was removed while measuring ignore the result */
-	ret = extcon_get_state(info->edev, EXTCON_MECHANICAL);
-	if (ret < 0) {
-		dev_err(arizona->dev, "Failed to check cable state: %d\n",
-			ret);
+	state = extcon_get_state(info->edev, EXTCON_MECHANICAL);
+	if (state < 0) {
+		dev_err(arizona->dev, "Failed to check cable state: %d\n", state);
 		goto out;
-	} else if (!ret) {
+	} else if (!state) {
 		dev_dbg(arizona->dev, "Ignoring HPDET for removed cable\n");
 		goto done;
 	}

@@ -672,7 +671,7 @@ done:
 			   ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
 
 	/* If we have a mic then reenable MICDET */
-	if (mic || info->mic)
+	if (state && (mic || info->mic))
 		arizona_start_mic(info);
 
 	if (info->hpdet_active) {

@@ -680,7 +679,9 @@ done:
 		info->hpdet_active = false;
 	}
 
-	info->hpdet_done = true;
+	/* Do not set hp_det done when the cable has been unplugged */
+	if (state)
+		info->hpdet_done = true;
 
 out:
 	mutex_unlock(&info->lock);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #3 lore raw

PATCH 3/240 ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit 64f40f9be14106e7df0098c427cb60be645bddb7 upstream.

ToneLab EX guitar pedal device requires the same quirk like ToneLab ST for supporting the MIDI.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=212593

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/usb/quirks-table.h |   10 ++++++++++
 1 file changed, 10 insertions(+)

sound/usb/quirks-table.h +10 -0

@@ -2479,6 +2479,16 @@ YAMAHA_DEVICE(0x7010, "UB99"),
 	}
 },
 
+{
+	USB_DEVICE_VENDOR_SPEC(0x0944, 0x0204),
+	.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
+		.vendor_name = "KORG, Inc.",
+		/* .product_name = "ToneLab EX", */
+		.ifnum = 3,
+		.type = QUIRK_MIDI_STANDARD_INTERFACE,
+	}
+},
+
 /* AKAI devices */
 {
 	USB_DEVICE(0x09e8, 0x0062),

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #30 lore raw

PATCH 30/240 media: media/saa7164: fix saa7164_encoder_register() memory leak bugs

In reply to Greg Kroah-Hartman

From: Daniel Niv <[email protected]>

[ Upstream commit c759b2970c561e3b56aa030deb13db104262adfe ]

Add a fix for the memory leak bugs that can occur when the saa7164_encoder_register() function fails.
The function allocates memory without explicitly freeing
it when errors occur.
Add a better error handling that deallocate the unused buffers before the function exits during a fail.

Signed-off-by Daniel Niv <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/pci/saa7164/saa7164-encoder.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

drivers/media/pci/saa7164/saa7164-encoder.c +11 -9

index 32a353d162e7..f2e6fbfa019f 100644
@@ -1030,7 +1030,7 @@ int saa7164_encoder_register(struct saa7164_port *port)
 		       "(errno = %d), NO PCI configuration\n",
 			__func__, result);
 		result = -ENOMEM;
-		goto failed;
+		goto fail_pci;
 	}
 
 	/* Establish encoder defaults here */

@@ -1084,7 +1084,7 @@ int saa7164_encoder_register(struct saa7164_port *port)
 			  100000, ENCODER_DEF_BITRATE);
 	if (hdl->error) {
 		result = hdl->error;
-		goto failed;
+		goto fail_hdl;
 	}
 
 	port->std = V4L2_STD_NTSC_M;

@@ -1102,7 +1102,7 @@ int saa7164_encoder_register(struct saa7164_port *port)
 		printk(KERN_INFO "%s: can't allocate mpeg device\n",
 			dev->name);
 		result = -ENOMEM;
-		goto failed;
+		goto fail_hdl;
 	}
 
 	port->v4l_device->ctrl_handler = hdl;

@@ -1113,10 +1113,7 @@ int saa7164_encoder_register(struct saa7164_port *port)
 	if (result < 0) {
 		printk(KERN_INFO "%s: can't register mpeg device\n",
 			dev->name);
-		/* TODO: We're going to leak here if we don't dealloc
-		 The buffers above. The unreg function can't deal wit it.
-		*/
-		goto failed;
+		goto fail_reg;
 	}
 
 	printk(KERN_INFO "%s: registered device video%d [mpeg]\n",

@@ -1138,9 +1135,14 @@ int saa7164_encoder_register(struct saa7164_port *port)
 
 	saa7164_api_set_encoder(port);
 	saa7164_api_get_encoder(port);
+	return 0;
 
-	result = 0;
-failed:
+fail_reg:
+	video_device_release(port->v4l_device);
+	port->v4l_device = NULL;
+fail_hdl:
+	v4l2_ctrl_handler_free(hdl);
+fail_pci:
 	return result;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #31 lore raw

PATCH 31/240 media: gspca/sq905.c: fix uninitialized variable

In reply to Greg Kroah-Hartman

From: Hans Verkuil <[email protected]>

[ Upstream commit eaaea4681984c79d2b2b160387b297477f0c1aab ]

act_len can be uninitialized if usb_bulk_msg() returns an error. Set it to 0 to avoid a KMSAN error.

Signed-off-by Hans Verkuil <[email protected]>

Reported-by [email protected]

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/gspca/sq905.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/usb/gspca/sq905.c +1 -1

index a7ae0ec9fa91..03322d2b2e82 100644
@@ -172,7 +172,7 @@ static int
 sq905_read_data(struct gspca_dev *gspca_dev, u8 *data, int size, int need_lock)
 {
 	int ret;
-	int act_len;
+	int act_len = 0;
 
 	gspca_dev->usb_buf[0] = '\0';
 	if (need_lock)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #32 lore raw

PATCH 32/240 power: supply: Use IRQF_ONESHOT

In reply to Greg Kroah-Hartman

From: dongjian <[email protected]>

[ Upstream commit 2469b836fa835c67648acad17d62bc805236a6ea ]

Fixes coccicheck error:

drivers/power/supply/pm2301_charger.c:1089:7-27: ERROR:
drivers/power/supply/lp8788-charger.c:502:8-28: ERROR:
drivers/power/supply/tps65217_charger.c:239:8-33: ERROR:
drivers/power/supply/tps65090-charger.c:303:8-33: ERROR:

Threaded IRQ with no primary handler requested without IRQF_ONESHOT

Signed-off-by dongjian <[email protected]>

Signed-off-by Sebastian Reichel <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/power/supply/lp8788-charger.c   | 2 +-
 drivers/power/supply/pm2301_charger.c   | 2 +-
 drivers/power/supply/tps65090-charger.c | 2 +-
 drivers/power/supply/tps65217_charger.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

drivers/power/supply/lp8788-charger.c +1 -1

index c3075ea011b6..e800beff1f8f 100644
@@ -532,7 +532,7 @@ static int lp8788_set_irqs(struct platform_device *pdev,
 
 		ret = request_threaded_irq(virq, NULL,
 					lp8788_charger_irq_thread,
-					0, name, pchg);
+					IRQF_ONESHOT, name, pchg);
 		if (ret)
 			break;
 	}

drivers/power/supply/pm2301_charger.c +1 -1

index 78561b6884fc..9ef218d76aa9 100644
@@ -1098,7 +1098,7 @@ static int pm2xxx_wall_charger_probe(struct i2c_client *i2c_client,
 	ret = request_threaded_irq(gpio_to_irq(pm2->pdata->gpio_irq_number),
 				NULL,
 				pm2xxx_charger_irq[0].isr,
-				pm2->pdata->irq_type,
+				pm2->pdata->irq_type | IRQF_ONESHOT,
 				pm2xxx_charger_irq[0].name, pm2);
 
 	if (ret != 0) {

drivers/power/supply/tps65090-charger.c +1 -1

index 1b4b5e09538e..297bf58f0d4f 100644
@@ -311,7 +311,7 @@ static int tps65090_charger_probe(struct platform_device *pdev)
 
 	if (irq != -ENXIO) {
 		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
-			tps65090_charger_isr, 0, "tps65090-charger", cdata);
+			tps65090_charger_isr, IRQF_ONESHOT, "tps65090-charger", cdata);
 		if (ret) {
 			dev_err(cdata->dev,
 				"Unable to register irq %d err %d\n", irq,

drivers/power/supply/tps65217_charger.c +1 -1

index 9fd019f9b88c..a6b4eb61b4bb 100644
@@ -238,7 +238,7 @@ static int tps65217_charger_probe(struct platform_device *pdev)
 	if (irq != -ENXIO) {
 		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
 						tps65217_charger_irq,
-						0, "tps65217-charger",
+						IRQF_ONESHOT, "tps65217-charger",
 						charger);
 		if (ret) {
 			dev_err(charger->dev,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #4 lore raw

PATCH 4/240 USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet

In reply to Greg Kroah-Hartman

From: Kai-Heng Feng <[email protected]>

commit 8f23fe35ff1e5491b4d279323a8209a31f03ae65 upstream.

This is another branded 8153 device that doesn't work well with LPM enabled:

[ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status -71

So disable LPM to resolve the issue.

Signed-off-by Kai-Heng Feng <[email protected]>

BugLink https://bugs.launchpad.net/bugs/1922651

Link https://lore.kernel.org/r/[email protected] open here

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/quirks.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/usb/core/quirks.c +3 -0

@@ -264,6 +264,9 @@ static const struct usb_device_id usb_qu
 	{ USB_DEVICE(0x1532, 0x0116), .driver_info =
 			USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
+	/* Lenovo ThinkPad USB-C Dock Gen2 Ethernet (RTL8153 GigE) */
+	{ USB_DEVICE(0x17ef, 0xa387), .driver_info = USB_QUIRK_NO_LPM },
+
 	/* BUILDWIN Photo Frame */
 	{ USB_DEVICE(0x1908, 0x1315), .driver_info =
 			USB_QUIRK_HONOR_BNUMINTERFACES },

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #6 lore raw

PATCH 6/240 platform/x86: thinkpad_acpi: Correct thermal sensor allocation

In reply to Greg Kroah-Hartman

From: Mark Pearson <[email protected]>

commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream.

On recent Thinkpad platforms it was reported that temp sensor 11 was always incorrectly displaying 66C. It turns out the reason for this is that this location in EC RAM is not a temperature sensor but is the power supply ID (offset 0xC2).

Based on feedback from the Lenovo firmware team the EC RAM version can be determined and for the current version (3) only the 0x78 to 0x7F range is used for temp sensors. I don't have any details for earlier versions so I have left the implementation unaltered there.

Note - in this block only 0x78 and 0x79 are officially designated (CPU & GPU sensors). The use of the other locations in the block will vary from platform to platform; but the existing logic to detect a sensor presence holds.

Signed-off-by Mark Pearson <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Hans de Goede <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/platform/x86/thinkpad_acpi.c |   31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

drivers/platform/x86/thinkpad_acpi.c +22 -9

@@ -6044,6 +6044,7 @@ enum thermal_access_mode {
 enum { /* TPACPI_THERMAL_TPEC_* */
 	TP_EC_THERMAL_TMP0 = 0x78,	/* ACPI EC regs TMP 0..7 */
 	TP_EC_THERMAL_TMP8 = 0xC0,	/* ACPI EC regs TMP 8..15 */
+	TP_EC_FUNCREV      = 0xEF,      /* ACPI EC Functional revision */
 	TP_EC_THERMAL_TMP_NA = -128,	/* ACPI EC sensor not available */
 
 	TPACPI_THERMAL_SENSOR_NA = -128000, /* Sensor not available */

@@ -6242,7 +6243,7 @@ static const struct attribute_group ther
 
 static int __init thermal_init(struct ibm_init_struct *iibm)
 {
-	u8 t, ta1, ta2;
+	u8 t, ta1, ta2, ver = 0;
 	int i;
 	int acpi_tmp7;
 	int res;

@@ -6257,7 +6258,14 @@ static int __init thermal_init(struct ib
 		 * 0x78-0x7F, 0xC0-0xC7.  Registers return 0x00 for
 		 * non-implemented, thermal sensors return 0x80 when
 		 * not available
+		 * The above rule is unfortunately flawed. This has been seen with
+		 * 0xC2 (power supply ID) causing thermal control problems.
+		 * The EC version can be determined by offset 0xEF and at least for
+		 * version 3 the Lenovo firmware team confirmed that registers 0xC0-0xC7
+		 * are not thermal registers.
 		 */
+		if (!acpi_ec_read(TP_EC_FUNCREV, &ver))
+			pr_warn("Thinkpad ACPI EC unable to access EC version\n");
 
 		ta1 = ta2 = 0;
 		for (i = 0; i < 8; i++) {

@@ -6267,11 +6275,13 @@ static int __init thermal_init(struct ib
 				ta1 = 0;
 				break;
 			}
-			if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, &t)) {
-				ta2 |= t;
-			} else {
-				ta1 = 0;
-				break;
+			if (ver < 3) {
+				if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, &t)) {
+					ta2 |= t;
+				} else {
+					ta1 = 0;
+					break;
+				}
 			}
 		}
 		if (ta1 == 0) {

@@ -6287,9 +6297,12 @@ static int __init thermal_init(struct ib
 				thermal_read_mode = TPACPI_THERMAL_NONE;
 			}
 		} else {
-			thermal_read_mode =
-			    (ta2 != 0) ?
-			    TPACPI_THERMAL_TPEC_16 : TPACPI_THERMAL_TPEC_8;
+			if (ver >= 3)
+				thermal_read_mode = TPACPI_THERMAL_TPEC_8;
+			else
+				thermal_read_mode =
+					(ta2 != 0) ?
+					TPACPI_THERMAL_TPEC_16 : TPACPI_THERMAL_TPEC_8;
 		}
 	} else if (acpi_tmp7) {
 		if (tpacpi_is_ibm() &&

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #5 lore raw

PATCH 5/240 USB: Add reset-resume quirk for WD19s Realtek Hub

In reply to Greg Kroah-Hartman

From: Chris Chiu <[email protected]>

commit ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a upstream.

Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work after the system resumes from suspend with remote wakeup enabled device connected:

[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=5487 Rev= 1.47
S:  Manufacturer=Dell Inc.
S:  Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on the suspend feature for the specified port of the hub. The port seems to be in an unknown state so the hub_activate during resume fails the hub_port_status, then the hub will fail to work.

The quirky hub needs the reset-resume quirk to function correctly.

Acked-by Alan Stern <[email protected]>

Signed-off-by Chris Chiu <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/quirks.c |    1 +
 1 file changed, 1 insertion(+)

drivers/usb/core/quirks.c +1 -0

@@ -245,6 +245,7 @@ static const struct usb_device_id usb_qu
 
 	/* Realtek hub in Dell WD19 (Type-C) */
 	{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+	{ USB_DEVICE(0x0bda, 0x5487), .driver_info = USB_QUIRK_RESET_RESUME },
 
 	/* Generic RTL8153 based ethernet adapters */
 	{ USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #7 lore raw

PATCH 7/240 s390/disassembler: increase ebpf disasm buffer size

In reply to Greg Kroah-Hartman

From: Vasily Gorbik <[email protected]>

commit 6f3353c2d2b3eb4de52e9704cb962712033db181 upstream.

Current ebpf disassembly buffer size of 64 is too small. E.g. this line takes 65 bytes:
01fffff8005822e: ec8100ed8065\tclgrj\t%r8,%r1,8,001fffff80058408\n\0

Double the buffer size like it is done for the kernel disassembly buffer.

Fixes the following KASAN finding:

UG: KASAN: stack-out-of-bounds in print_fn_code+0x34c/0x380

Write of size 1 at addr 001fff800ad5f970 by task test_progs/853

CPU: 53 PID: 853 Comm: test_progs Not tainted
5.12.0-rc7-23786-g23457d86b1f0-dirty #19
Hardware name: IBM 3906 M04 704 (LPAR)
Call Trace:
 [<0000000cd8e0538a>] show_stack+0x17a/0x1668
 [<0000000cd8e2a5d8>] dump_stack+0x140/0x1b8
 [<0000000cd8e16e74>] print_address_description.constprop.0+0x54/0x260
 [<0000000cd75a8698>] kasan_report+0xc8/0x130
 [<0000000cd6e26da4>] print_fn_code+0x34c/0x380
 [<0000000cd6ea0f4e>] bpf_int_jit_compile+0xe3e/0xe58
 [<0000000cd72c4c88>] bpf_prog_select_runtime+0x5b8/0x9c0
 [<0000000cd72d1bf8>] bpf_prog_load+0xa78/0x19c0
 [<0000000cd72d7ad6>] __do_sys_bpf.part.0+0x18e/0x768
 [<0000000cd6e0f392>] do_syscall+0x12a/0x220
 [<0000000cd8e333f8>] __do_syscall+0x98/0xc8
 [<0000000cd8e54834>] system_call+0x6c/0x94
1 lock held by test_progs/853:
 #0: 0000000cd9bf7460 (report_lock){....}-{2:2}, at:
     kasan_report+0x96/0x130

addr 001fff800ad5f970 is located in stack of task test_progs/853 at offset 96 in frame:
print_fn_code+0x0/0x380
this frame has 1 object:
[32, 96) 'buffer'

Memory state around the buggy address:
 001fff800ad5f800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 001fff800ad5f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>001fff800ad5f900: 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 f3 f3
                                                             ^
 001fff800ad5f980: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 001fff800ad5fa00: 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00

Cc <[email protected]>

Reviewed-by Heiko Carstens <[email protected]>

Signed-off-by Vasily Gorbik <[email protected]>

Signed-off-by Heiko Carstens <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/kernel/dis.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/s390/kernel/dis.c +1 -1

@@ -2026,7 +2026,7 @@ void show_code(struct pt_regs *regs)
 
 void print_fn_code(unsigned char *code, unsigned long len)
 {
-	char buffer[64], *ptr;
+	char buffer[128], *ptr;
 	int opsize, i;
 
 	while (len) {

Greg Kroah-Hartman

author maintainer

2021-05-20 10:47 UTC #8 lore raw

PATCH 8/240 ACPI: custom_method: fix potential use-after-free issue

In reply to Greg Kroah-Hartman

From: Mark Langsdorf <[email protected]>

commit e483bb9a991bdae29a0caa4b3a6d002c968f94aa upstream.

In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it.

Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function.

Fixes 03d1571d9513 ("ACPI: custom_method: fix memory leaks")

Signed-off-by Mark Langsdorf <[email protected]>

Cc 5.4+ <[email protected]> # 5.4+

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/custom_method.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/acpi/custom_method.c +1 -1

@@ -50,6 +50,7 @@ static ssize_t cm_write(struct file *fil
 	    (*ppos + count < count) ||
 	    (count > uncopied_bytes)) {
 		kfree(buf);
+		buf = NULL;
 		return -EINVAL;
 	}

@@ -71,7 +72,6 @@ static ssize_t cm_write(struct file *fil
 		add_taint(TAINT_OVERRIDDEN_ACPI_TABLE, LOCKDEP_NOW_UNRELIABLE);
 	}
 
-	kfree(buf);
 	return count;
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #0 lore raw

cover 4.9.269-rc1 review

This is the start of the stable review cycle for the 4.9.269 release. There are 240 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 22 May 2021 09:20:38 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.269-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.9.269-rc1

Eric Dumazet <[email protected]>
ipv6: remove extra dev_hold() for fallback tunnels

Christophe JAILLET <[email protected]>
xhci: Do not use GFP_KERNEL in (potentially) atomic context

Eric Dumazet <[email protected]>
ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods

Eric Dumazet <[email protected]>
sit: proper dev_{hold|put} in ndo_[un]init methods

Zqiang <[email protected]>
lib: stackdepot: turn depot_lock spinlock to raw_spinlock

Hui Wang <[email protected]>
ALSA: hda: generic: change the DAC ctl name for LO+SPK or LO+HP

Jeff Layton <[email protected]>
ceph: fix fscache invalidation

Johannes Berg <[email protected]>
um: Mark all kernel symbols as local

Hans de Goede <[email protected]>
Input: silead - add workaround for x86 BIOS-es which bring the chip up in a stuck state

Feilong Lin <[email protected]>
ACPI / hotplug / PCI: Fix reference count leak in enable_slot()

Ard Biesheuvel <[email protected]>
ARM: 9058/1: cache-v7: refactor v7_invalidate_l1 to avoid clobbering r5/r6

Arnd Bergmann <[email protected]>
isdn: capi: fix mismatched prototypes

Kaixu Xia <[email protected]>
cxgb4: Fix the -Wmisleading-indentation warning

Arnd Bergmann <[email protected]>
usb: sl811-hcd: improve misleading indentation

Arnd Bergmann <[email protected]>
kgdb: fix gcc-11 warning on indentation

Peter Foley <[email protected]>
extcon: adc-jack: Fix incompatible pointer type warning

Arnd Bergmann <[email protected]>
x86/msr: Fix wr/rdmsr_safe_regs_on_cpu() prototypes

Paweł Chmiel <[email protected]>
clk: exynos7: Mark aclk_fsys1_200 as critical

Jonathon Reinhart <[email protected]>
netfilter: conntrack: Make global sysctls readonly in non-init netns

Greg Kroah-Hartman <[email protected]>
kobject_uevent: remove warning in init_uevent_argv()

Mikulas Patocka <[email protected]>
dm ioctl: fix out of bounds array access when no devices

Lukasz Luba <[email protected]>
thermal/core/fair share: Lock the thermal zone while looping over instances

Maciej W. Rozycki <[email protected]>
MIPS: Avoid handcoded DIVU in `__div64_32' altogether

Maciej W. Rozycki <[email protected]>
MIPS: Avoid DIVU in `__div64_32' is result would be zero

Maciej W. Rozycki <[email protected]>
MIPS: Reinstate platform `__div64_32' handler

Maciej W. Rozycki <[email protected]>
FDDI: defxx: Make MMIO the configuration default except for EISA

Thomas Gleixner <[email protected]>
KVM: x86: Cancel pvclock_gtod_work on module removal

Chunfeng Yun <[email protected]>
usb: core: hub: fix race condition about TRSMRCY of resume

Phil Elwell <[email protected]>
usb: dwc2: Fix gadget DMA unmap direction

Maximilian Luz <[email protected]>
usb: xhci: Increase timeout for HC halt

Christophe JAILLET <[email protected]>
ACPI: scan: Fix a memory leak in an error handling path

Christophe JAILLET <[email protected]>
usb: fotg210-hcd: Fix an error message

Dinghao Liu <[email protected]>
iio: proximity: pulsedlight: Fix rumtime PM imbalance on error

Phillip Lougher <[email protected]>
squashfs: fix divide error in calculate_skip()

Michael Ellerman <[email protected]>
powerpc/64s: Fix crashes when toggling entry flush barrier

Vineet Gupta <[email protected]>
ARC: entry: fix off-by-one error in syscall number validation

Jia-Ju Bai <[email protected]>
kernel: kexec_file: fix error return code of kexec_calculate_store_digests()

Miaohe Lin <[email protected]>
ksm: fix potential missing rmap_item for stable_node

Miaohe Lin <[email protected]>
mm/hugeltb: handle the error case in hugetlb_fix_reserve_counts()

Miaohe Lin <[email protected]>
khugepaged: fix wrong result value for trace_mm_collapse_huge_page_isolate()

Kees Cook <[email protected]>
drm/radeon: Fix off-by-one power_state index heap overwrite

Xin Long <[email protected]>
sctp: fix a SCTP_MIB_CURRESTAB leak in sctp_sf_do_dupcook_b

Olga Kornievskaia <[email protected]>
NFSv4.2 fix handling of sr_eof in SEEK's reply

Nikola Livic <[email protected]>
pNFS/flexfiles: fix incorrect size check in decode_nfs_fh()

Trond Myklebust <[email protected]>
NFS: Deal correctly with attribute generation counter overflow

Trond Myklebust <[email protected]>
NFSv4.2: Always flush out writes in nfs42_proc_fallocate()

Zhen Lei <[email protected]>
ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook

Dmitry Baryshkov <[email protected]>
PCI: Release OF node in pci_scan_device()'s error path

Colin Ian King <[email protected]>
f2fs: fix a redundant call to f2fs_balance_fs if an error occurs

David Ward <[email protected]>
ASoC: rt286: Make RT286_SET_GPIO_* readable and writable

Felix Fietkau <[email protected]>
net: ethernet: mtk_eth_soc: fix RX VLAN offload

Alexey Kardashevskiy <[email protected]>
powerpc/iommu: Annotate nested lock for lockdep

Gustavo A. R. Silva <[email protected]>
wl3501_cs: Fix out-of-bounds warnings in wl3501_mgmt_join

Gustavo A. R. Silva <[email protected]>
wl3501_cs: Fix out-of-bounds warnings in wl3501_send_pkt

Michael Ellerman <[email protected]>
powerpc/pseries: Stop calling printk in rtas_stop_self()

Yaqi Chen <[email protected]>
samples/bpf: Fix broken tracex1 due to kprobe argument change

David Ward <[email protected]>
ASoC: rt286: Generalize support for ALC3263 codec

Gustavo A. R. Silva <[email protected]>
sctp: Fix out-of-bounds warning in sctp_process_asconf_param()

Mihai Moldovan <[email protected]>
kconfig: nconf: stop endless search loops

Yonghong Song <[email protected]>
selftests: Set CC to clang in lib.mk if LLVM is set

Miklos Szeredi <[email protected]>
cuse: prevent clone

Emmanuel Grumbach <[email protected]>
mac80211: clear the beacon's CRC after channel switch

Eric Dumazet <[email protected]>
ip6_vti: proper dev_{hold|put} in ndo_[un]init methods

Tetsuo Handa <[email protected]>
Bluetooth: initialize skb_queue_head at l2cap_chan_create()

Archie Pusaka <[email protected]>
Bluetooth: Set CONF_NOT_COMPLETE as l2cap_chan default

Tong Zhang <[email protected]>
ALSA: rme9652: don't disable if not enabled

Tong Zhang <[email protected]>
ALSA: hdspm: don't disable if not enabled

Tong Zhang <[email protected]>
ALSA: hdsp: don't disable if not enabled

Jonathan McDowell <[email protected]>
net: stmmac: Set FIFO sizes for ipq806x

Hoang Le <[email protected]>
tipc: convert dest node's address to network order

Alexander Aring <[email protected]>
fs: dlm: fix debugfs dump

Quentin Perret <[email protected]>
Revert "fdt: Properly handle "no-map" field in the memory region"

Quentin Perret <[email protected]>
Revert "of/fdt: Make sure no-map does not remove already reserved regions"

Xin Long <[email protected]>
sctp: delay auto_asconf init until binding the first addr

Xin Long <[email protected]>
Revert "net/sctp: fix race condition in sctp_destroy_sock"

Dan Carpenter <[email protected]>
kfifo: fix ternary sign extension bugs

Lv Yunlong <[email protected]>
net:nfc:digital: Fix a double free in digital_tg_recv_dep_req

Lv Yunlong <[email protected]>
net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send

Christophe Leroy <[email protected]>
powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add')

Toke Høiland-Jørgensen <[email protected]>
ath9k: Fix error check in ath9k_hw_read_revisions() for PCI devices

Colin Ian King <[email protected]>
net: davinci_emac: Fix incorrect masking of tx and rx error channel

Sindhu Devale <[email protected]>
RDMA/i40iw: Fix error unwinding when i40iw_hmc_sd_one fails

Stefano Garzarella <[email protected]>
vsock/vmci: log once the failed queue pair allocation

Lv Yunlong <[email protected]>
mwl8k: Fix a double Free in mwl8k_probe_hw

Sergey Shtylyov <[email protected]>
i2c: sh7760: fix IRQ error path

Tyrel Datwyler <[email protected]>
powerpc/pseries: extract host bridge from pci_bus prior to bus removal

Ilya Lipnitskiy <[email protected]>
MIPS: pci-legacy: stop using of_pci_range_to_resource

Sergey Shtylyov <[email protected]>

    i2c: sh7760: add IRQ check

Sergey Shtylyov <[email protected]>

    i2c: jz4780: add IRQ check

Sergey Shtylyov <[email protected]>
i2c: emev2: add IRQ check

Sergey Shtylyov <[email protected]>
i2c: cadence: add IRQ check

Colin Ian King <[email protected]>
net: thunderx: Fix unintentional sign extension issue

Colin Ian King <[email protected]>
mt7601u: fix always true expression

Johannes Berg <[email protected]>
mac80211: bail out if cipher schemes are invalid

Randy Dunlap <[email protected]>
powerpc: iommu: fix build when neither PCI or IBMVIO is set

Athira Rajeev <[email protected]>
powerpc/perf: Fix PMU constraint check for EBB events

Colin Ian King <[email protected]>
liquidio: Fix unintented sign extension of a left shift of a u16

Takashi Iwai <[email protected]>
ALSA: usb-audio: Add error checks for usb_driver_claim_interface() calls

Dan Carpenter <[email protected]>
nfc: pn533: prevent potential memory corruption

Jia Zhou <[email protected]>
ALSA: core: remove redundant spin_lock pair in snd_card_disconnect

Nathan Chancellor <[email protected]>
powerpc/prom: Mark identical_pvr_fixup as __init

Xie He <[email protected]>
net: lapbether: Prevent racing when checking whether the netif is running

Arnaldo Carvalho de Melo <[email protected]>
perf symbols: Fix dso__fprintf_symbols_by_name() to return the number of printed chars

Maxim Mikityanskiy <[email protected]>
HID: plantronics: Workaround for double volume key presses

Nathan Chancellor <[email protected]>
x86/events/amd/iommu: Fix sysfs type mismatch

Dan Carpenter <[email protected]>
HSI: core: fix resource leaks in hsi_add_client_from_dt()

Sergey Shtylyov <[email protected]>

    scsi: sni_53c710: Add IRQ check

Sergey Shtylyov <[email protected]>
scsi: sun3x_esp: Add IRQ check

Sergey Shtylyov <[email protected]>
scsi: jazz_esp: Add IRQ check

Colin Ian King <[email protected]>
clk: uniphier: Fix potential infinite loop

Arnd Bergmann <[email protected]>
media: dvb-usb-remote: fix dvb_usb_nec_rc_key_to_event type mismatch

Arnd Bergmann <[email protected]>
scsi: fcoe: Fix mismatched fcoe_wwn_from_mac declaration

Sergey Shtylyov <[email protected]>
ata: libahci_platform: fix IRQ check

Sergey Shtylyov <[email protected]>
sata_mv: add IRQ checks

Sergey Shtylyov <[email protected]>
pata_ipx4xx_cf: fix IRQ check

Sergey Shtylyov <[email protected]>
pata_arasan_cf: fix IRQ check

Colin Ian King <[email protected]>
media: m88rs6000t: avoid potential out-of-bounds reads on arrays

Yang Yingliang <[email protected]>
media: omap4iss: return error code when omap4iss_get() failed

Colin Ian King <[email protected]>

    media: vivid: fix assignment of dev->fbuf_out_flags

Tetsuo Handa <[email protected]>
ttyprintk: Add TTY hangup callback.

Michael Kelley <[email protected]>
Drivers: hv: vmbus: Increase wait time for VMbus unload

Ingo Molnar <[email protected]>
x86/platform/uv: Fix !KEXEC build failure

He Ying <[email protected]>
firmware: qcom-scm: Fix QCOM_SCM configuration

Johan Hovold <[email protected]>
tty: fix return value for unsupported ioctls

Johan Hovold <[email protected]>
tty: actually undefine superseded ASYNC flags

Johan Hovold <[email protected]>
USB: cdc-acm: fix unprivileged TIOCCSERIAL

Colin Ian King <[email protected]>
usb: gadget: r8a66597: Add missing null check on return from platform_get_resource

Lv Yunlong <[email protected]>
crypto: qat - Fix a double free in adf_create_ring

Johan Hovold <[email protected]>
staging: greybus: uart: fix unprivileged TIOCCSERIAL

Colin Ian King <[email protected]>
staging: rtl8192u: Fix potential infinite loop

Lv Yunlong <[email protected]>
mtd: rawnand: gpmi: Fix a double free in gpmi_nand_init

Giovanni Cabiddu <[email protected]>
crypto: qat - fix error path in adf_isr_resource_alloc()

Pan Bian <[email protected]>
bus: qcom: Put child node before return

Michael Walle <[email protected]>
mtd: require write permissions for locking and badblock ioctls

Fabian Vogt <[email protected]>
fotg210-udc: Complete OUT requests on short packets

Fabian Vogt <[email protected]>
fotg210-udc: Don't DMA more than the buffer can take

Fabian Vogt <[email protected]>
fotg210-udc: Mask GRP2 interrupts we don't handle

Fabian Vogt <[email protected]>
fotg210-udc: Remove a dubious condition leading to fotg210_done

Fabian Vogt <[email protected]>
fotg210-udc: Fix EP0 IN requests bigger than two packets

Fabian Vogt <[email protected]>
fotg210-udc: Fix DMA on EP0 for length > max packet size

Tong Zhang <[email protected]>
crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init

Tong Zhang <[email protected]>
crypto: qat - don't release uninitialized resources

Andy Shevchenko <[email protected]>
usb: gadget: pch_udc: Check for DMA mapping error

Andy Shevchenko <[email protected]>

    usb: gadget: pch_udc: Check if driver is present before calling ->setup()

Andy Shevchenko <[email protected]>

    usb: gadget: pch_udc: Replace cpu_to_le32() by lower_32_bits()

Erwan Le Ray <[email protected]>
serial: stm32: fix incorrect characters on console

Krzysztof Kozlowski <[email protected]>
ARM: dts: exynos: correct PMIC interrupt trigger level on Snow

Krzysztof Kozlowski <[email protected]>
ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250

Colin Ian King <[email protected]>

    memory: gpmc: fix out of bounds read and dereference on gpmc_cs[]

Andy Shevchenko <[email protected]>
usb: gadget: pch_udc: Revert d3cb25a12138 completely

Takashi Iwai <[email protected]>
ALSA: hda/realtek: Remove redundant entry for ALC861 Haier/Uniwill devices

Takashi Iwai <[email protected]>
ALSA: hda/realtek: Re-order ALC269 Lenovo quirk table entries

Takashi Iwai <[email protected]>
ALSA: hda/realtek: Re-order ALC269 Sony quirk table entries

Takashi Iwai <[email protected]>
ALSA: hda/realtek: Re-order ALC882 Sony quirk table entries

Takashi Iwai <[email protected]>
ALSA: hda/realtek: Re-order ALC882 Acer quirk table entries

Colin Ian King <[email protected]>
drm/radeon: fix copy of uninitialized variable back to userspace

Johannes Berg <[email protected]>
cfg80211: scan: drop entry from hidden_list on overflow

Dan Carpenter <[email protected]>
ipw2x00: potential buffer overflow in libipw_wx_set_encodeext()

Zhao Heming <[email protected]>
md: md_open returns -EBUSY when entering racing area

Christoph Hellwig <[email protected]>
md: factor out a mddev_find_locked helper from mddev_find

Heming Zhao <[email protected]>
md-cluster: fix use-after-free issue when removing rdev

Steven Rostedt (VMware) <[email protected]>
tracing: Restructure trace_clock_global() to never block

Steven Rostedt (VMware) <[email protected]>
tracing: Map all PIDs to command lines

Amey Telawane <[email protected]>
tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

Joel Fernandes <[email protected]>
tracing: Treat recording comm for idle task as a success

Tetsuo Handa <[email protected]>
misc: vmw_vmci: explicitly initialize vmci_datagram payload

Tetsuo Handa <[email protected]>
misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct

Hans de Goede <[email protected]>
misc: lis3lv02d: Fix false-positive WARN on various HP models

Maciej W. Rozycki <[email protected]>
FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR

Or Cohen <[email protected]>
net/nfc: fix use-after-free llcp_sock_bind/connect

Lin Ma <[email protected]>
bluetooth: eliminate the potential race condition when removing the HCI controller

Taehee Yoo <[email protected]>
hsr: use netdev_err() instead of WARN_ONCE()

Archie Pusaka <[email protected]>
Bluetooth: verify AMP hci_chan before amp_destroy

Benjamin Block <[email protected]>
dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails

Joe Thornber <[email protected]>
dm space map common: fix division bug in sm_ll_find_free_block()

Joe Thornber <[email protected]>
dm persistent data: packed struct should have an aligned() attribute too

Dean Anderson <[email protected]>
usb: gadget/function/f_fs string table fix for multiple languages

Hemant Kumar <[email protected]>
usb: gadget: Fix double free of device descriptor pointers

Anirudh Rayabharam <[email protected]>
usb: gadget: dummy_hcd: fix gpf in gadget_setup

Peilin Ye <[email protected]>
media: dvbdev: Fix memory leak in dvb_media_device_free()

Fengnan Chang <[email protected]>
ext4: fix error code in ext4_commit_super

Zhang Yi <[email protected]>
ext4: fix check to prevent false positive report of incorrect used inodes

Steven Rostedt (VMware) <[email protected]>
ftrace: Handle commands when closing set_ftrace_filter file

Thomas Gleixner <[email protected]>
Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op")

Yang Yang <[email protected]>
jffs2: check the validity of dstlen in jffs2_zlib_compress()

Tony Ambardar <[email protected]>
powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

Mahesh Salgaonkar <[email protected]>
powerpc/eeh: Fix EEH handling for hugepages in ioremap space.

lizhe <[email protected]>
jffs2: Fix kasan slab-out-of-bounds problem

Trond Myklebust <[email protected]>
NFSv4: Don't discard segments marked for return in _pnfs_return_layout()

Davide Caratti <[email protected]>
openvswitch: fix stack OOB read while fragmenting IPv4 packets

Bill Wendling <[email protected]>
arm64/vdso: Discard .note.gnu.property sections in vDSO

Lv Yunlong <[email protected]>
ALSA: sb: Fix two use after free in snd_sb_qsound_build

Lv Yunlong <[email protected]>
ALSA: emu8000: Fix a use after free in snd_emu8000_create_mixer

Bart Van Assche <[email protected]>
scsi: libfc: Fix a format specifier

James Smart <[email protected]>
scsi: lpfc: Fix crash when a REG_RPI mailbox fails triggering a LOGO response

Guchun Chen <[email protected]>
drm/amdgpu: fix NULL pointer dereference

Marijn Suijten <[email protected]>
drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal

Hans Verkuil <[email protected]>
media: gscpa/stv06xx: fix memory leak

Pavel Skripkin <[email protected]>
media: dvb-usb: fix memory leak in dvb_usb_adapter_init

Yang Yingliang <[email protected]>
media: i2c: adv7842: fix possible use-after-free in adv7842_remove()

Yang Yingliang <[email protected]>

    media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove()

Yang Yingliang <[email protected]>
media: adv7604: fix possible use-after-free in adv76xx_remove()

Yang Yingliang <[email protected]>
power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove()

Yang Yingliang <[email protected]>
power: supply: generic-adc-battery: fix possible use-after-free in gab_remove()

Colin Ian King <[email protected]>
clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return

Muhammad Usama Anjum <[email protected]>
media: em28xx: fix memory leak

Ewan D. Milne <[email protected]>
scsi: scsi_dh_alua: Remove check for ASC 24h in alua_rtpg()

Bart Van Assche <[email protected]>
scsi: qla2xxx: Always check the return value of qla24xx_get_isp_stats()

dongjian <[email protected]>
power: supply: Use IRQF_ONESHOT

Hans Verkuil <[email protected]>
media: gspca/sq905.c: fix uninitialized variable

Daniel Niv <[email protected]>
media: media/saa7164: fix saa7164_encoder_register() memory leak bugs

Hans de Goede <[email protected]>
extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged

Sean Young <[email protected]>
media: ite-cir: check for receive overflow

Chaitanya Kulkarni <[email protected]>
scsi: target: pscsi: Fix warning in pscsi_complete_cmd()

Josef Bacik <[email protected]>
btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s

Yang Yingliang <[email protected]>
phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove()

Pavel Machek <[email protected]>
intel_th: Consistency and off-by-one fix

Wei Yongjun <[email protected]>
spi: omap-100k: Fix reference leak to master

Wei Yongjun <[email protected]>
spi: dln2: Fix reference leak to master

John Millikin <[email protected]>

    x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)

Rafael J. Wysocki <[email protected]>
PCI: PM: Do not read power state in pci_enable_device_flags()

Thinh Nguyen <[email protected]>
usb: xhci: Fix port minor revision

Wesley Cheng <[email protected]>
usb: dwc3: gadget: Ignore EP queue requests during bus reset

Pawel Laszczak <[email protected]>
usb: gadget: uvc: add bInterval checking for HS mode

karthik alapati <[email protected]>
staging: wimax/i2400m: fix byte-order issue

Phillip Potter <[email protected]>
fbdev: zero-fill colormap in fbcmap.c

Filipe Manana <[email protected]>
btrfs: fix metadata extent leak after failure to create subvolume

Seunghui Lee <[email protected]>
mmc: core: Set read only for SD cards with permanent write protect bit

DooHyun Hwang <[email protected]>
mmc: core: Do a power cycle when the CMD11 fails

Jeffrey Mitchell <[email protected]>
ecryptfs: fix kernel panic with null dev_name

Chunfeng Yun <[email protected]>
arm64: dts: mt8173: fix property typo of 'phys' in dsi node

Mark Langsdorf <[email protected]>
ACPI: custom_method: fix a possible memory leak

Mark Langsdorf <[email protected]>
ACPI: custom_method: fix potential use-after-free issue

Vasily Gorbik <[email protected]>
s390/disassembler: increase ebpf disasm buffer size

Mark Pearson <[email protected]>
platform/x86: thinkpad_acpi: Correct thermal sensor allocation

Chris Chiu <[email protected]>
USB: Add reset-resume quirk for WD19's Realtek Hub

Kai-Heng Feng <[email protected]>
USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet

Takashi Iwai <[email protected]>
ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX

Jiri Kosina <[email protected]>
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()

Phillip Potter <[email protected]>
net: usb: ax88179_178a: initialize local variables before use

-------------

Diffstat:

 Makefile                                           |  4 +-
 arch/arc/kernel/entry.S                            |  4 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts          |  2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi      |  2 +-
 arch/arm/kernel/hw_breakpoint.c                    |  2 +-
 arch/arm/mm/cache-v7.S                             | 51 +++++++++---------
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  2 +-
 arch/arm64/kernel/vdso/vdso.lds.S                  |  8 ++-
 arch/mips/include/asm/div64.h                      | 55 ++++++++++++++------
 arch/mips/pci/pci-legacy.c                         |  9 +++-
 arch/powerpc/Kconfig.debug                         |  1 +
 arch/powerpc/include/uapi/asm/errno.h              |  1 +
 arch/powerpc/kernel/eeh.c                          | 11 ++--
 arch/powerpc/kernel/iommu.c                        |  4 +-
 arch/powerpc/kernel/prom.c                         |  2 +-
 arch/powerpc/lib/feature-fixups.c                  | 17 +++++-
 arch/powerpc/perf/isa207-common.c                  |  4 +-
 arch/powerpc/platforms/52xx/lite5200_sleep.S       |  2 +-
 arch/powerpc/platforms/pseries/hotplug-cpu.c       |  3 --
 arch/powerpc/platforms/pseries/pci_dlpar.c         |  4 +-
 arch/s390/kernel/dis.c                             |  2 +-
 arch/um/kernel/dyn.lds.S                           |  6 +++
 arch/um/kernel/uml.lds.S                           |  6 +++
 arch/x86/Kconfig                                   |  1 +
 arch/x86/Makefile                                  |  1 +
 arch/x86/events/amd/iommu.c                        |  6 +--
 arch/x86/kvm/x86.c                                 |  1 +
 arch/x86/lib/msr-smp.c                             |  4 +-
 drivers/acpi/custom_method.c                       |  4 +-
 drivers/acpi/scan.c                                |  1 +
 drivers/ata/libahci_platform.c                     |  4 +-
 drivers/ata/pata_arasan_cf.c                       | 15 ++++--
 drivers/ata/pata_ixp4xx_cf.c                       |  6 ++-
 drivers/ata/sata_mv.c                              |  4 ++
 drivers/bus/qcom-ebi2.c                            |  4 +-
 drivers/char/ttyprintk.c                           | 11 ++++
 drivers/clk/samsung/clk-exynos7.c                  |  7 ++-
 drivers/clk/socfpga/clk-gate-a10.c                 |  1 +
 drivers/clk/uniphier/clk-uniphier-mux.c            |  4 +-
 drivers/crypto/qat/qat_c3xxxvf/adf_drv.c           |  4 +-
 drivers/crypto/qat/qat_c62xvf/adf_drv.c            |  4 +-
 drivers/crypto/qat/qat_common/adf_isr.c            | 29 ++++++++---
 drivers/crypto/qat/qat_common/adf_transport.c      |  1 +
 drivers/crypto/qat/qat_common/adf_vf_isr.c         | 17 ++++--
 drivers/crypto/qat/qat_dh895xccvf/adf_drv.c        |  4 +-
 drivers/extcon/extcon-arizona.c                    | 17 +++---
 drivers/firmware/Kconfig                           |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c            |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c    | 10 +++-
 drivers/gpu/drm/radeon/radeon_atombios.c           |  6 +--
 drivers/gpu/drm/radeon/radeon_kms.c                |  1 +
 drivers/hid/hid-ids.h                              |  1 +
 drivers/hid/hid-plantronics.c                      | 60 +++++++++++++++++++++-
 drivers/hsi/hsi_core.c                             |  3 +-
 drivers/hv/channel_mgmt.c                          | 30 +++++++++--
 drivers/hwtracing/intel_th/gth.c                   |  4 +-
 drivers/i2c/busses/i2c-cadence.c                   |  5 +-
 drivers/i2c/busses/i2c-emev2.c                     |  5 +-
 drivers/i2c/busses/i2c-jz4780.c                    |  5 +-
 drivers/i2c/busses/i2c-sh7760.c                    |  5 +-
 drivers/iio/proximity/pulsedlight-lidar-lite-v2.c  |  1 +
 drivers/infiniband/hw/i40iw/i40iw_pble.c           |  6 +--
 drivers/input/touchscreen/silead.c                 | 44 ++++++++++++++--
 drivers/isdn/capi/kcapi.c                          |  4 +-
 drivers/md/dm-ioctl.c                              |  2 +-
 drivers/md/dm-rq.c                                 |  2 +
 drivers/md/md.c                                    | 43 +++++++++-------
 drivers/md/persistent-data/dm-btree-internal.h     |  4 +-
 drivers/md/persistent-data/dm-space-map-common.c   |  2 +
 drivers/md/persistent-data/dm-space-map-common.h   |  8 +--
 drivers/media/dvb-core/dvbdev.c                    |  1 +
 drivers/media/i2c/adv7511-v4l2.c                   |  2 +-
 drivers/media/i2c/adv7604.c                        |  2 +-
 drivers/media/i2c/adv7842.c                        |  2 +-
 drivers/media/pci/saa7164/saa7164-encoder.c        | 20 ++++----
 drivers/media/platform/vivid/vivid-vid-out.c       |  2 +-
 drivers/media/rc/ite-cir.c                         |  8 ++-
 drivers/media/tuners/m88rs6000t.c                  |  6 +--
 drivers/media/usb/dvb-usb/dvb-usb-init.c           | 20 ++++++--
 drivers/media/usb/dvb-usb/dvb-usb.h                |  3 +-
 drivers/media/usb/em28xx/em28xx-dvb.c              |  1 +
 drivers/media/usb/gspca/gspca.c                    |  2 +
 drivers/media/usb/gspca/gspca.h                    |  1 +
 drivers/media/usb/gspca/sq905.c                    |  2 +-
 drivers/media/usb/gspca/stv06xx/stv06xx.c          |  9 ++++
 drivers/memory/omap-gpmc.c                         |  7 ++-
 drivers/misc/kgdbts.c                              | 26 +++++-----
 drivers/misc/lis3lv02d/lis3lv02d.c                 | 21 ++++++--
 drivers/misc/vmw_vmci/vmci_doorbell.c              |  2 +-
 drivers/misc/vmw_vmci/vmci_guest.c                 |  2 +-
 drivers/mmc/core/core.c                            |  2 +-
 drivers/mmc/core/sd.c                              |  6 +++
 drivers/mtd/mtdchar.c                              |  8 +--
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c             |  2 +-
 .../net/ethernet/cavium/liquidio/cn23xx_pf_regs.h  |  2 +-
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |  2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c |  2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c        |  2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h        |  1 +
 drivers/net/ethernet/qualcomm/emac/emac-mac.c      |  4 +-
 .../net/ethernet/stmicro/stmmac/dwmac-ipq806x.c    |  2 +
 drivers/net/ethernet/ti/davinci_emac.c             |  4 +-
 drivers/net/fddi/Kconfig                           | 15 +++---
 drivers/net/fddi/defxx.c                           | 47 +++++++++++------
 drivers/net/usb/ax88179_178a.c                     |  4 +-
 drivers/net/wan/lapbether.c                        | 32 +++++++++---
 drivers/net/wimax/i2400m/op-rfkill.c               |  2 +-
 drivers/net/wireless/ath/ath9k/htc_drv_init.c      |  2 +-
 drivers/net/wireless/ath/ath9k/hw.c                |  2 +-
 drivers/net/wireless/intel/ipw2x00/libipw_wx.c     |  6 ++-
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c       |  7 +--
 drivers/net/wireless/marvell/mwl8k.c               |  1 +
 drivers/net/wireless/mediatek/mt7601u/eeprom.c     |  2 +-
 drivers/net/wireless/wl3501.h                      | 47 +++++++++--------
 drivers/net/wireless/wl3501_cs.c                   | 54 ++++++++++---------
 drivers/nfc/pn533/pn533.c                          |  3 ++
 drivers/of/fdt.c                                   | 12 +----
 drivers/pci/hotplug/acpiphp_glue.c                 |  1 +
 drivers/pci/pci.c                                  | 16 ++----
 drivers/pci/probe.c                                |  1 +
 drivers/phy/phy-twl4030-usb.c                      |  2 +-
 drivers/platform/x86/thinkpad_acpi.c               | 31 +++++++----
 drivers/power/supply/generic-adc-battery.c         |  2 +-
 drivers/power/supply/lp8788-charger.c              |  2 +-
 drivers/power/supply/pm2301_charger.c              |  2 +-
 drivers/power/supply/s3c_adc_battery.c             |  2 +-
 drivers/power/supply/tps65090-charger.c            |  2 +-
 drivers/power/supply/tps65217_charger.c            |  2 +-
 drivers/scsi/device_handler/scsi_dh_alua.c         |  5 +-
 drivers/scsi/jazz_esp.c                            |  4 +-
 drivers/scsi/libfc/fc_lport.c                      |  2 +-
 drivers/scsi/lpfc/lpfc_nportdisc.c                 |  2 -
 drivers/scsi/lpfc/lpfc_sli.c                       |  1 -
 drivers/scsi/qla2xxx/qla_attr.c                    |  8 ++-
 drivers/scsi/sni_53c710.c                          |  5 +-
 drivers/scsi/sun3x_esp.c                           |  4 +-
 drivers/spi/spi-dln2.c                             |  2 +-
 drivers/spi/spi-omap-100k.c                        |  6 +--
 drivers/staging/greybus/uart.c                     |  2 -
 drivers/staging/media/omap4iss/iss.c               |  4 +-
 drivers/staging/rtl8192u/r8192U_core.c             |  2 +-
 drivers/target/target_core_pscsi.c                 |  3 +-
 drivers/thermal/fair_share.c                       |  4 ++
 drivers/tty/serial/stm32-usart.c                   | 12 ++++-
 drivers/tty/tty_io.c                               |  8 +--
 drivers/usb/class/cdc-acm.c                        |  2 -
 drivers/usb/core/hub.c                             |  6 +--
 drivers/usb/core/quirks.c                          |  4 ++
 drivers/usb/dwc2/core.h                            |  2 +
 drivers/usb/dwc2/gadget.c                          |  3 +-
 drivers/usb/dwc3/gadget.c                          |  9 ++++
 drivers/usb/gadget/config.c                        |  4 ++
 drivers/usb/gadget/function/f_fs.c                 |  3 +-
 drivers/usb/gadget/function/f_uvc.c                |  7 ++-
 drivers/usb/gadget/udc/dummy_hcd.c                 | 23 ++++++---
 drivers/usb/gadget/udc/fotg210-udc.c               | 26 +++++++---
 drivers/usb/gadget/udc/pch_udc.c                   | 49 ++++++++++++------
 drivers/usb/gadget/udc/r8a66597-udc.c              |  2 +
 drivers/usb/host/fotg210-hcd.c                     |  4 +-
 drivers/usb/host/sl811-hcd.c                       |  9 ++--
 drivers/usb/host/xhci-ext-caps.h                   |  5 +-
 drivers/usb/host/xhci-mem.c                        |  9 ++++
 drivers/usb/host/xhci.c                            |  6 +--
 drivers/video/fbdev/core/fbcmap.c                  |  8 +--
 fs/btrfs/ioctl.c                                   | 18 +++++--
 fs/btrfs/relocation.c                              |  6 +--
 fs/ceph/caps.c                                     |  1 +
 fs/ceph/inode.c                                    |  1 +
 fs/dlm/debug_fs.c                                  |  1 +
 fs/ecryptfs/main.c                                 |  6 +++
 fs/ext4/ialloc.c                                   | 48 +++++++++++------
 fs/ext4/super.c                                    |  6 ++-
 fs/f2fs/inline.c                                   |  3 +-
 fs/fuse/cuse.c                                     |  2 +
 fs/jffs2/compr_rtime.c                             |  3 ++
 fs/jffs2/scan.c                                    |  2 +-
 fs/nfs/flexfilelayout/flexfilelayout.c             |  2 +-
 fs/nfs/inode.c                                     |  8 +--
 fs/nfs/nfs42proc.c                                 | 21 +++++---
 fs/nfs/pnfs.c                                      |  2 +-
 fs/squashfs/file.c                                 |  6 +--
 include/linux/extcon/extcon-adc-jack.h             |  2 +-
 include/linux/hid.h                                |  2 +
 include/linux/tty_driver.h                         |  2 +-
 include/net/bluetooth/hci_core.h                   |  1 +
 include/scsi/libfcoe.h                             |  2 +-
 include/uapi/linux/tty_flags.h                     |  4 +-
 kernel/futex.c                                     |  3 +-
 kernel/kexec_file.c                                |  4 +-
 kernel/trace/ftrace.c                              |  5 +-
 kernel/trace/trace.c                               | 45 +++++++---------
 kernel/trace/trace_clock.c                         | 44 +++++++++++-----
 lib/kobject_uevent.c                               |  9 ++--
 lib/stackdepot.c                                   |  6 +--
 mm/hugetlb.c                                       | 11 +++-
 mm/khugepaged.c                                    | 18 +++----
 mm/ksm.c                                           |  1 +
 net/bluetooth/hci_event.c                          |  3 +-
 net/bluetooth/hci_request.c                        | 12 +++--
 net/bluetooth/l2cap_core.c                         |  4 ++
 net/hsr/hsr_framereg.c                             |  3 +-
 net/ipv6/ip6_gre.c                                 |  3 --
 net/ipv6/ip6_tunnel.c                              |  3 +-
 net/ipv6/ip6_vti.c                                 |  3 +-
 net/ipv6/sit.c                                     |  5 +-
 net/mac80211/main.c                                |  7 ++-
 net/mac80211/mlme.c                                |  5 ++
 net/netfilter/nf_conntrack_standalone.c            |  5 +-
 net/nfc/digital_dep.c                              |  2 +
 net/nfc/llcp_sock.c                                |  4 ++
 net/openvswitch/actions.c                          |  8 +--
 net/sctp/sm_make_chunk.c                           |  2 +-
 net/sctp/sm_statefuns.c                            |  3 +-
 net/sctp/socket.c                                  | 38 ++++++++------
 net/tipc/netlink_compat.c                          |  2 +-
 net/vmw_vsock/vmci_transport.c                     |  3 +-
 net/wireless/scan.c                                |  2 +
 samples/bpf/tracex1_kern.c                         |  4 +-
 samples/kfifo/bytestream-example.c                 |  8 ++-
 samples/kfifo/inttype-example.c                    |  8 ++-
 samples/kfifo/record-example.c                     |  8 ++-
 scripts/kconfig/nconf.c                            |  2 +-
 sound/core/init.c                                  |  2 -
 sound/isa/sb/emu8000.c                             |  4 +-
 sound/isa/sb/sb16_csp.c                            |  8 ++-
 sound/pci/hda/hda_generic.c                        | 16 ++++--
 sound/pci/hda/patch_realtek.c                      | 21 ++++----
 sound/pci/rme9652/hdsp.c                           |  3 +-
 sound/pci/rme9652/hdspm.c                          |  3 +-
 sound/pci/rme9652/rme9652.c                        |  3 +-
 sound/soc/codecs/rt286.c                           | 23 +++++----
 sound/usb/card.c                                   | 14 ++---
 sound/usb/quirks-table.h                           | 10 ++++
 sound/usb/quirks.c                                 | 16 ++++--
 sound/usb/usbaudio.h                               |  2 +
 tools/perf/util/symbol_fprintf.c                   |  2 +-
 tools/testing/selftests/lib.mk                     |  4 ++
 237 files changed, 1262 insertions(+), 647 deletions(-)

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #9 lore raw

PATCH 9/240 ACPI: custom_method: fix a possible memory leak

From: Mark Langsdorf <[email protected]>

commit 1cfd8956437f842836e8a066b40d1ec2fc01f13e upstream.

In cm_write(), if the 'buf' is allocated memory but not fully consumed, it is possible to reallocate the buffer without freeing it by passing '*ppos' as 0 on a subsequent call.

Add an explicit kfree() before kzalloc() to prevent the possible memory leak.

Fixes 526b4af47f44 ("ACPI: Split out custom_method functionality into an own driver")

Signed-off-by Mark Langsdorf <[email protected]>

Cc 5.4+ <[email protected]> # 5.4+

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/acpi/custom_method.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/acpi/custom_method.c +2 -0

@@ -37,6 +37,8 @@ static ssize_t cm_write(struct file *fil
 				   sizeof(struct acpi_table_header)))
 			return -EFAULT;
 		uncopied_bytes = max_size = table.length;
+		/* make sure the buf is not allocated */
+		kfree(buf);
 		buf = kzalloc(max_size, GFP_KERNEL);
 		if (!buf)
 			return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #34 lore raw

PATCH 34/240 scsi: scsi_dh_alua: Remove check for ASC 24h in alua_rtpg()

In reply to Greg Kroah-Hartman

From: Ewan D. Milne <[email protected]>

[ Upstream commit bc3f2b42b70eb1b8576e753e7d0e117bbb674496 ]

Some arrays return ILLEGAL_REQUEST with ASC 00h if they don't support the RTPG extended header so remove the check for INVALID FIELD IN CDB.

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Hannes Reinecke <[email protected]>

Signed-off-by Ewan D. Milne <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/device_handler/scsi_dh_alua.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/scsi/device_handler/scsi_dh_alua.c +3 -2

index 2bc3dc6244a5..dce885276235 100644
@@ -564,10 +564,11 @@ static int alua_rtpg(struct scsi_device *sdev, struct alua_port_group *pg)
 		 * even though it shouldn't according to T10.
 		 * The retry without rtpg_ext_hdr_req set
 		 * handles this.
+		 * Note:  some arrays return a sense key of ILLEGAL_REQUEST
+		 * with ASC 00h if they don't support the extended header.
 		 */
 		if (!(pg->flags & ALUA_RTPG_EXT_HDR_UNSUPP) &&
-		    sense_hdr.sense_key == ILLEGAL_REQUEST &&
-		    sense_hdr.asc == 0x24 && sense_hdr.ascq == 0) {
+		    sense_hdr.sense_key == ILLEGAL_REQUEST) {
 			pg->flags |= ALUA_RTPG_EXT_HDR_UNSUPP;
 			goto retry;
 		}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #43 lore raw

PATCH 43/240 media: gscpa/stv06xx: fix memory leak

In reply to Greg Kroah-Hartman

From: Hans Verkuil <[email protected]>

[ Upstream commit 4f4e6644cd876c844cdb3bea2dd7051787d5ae25 ]

For two of the supported sensors the stv06xx driver allocates memory which is stored in sd->sensor_priv. This memory is freed on a disconnect, but if the probe() fails, then it isn't freed and so this leaks memory.

Add a new probe_error() op that drivers can use to free any allocated memory in case there was a probe failure.

Thanks to Pavel Skripkin <[email protected]> for discovering the cause of the memory leak.

Reported-and-tested-by [email protected]

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/gspca/gspca.c           | 2 ++
 drivers/media/usb/gspca/gspca.h           | 1 +
 drivers/media/usb/gspca/stv06xx/stv06xx.c | 9 +++++++++
 3 files changed, 12 insertions(+)

drivers/media/usb/gspca/gspca.c +2 -0

index d239075a6a65..79f1e8904e30 100644
@@ -2146,6 +2146,8 @@ out:
 #endif
 	v4l2_ctrl_handler_free(gspca_dev->vdev.ctrl_handler);
 	v4l2_device_unregister(&gspca_dev->v4l2_dev);
+	if (sd_desc->probe_error)
+		sd_desc->probe_error(gspca_dev);
 	kfree(gspca_dev->usb_buf);
 	kfree(gspca_dev);
 	return ret;

drivers/media/usb/gspca/gspca.h +1 -0

index d39adf90303b..bec8fccc2c94 100644
@@ -101,6 +101,7 @@ struct sd_desc {
 	cam_cf_op config;	/* called on probe */
 	cam_op init;		/* called on probe and resume */
 	cam_op init_controls;	/* called on probe */
+	cam_v_op probe_error;	/* called if probe failed, do cleanup here */
 	cam_op start;		/* called on stream on after URBs creation */
 	cam_pkt_op pkt_scan;
 /* optional operations */

drivers/media/usb/gspca/stv06xx/stv06xx.c +9 -0

index 7d255529ed4c..40d4c99debb8 100644
@@ -541,12 +541,21 @@ static int sd_int_pkt_scan(struct gspca_dev *gspca_dev,
 static int stv06xx_config(struct gspca_dev *gspca_dev,
 			  const struct usb_device_id *id);
 
+static void stv06xx_probe_error(struct gspca_dev *gspca_dev)
+{
+	struct sd *sd = (struct sd *)gspca_dev;
+
+	kfree(sd->sensor_priv);
+	sd->sensor_priv = NULL;
+}
+
 /* sub-driver description */
 static const struct sd_desc sd_desc = {
 	.name = MODULE_NAME,
 	.config = stv06xx_config,
 	.init = stv06xx_init,
 	.init_controls = stv06xx_init_controls,
+	.probe_error = stv06xx_probe_error,
 	.start = stv06xx_start,
 	.stopN = stv06xx_stopN,
 	.pkt_scan = stv06xx_pkt_scan,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #44 lore raw

PATCH 44/240 drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal

In reply to Greg Kroah-Hartman

From: Marijn Suijten <[email protected]>

[ Upstream commit 2ad52bdb220de5ab348098e3482b01235d15a842 ]

Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up.

In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq.

Signed-off-by Marijn Suijten <[email protected]>

Reviewed-by AngeloGioacchino Del Regno <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Rob Clark <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c +9 -1

index c627ab6d0061..8ac54b9dcd39 100644
@@ -128,9 +128,17 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder,
 		| MDP5_PP_SYNC_CONFIG_VSYNC_IN_EN;
 	cfg |= MDP5_PP_SYNC_CONFIG_VSYNC_COUNT(vclks_line);
 
+	/*
+	 * Tearcheck emits a blanking signal every vclks_line * vtotal * 2 ticks on
+	 * the vsync_clk equating to roughly half the desired panel refresh rate.
+	 * This is only necessary as stability fallback if interrupts from the
+	 * panel arrive too late or not at all, but is currently used by default
+	 * because these panel interrupts are not wired up yet.
+	 */
 	mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg);
 	mdp5_write(mdp5_kms,
-		REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0);
+		REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal));
+
 	mdp5_write(mdp5_kms,
 		REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay);
 	mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #45 lore raw

PATCH 45/240 drm/amdgpu: fix NULL pointer dereference

In reply to Greg Kroah-Hartman

From: Guchun Chen <[email protected]>

[ Upstream commit 3c3dc654333f6389803cdcaf03912e94173ae510 ]

ttm->sg needs to be checked before accessing its child member.

Call Trace:
 amdgpu_ttm_backend_destroy+0x12/0x70 [amdgpu]
 ttm_bo_cleanup_memtype_use+0x3a/0x60 [ttm]
 ttm_bo_release+0x17d/0x300 [ttm]
 amdgpu_bo_unref+0x1a/0x30 [amdgpu]
 amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x78b/0x8b0 [amdgpu]
 kfd_ioctl_alloc_memory_of_gpu+0x118/0x220 [amdgpu]
 kfd_ioctl+0x222/0x400 [amdgpu]
 ? kfd_dev_is_large_bar+0x90/0x90 [amdgpu]
 __x64_sys_ioctl+0x8e/0xd0
 ? __context_tracking_exit+0x52/0x90
 do_syscall_64+0x33/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f97f264d317
Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
RSP: 002b:00007ffdb402c338 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f97f3cc63a0 RCX: 00007f97f264d317
RDX: 00007ffdb402c380 RSI: 00000000c0284b16 RDI: 0000000000000003
RBP: 00007ffdb402c380 R08: 00007ffdb402c428 R09: 00000000c4000004
R10: 00000000c4000004 R11: 0000000000000246 R12: 00000000c0284b16
R13: 0000000000000003 R14: 00007f97f3cc63a0 R15: 00007f8836200000

Signed-off-by Guchun Chen <[email protected]>

Acked-by Christian König <[email protected]>

Signed-off-by Alex Deucher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +1 -1

index 80c60a62d39e..7271e3f32d82 100644
@@ -652,7 +652,7 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
 		DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
 
 	/* double check that we don't free the table twice */
-	if (!ttm->sg->sgl)
+	if (!ttm->sg || !ttm->sg->sgl)
 		return;
 
 	/* free the sg table and pages again */

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #46 lore raw

PATCH 46/240 scsi: lpfc: Fix crash when a REG_RPI mailbox fails triggering a LOGO response

In reply to Greg Kroah-Hartman

From: James Smart <[email protected]>

[ Upstream commit fffd18ec6579c2d9c72b212169259062fe747888 ]

Fix a crash caused by a double put on the node when the driver completed an ACC for an unsolicted abort on the same node. The second put was executed by lpfc_nlp_not_used() and is wrong because the completion routine executes the nlp_put when the iocbq was released. Additionally, the driver is issuing a LOGO then immediately calls lpfc_nlp_set_state to put the node into NPR. This call does nothing.

Remove the lpfc_nlp_not_used call and additional set_state in the completion routine. Remove the lpfc_nlp_set_state post issue_logo. Isn't necessary.

Link https://lore.kernel.org/r/[email protected] open here

Co-developed-by Justin Tee <[email protected]>

Signed-off-by Justin Tee <[email protected]>

Signed-off-by James Smart <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/lpfc/lpfc_nportdisc.c | 2 --
 drivers/scsi/lpfc/lpfc_sli.c       | 1 -
 2 files changed, 3 deletions(-)

drivers/scsi/lpfc/lpfc_nportdisc.c +0 -2

index fefef2884d59..30b5f65b29d1 100644
@@ -1606,8 +1606,6 @@ lpfc_cmpl_reglogin_reglogin_issue(struct lpfc_vport *vport,
 		ndlp->nlp_last_elscmd = ELS_CMD_PLOGI;
 
 		lpfc_issue_els_logo(vport, ndlp, 0);
-		ndlp->nlp_prev_state = NLP_STE_REG_LOGIN_ISSUE;
-		lpfc_nlp_set_state(vport, ndlp, NLP_STE_NPR_NODE);
 		return ndlp->nlp_state;
 	}

drivers/scsi/lpfc/lpfc_sli.c +0 -1

index 08c76c361e8d..0e7915ecb85a 100644
@@ -15252,7 +15252,6 @@ lpfc_sli4_seq_abort_rsp_cmpl(struct lpfc_hba *phba,
 	if (cmd_iocbq) {
 		ndlp = (struct lpfc_nodelist *)cmd_iocbq->context1;
 		lpfc_nlp_put(ndlp);
-		lpfc_nlp_not_used(ndlp);
 		lpfc_sli_release_iocbq(phba, cmd_iocbq);
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #47 lore raw

PATCH 47/240 scsi: libfc: Fix a format specifier

In reply to Greg Kroah-Hartman

From: Bart Van Assche <[email protected]>

[ Upstream commit 90d6697810f06aceea9de71ad836a8c7669789cd ]

Since the 'mfs' member has been declared as 'u32' in include/scsi/libfc.h, use the %u format specifier instead of %hu. This patch fixes the following clang compiler warning:

warning: format specifies type

      'unsigned short' but the argument has type 'u32' (aka 'unsigned int')
      [-Wformat]
                             "lport->mfs:%hu\n", mfs, lport->mfs);
                                         ~~~          ^~~~~~~~~~
                                         %u

Link https://lore.kernel.org/r/[email protected] open here

Cc Hannes Reinecke <[email protected]>

Signed-off-by Bart Van Assche <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/libfc/fc_lport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/libfc/fc_lport.c +1 -1

index ae93f45f9cd8..a36817fb0673 100644
@@ -1751,7 +1751,7 @@ void fc_lport_flogi_resp(struct fc_seq *sp, struct fc_frame *fp,
 
 	if (mfs < FC_SP_MIN_MAX_PAYLOAD || mfs > FC_SP_MAX_MAX_PAYLOAD) {
 		FC_LPORT_DBG(lport, "FLOGI bad mfs:%hu response, "
-			     "lport->mfs:%hu\n", mfs, lport->mfs);
+			     "lport->mfs:%u\n", mfs, lport->mfs);
 		fc_lport_error(lport, fp);
 		goto out;
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #48 lore raw

PATCH 48/240 ALSA: emu8000: Fix a use after free in snd_emu8000_create_mixer

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

commit 1c98f574403dbcf2eb832d5535a10d967333ef2d upstream.

Our code analyzer reported a uaf.

In snd_emu8000_create_mixer, the callee snd_ctl_add(..,emu->controls[i]) calls snd_ctl_add_replace(.., kcontrol,..). Inside snd_ctl_add_replace(), if error happens, kcontrol will be freed by snd_ctl_free_one(kcontrol). Then emu->controls[i] points to a freed memory, and the execution comes to __error branch of snd_emu8000_create_mixer. The freed emu->controls[i] is used in snd_ctl_remove(card, emu->controls[i]).

My patch set emu->controls[i] to NULL if snd_ctl_add() failed to avoid the uaf.

Signed-off-by Lv Yunlong <[email protected]>

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/isa/sb/emu8000.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

sound/isa/sb/emu8000.c +3 -1

@@ -1042,8 +1042,10 @@ snd_emu8000_create_mixer(struct snd_card
 
 	memset(emu->controls, 0, sizeof(emu->controls));
 	for (i = 0; i < EMU8000_NUM_CONTROLS; i++) {
-		if ((err = snd_ctl_add(card, emu->controls[i] = snd_ctl_new1(mixer_defs[i], emu))) < 0)
+		if ((err = snd_ctl_add(card, emu->controls[i] = snd_ctl_new1(mixer_defs[i], emu))) < 0) {
+			emu->controls[i] = NULL;
 			goto __error;
+		}
 	}
 	return 0;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #49 lore raw

PATCH 49/240 ALSA: sb: Fix two use after free in snd_sb_qsound_build

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

commit 4fb44dd2c1dda18606348acdfdb97e8759dde9df upstream.

In snd_sb_qsound_build, snd_ctl_add(..,p->qsound_switch...) and snd_ctl_add(..,p->qsound_space..) are called. But the second arguments of snd_ctl_add() could be freed via snd_ctl_add_replace() ->snd_ctl_free_one(). After the error code is returned, snd_sb_qsound_destroy(p) is called in __error branch.

But in snd_sb_qsound_destroy(), the freed p->qsound_switch and p->qsound_space are still used by snd_ctl_remove().

My patch set p->qsound_switch and p->qsound_space to NULL if snd_ctl_add() failed to avoid the uaf bugs. But these codes need to further be improved with the code style.

Signed-off-by Lv Yunlong <[email protected]>

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/isa/sb/sb16_csp.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

sound/isa/sb/sb16_csp.c +6 -2

@@ -1059,10 +1059,14 @@ static int snd_sb_qsound_build(struct sn
 
 	spin_lock_init(&p->q_lock);
 
-	if ((err = snd_ctl_add(card, p->qsound_switch = snd_ctl_new1(&snd_sb_qsound_switch, p))) < 0)
+	if ((err = snd_ctl_add(card, p->qsound_switch = snd_ctl_new1(&snd_sb_qsound_switch, p))) < 0) {
+		p->qsound_switch = NULL;
 		goto __error;
-	if ((err = snd_ctl_add(card, p->qsound_space = snd_ctl_new1(&snd_sb_qsound_space, p))) < 0)
+	}
+	if ((err = snd_ctl_add(card, p->qsound_space = snd_ctl_new1(&snd_sb_qsound_space, p))) < 0) {
+		p->qsound_space = NULL;
 		goto __error;
+	}
 
 	return 0;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #51 lore raw

PATCH 51/240 openvswitch: fix stack OOB read while fragmenting IPv4 packets

In reply to Greg Kroah-Hartman

From: Davide Caratti <[email protected]>

commit 7c0ea5930c1c211931819d83cfb157bff1539a4c upstream.

running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets:

 BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
 Read of size 1 at addr ffff888112fc713c by task handler2/1367

 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  ip_do_fragment+0x1b03/0x1f60
  ovs_fragment+0x5bf/0x840 [openvswitch]
  do_execute_actions+0x1bd5/0x2400 [openvswitch]
  ovs_execute_actions+0xc8/0x3d0 [openvswitch]
  ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]
  genl_family_rcv_msg_doit.isra.15+0x227/0x2d0
  genl_rcv_msg+0x287/0x490
  netlink_rcv_skb+0x120/0x380
  genl_rcv+0x24/0x40
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f957079db07
 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48
 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
 RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07
 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019
 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730
 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0

 The buggy address belongs to the page:
 page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7
 flags: 0x17ffffc0000000()
 raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000
 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:
ovs_fragment+0x0/0x840 [openvswitch]

this frame has 2 objects:
[32, 144) 'ovs_dst'
[192, 424) 'ovs_rt'

 Memory state around the buggy address:
  ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00
 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
                                         ^
  ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00

for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph:

ip_do_fragment()

    ip_skb_dst_mtu()
      ip_dst_mtu_maybe_forward()
        ip_mtu_locked()

the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below.

Fixes d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmt")

Cc <[email protected]>

Acked-by Eelco Chaudron <[email protected]>

Signed-off-by Davide Caratti <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/openvswitch/actions.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

net/openvswitch/actions.c +4 -4

@@ -710,16 +710,16 @@ static void ovs_fragment(struct net *net
 	}
 
 	if (ethertype == htons(ETH_P_IP)) {
-		struct dst_entry ovs_dst;
+		struct rtable ovs_rt = { 0 };
 		unsigned long orig_dst;
 
 		prepare_frag(vport, skb);
-		dst_init(&ovs_dst, &ovs_dst_ops, NULL, 1,
+		dst_init(&ovs_rt.dst, &ovs_dst_ops, NULL, 1,
 			 DST_OBSOLETE_NONE, DST_NOCOUNT);
-		ovs_dst.dev = vport->dev;
+		ovs_rt.dst.dev = vport->dev;
 
 		orig_dst = skb->_skb_refdst;
-		skb_dst_set_noref(skb, &ovs_dst);
+		skb_dst_set_noref(skb, &ovs_rt.dst);
 		IPCB(skb)->frag_max_size = mru;
 
 		ip_do_fragment(net, skb->sk, skb, ovs_vport_output);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #50 lore raw

PATCH 50/240 arm64/vdso: Discard .note.gnu.property sections in vDSO

In reply to Greg Kroah-Hartman

From: Bill Wendling <[email protected]>

[ Upstream commit 388708028e6937f3fc5fc19aeeb847f8970f489c ]

The arm64 assembler in binutils 2.32 and above generates a program property note in a note section, .note.gnu.property, to encode used x86 ISAs and features. But the kernel linker script only contains a single NOTE segment:

  PHDRS
  {
    text    PT_LOAD    FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */
    dynamic PT_DYNAMIC FLAGS(4);               /* PF_R */
    note    PT_NOTE    FLAGS(4);               /* PF_R */
  }

The NOTE segment generated by the vDSO linker script is aligned to 4 bytes. But the .note.gnu.property section must be aligned to 8 bytes on arm64.

  $ readelf -n vdso64.so

Displaying notes found in: .note

    Owner                Data size      Description
    Linux                0x00000004     Unknown note type: (0x00000000)
     description data: 06 00 00 00

readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20
readelf: Warning: type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8

Since the note.gnu.property section in the vDSO is not checked by the dynamic linker, discard the .note.gnu.property sections in the vDSO.

Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property sections in vDSO"), but for arm64.

Signed-off-by Bill Wendling <[email protected]>

Reviewed-by Kees Cook <[email protected]>

Acked-by Ard Biesheuvel <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Catalin Marinas <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/kernel/vdso/vdso.lds.S | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

arch/arm64/kernel/vdso/vdso.lds.S +7 -1

index beca249bc2f3..b3e6c4d5b75c 100644
@@ -39,6 +39,13 @@ SECTIONS
 	.gnu.version_d	: { *(.gnu.version_d) }
 	.gnu.version_r	: { *(.gnu.version_r) }
 
+	/*
+	 * Discard .note.gnu.property sections which are unused and have
+	 * different alignment requirement from vDSO note sections.
+	 */
+	/DISCARD/	: {
+		*(.note.GNU-stack .note.gnu.property)
+	}
 	.note		: { *(.note.*) }		:text	:note
 
 	. = ALIGN(16);

@@ -59,7 +66,6 @@ SECTIONS
 	PROVIDE(end = .);
 
 	/DISCARD/	: {
-		*(.note.GNU-stack)
 		*(.data .data.* .gnu.linkonce.d.* .sdata*)
 		*(.bss .sbss .dynbss .dynsbss)
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #52 lore raw

PATCH 52/240 NFSv4: Dont discard segments marked for return in _pnfs_return_layout()

In reply to Greg Kroah-Hartman

From: Trond Myklebust <[email protected]>

commit de144ff4234f935bd2150108019b5d87a90a8a96 upstream.

If the pNFS layout segment is marked with the NFS_LSEG_LAYOUTRETURN flag, then the assumption is that it has some reporting requirement to perform through a layoutreturn (e.g. flexfiles layout stats or error information).

Fixes 6d597e175012 ("pnfs: only tear down lsegs that precede seqid in LAYOUTRETURN args")

Cc [email protected]

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/pnfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/nfs/pnfs.c +1 -1

@@ -1088,7 +1088,7 @@ _pnfs_return_layout(struct inode *ino)
 	pnfs_get_layout_hdr(lo);
 	empty = list_empty(&lo->plh_segs);
 	pnfs_clear_layoutcommit(ino, &tmp_list);
-	pnfs_mark_matching_lsegs_invalid(lo, &tmp_list, NULL, 0);
+	pnfs_mark_matching_lsegs_return(lo, &tmp_list, NULL, 0);
 
 	if (NFS_SERVER(ino)->pnfs_curr_ld->return_range) {
 		struct pnfs_layout_range range = {

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #35 lore raw

PATCH 35/240 media: em28xx: fix memory leak

In reply to Greg Kroah-Hartman

From: Muhammad Usama Anjum <[email protected]>

[ Upstream commit 0ae10a7dc8992ee682ff0b1752ff7c83d472eef1 ]

If some error occurs, URB buffers should also be freed. If they aren't freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB buffers as dvb is set to NULL. The function in which error occurs should do all the cleanup for the allocations it had done.

Tested the patch with the reproducer provided by syzbot. This patch fixes the memleak.

Reported-by [email protected]

Signed-off-by Muhammad Usama Anjum <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
 1 file changed, 1 insertion(+)

drivers/media/usb/em28xx/em28xx-dvb.c +1 -0

index b0aea48907b7..7e259be47252 100644
@@ -1967,6 +1967,7 @@ ret:
 	return result;
 
 out_free:
+	em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);
 	kfree(dvb);
 	dev->dvb = NULL;
 	goto ret;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #53 lore raw

PATCH 53/240 jffs2: Fix kasan slab-out-of-bounds problem

In reply to Greg Kroah-Hartman

From: lizhe <[email protected]>

commit 960b9a8a7676b9054d8b46a2c7db52a0c8766b56 upstream.

KASAN report a slab-out-of-bounds problem. The logs are listed below. It is because in function jffs2_scan_dirent_node, we alloc "checkedlen+1" bytes for fd->name and we check crc with length rd->nsize. If checkedlen is less than rd->nsize, it will cause the slab-out-of-bounds problem.

jffs2: Dirent at *** has zeroes in name. Truncating to %d char
==================================================================

BUG: KASAN: slab-out-of-bounds in crc32_le+0x1ce/0x260 at addr ffff8800842cf2d1
Read of size 1 by task test_JFFS2/915
=============================================================================
BUG kmalloc-64 (Tainted: G    B      O   ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in jffs2_alloc_full_dirent+0x2a/0x40 age=0 cpu=1 pid=915
	___slab_alloc+0x580/0x5f0
	__slab_alloc.isra.24+0x4e/0x64
	__kmalloc+0x170/0x300
	jffs2_alloc_full_dirent+0x2a/0x40
	jffs2_scan_eraseblock+0x1ca4/0x3b64
	jffs2_scan_medium+0x285/0xfe0
	jffs2_do_mount_fs+0x5fb/0x1bbc
	jffs2_do_fill_super+0x245/0x6f0
	jffs2_fill_super+0x287/0x2e0
	mount_mtd_aux.isra.0+0x9a/0x144
	mount_mtd+0x222/0x2f0
	jffs2_mount+0x41/0x60
	mount_fs+0x63/0x230
	vfs_kern_mount.part.6+0x6c/0x1f4
	do_mount+0xae8/0x1940
	SyS_mount+0x105/0x1d0
INFO: Freed in jffs2_free_full_dirent+0x22/0x40 age=27 cpu=1 pid=915
	__slab_free+0x372/0x4e4
	kfree+0x1d4/0x20c
	jffs2_free_full_dirent+0x22/0x40
	jffs2_build_remove_unlinked_inode+0x17a/0x1e4
	jffs2_do_mount_fs+0x1646/0x1bbc
	jffs2_do_fill_super+0x245/0x6f0
	jffs2_fill_super+0x287/0x2e0
	mount_mtd_aux.isra.0+0x9a/0x144
	mount_mtd+0x222/0x2f0
	jffs2_mount+0x41/0x60
	mount_fs+0x63/0x230
	vfs_kern_mount.part.6+0x6c/0x1f4
	do_mount+0xae8/0x1940
	SyS_mount+0x105/0x1d0
	entry_SYSCALL_64_fastpath+0x1e/0x97
Call Trace:
 [<ffffffff815befef>] dump_stack+0x59/0x7e
 [<ffffffff812d1d65>] print_trailer+0x125/0x1b0
 [<ffffffff812d82c8>] object_err+0x34/0x40
 [<ffffffff812dadef>] kasan_report.part.1+0x21f/0x534
 [<ffffffff81132401>] ? vprintk+0x2d/0x40
 [<ffffffff815f1ee2>] ? crc32_le+0x1ce/0x260
 [<ffffffff812db41a>] kasan_report+0x26/0x30
 [<ffffffff812d9fc1>] __asan_load1+0x3d/0x50
 [<ffffffff815f1ee2>] crc32_le+0x1ce/0x260
 [<ffffffff814764ae>] ? jffs2_alloc_full_dirent+0x2a/0x40
 [<ffffffff81485cec>] jffs2_scan_eraseblock+0x1d0c/0x3b64
 [<ffffffff81488813>] ? jffs2_scan_medium+0xccf/0xfe0
 [<ffffffff81483fe0>] ? jffs2_scan_make_ino_cache+0x14c/0x14c
 [<ffffffff812da3e9>] ? kasan_unpoison_shadow+0x35/0x50
 [<ffffffff812da3e9>] ? kasan_unpoison_shadow+0x35/0x50
 [<ffffffff812da462>] ? kasan_kmalloc+0x5e/0x70
 [<ffffffff812d5d90>] ? kmem_cache_alloc_trace+0x10c/0x2cc
 [<ffffffff818169fb>] ? mtd_point+0xf7/0x130
 [<ffffffff81487dc9>] jffs2_scan_medium+0x285/0xfe0
 [<ffffffff81487b44>] ? jffs2_scan_eraseblock+0x3b64/0x3b64
 [<ffffffff812da3e9>] ? kasan_unpoison_shadow+0x35/0x50
 [<ffffffff812da3e9>] ? kasan_unpoison_shadow+0x35/0x50
 [<ffffffff812da462>] ? kasan_kmalloc+0x5e/0x70
 [<ffffffff812d57df>] ? __kmalloc+0x12b/0x300
 [<ffffffff812da462>] ? kasan_kmalloc+0x5e/0x70
 [<ffffffff814a2753>] ? jffs2_sum_init+0x9f/0x240
 [<ffffffff8148b2ff>] jffs2_do_mount_fs+0x5fb/0x1bbc
 [<ffffffff8148ad04>] ? jffs2_del_noinode_dirent+0x640/0x640
 [<ffffffff812da462>] ? kasan_kmalloc+0x5e/0x70
 [<ffffffff81127c5b>] ? __init_rwsem+0x97/0xac
 [<ffffffff81492349>] jffs2_do_fill_super+0x245/0x6f0
 [<ffffffff81493c5b>] jffs2_fill_super+0x287/0x2e0
 [<ffffffff814939d4>] ? jffs2_parse_options+0x594/0x594
 [<ffffffff81819bea>] mount_mtd_aux.isra.0+0x9a/0x144
 [<ffffffff81819eb6>] mount_mtd+0x222/0x2f0
 [<ffffffff814939d4>] ? jffs2_parse_options+0x594/0x594
 [<ffffffff81819c94>] ? mount_mtd_aux.isra.0+0x144/0x144
 [<ffffffff81258757>] ? free_pages+0x13/0x1c
 [<ffffffff814fa0ac>] ? selinux_sb_copy_data+0x278/0x2e0
 [<ffffffff81492b35>] jffs2_mount+0x41/0x60
 [<ffffffff81302fb7>] mount_fs+0x63/0x230
 [<ffffffff8133755f>] ? alloc_vfsmnt+0x32f/0x3b0
 [<ffffffff81337f2c>] vfs_kern_mount.part.6+0x6c/0x1f4
 [<ffffffff8133ceec>] do_mount+0xae8/0x1940
 [<ffffffff811b94e0>] ? audit_filter_rules.constprop.6+0x1d10/0x1d10
 [<ffffffff8133c404>] ? copy_mount_string+0x40/0x40
 [<ffffffff812cbf78>] ? alloc_pages_current+0xa4/0x1bc
 [<ffffffff81253a89>] ? __get_free_pages+0x25/0x50
 [<ffffffff81338993>] ? copy_mount_options.part.17+0x183/0x264
 [<ffffffff8133e3a9>] SyS_mount+0x105/0x1d0
 [<ffffffff8133e2a4>] ? copy_mnt_ns+0x560/0x560
 [<ffffffff810e8391>] ? msa_space_switch_handler+0x13d/0x190
 [<ffffffff81be184a>] entry_SYSCALL_64_fastpath+0x1e/0x97
 [<ffffffff810e9274>] ? msa_space_switch+0xb0/0xe0
Memory state around the buggy address:
 ffff8800842cf180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8800842cf200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8800842cf280: fc fc fc fc fc fc 00 00 00 00 01 fc fc fc fc fc
                                                 ^
 ffff8800842cf300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8800842cf380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

Cc [email protected]

Reported-by Kunkun Xu <[email protected]>

Signed-off-by lizhe <[email protected]>

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/jffs2/scan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/jffs2/scan.c +1 -1

@@ -1075,7 +1075,7 @@ static int jffs2_scan_dirent_node(struct
 	memcpy(&fd->name, rd->name, checkedlen);
 	fd->name[checkedlen] = 0;
 
-	crc = crc32(0, fd->name, rd->nsize);
+	crc = crc32(0, fd->name, checkedlen);
 	if (crc != je32_to_cpu(rd->name_crc)) {
 		pr_notice("%s(): Name CRC failed on node at 0x%08x: Read 0x%08x, calculated 0x%08x\n",
 			  __func__, ofs, je32_to_cpu(rd->name_crc), crc);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #54 lore raw

PATCH 54/240 powerpc/eeh: Fix EEH handling for hugepages in ioremap space.

In reply to Greg Kroah-Hartman

From: Mahesh Salgaonkar <[email protected]>

commit 5ae5bc12d0728db60a0aa9b62160ffc038875f1a upstream.

During the EEH MMIO error checking, the current implementation fails to map the (virtual) MMIO address back to the pci device on radix with hugepage mappings for I/O. This results into failure to dispatch EEH event with no recovery even when EEH capability has been enabled on the device.

eeh_check_failure(token) # token = virtual MMIO address
addr = eeh_token_to_phys(token);
edev = eeh_addr_cache_get_dev(addr);
if (!edev)

	return 0;

eeh_dev_check_failure(edev); <= Dispatch the EEH event

In case of hugepage mappings, eeh_token_to_phys() has a bug in virt -> phys translation that results in wrong physical address, which is then passed to eeh_addr_cache_get_dev() to match it against cached pci I/O address ranges to get to a PCI device. Hence, it fails to find a match and the EEH event never gets dispatched leaving the device in failed state.

The commit 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space") introduced following logic to translate virt to phys for hugepage mappings:

eeh_token_to_phys():
+ pa = pte_pfn(*ptep);
+
+ /* On radix we can do hugepage mappings for io, so handle that */
+ if (hugepage_shift) {
+ pa <<= hugepage_shift; <= This is wrong
+ pa |= token & ((1ul << hugepage_shift) - 1);
+ }

This patch fixes the virt -> phys translation in eeh_token_to_phys() function.

  $ cat /sys/kernel/debug/powerpc/eeh_address_cache
  mem addr range [0x0000040080000000-0x00000400807fffff]: 0030:01:00.1
  mem addr range [0x0000040080800000-0x0000040080ffffff]: 0030:01:00.1
  mem addr range [0x0000040081000000-0x00000400817fffff]: 0030:01:00.0
  mem addr range [0x0000040081800000-0x0000040081ffffff]: 0030:01:00.0
  mem addr range [0x0000040082000000-0x000004008207ffff]: 0030:01:00.1
  mem addr range [0x0000040082080000-0x00000400820fffff]: 0030:01:00.0
  mem addr range [0x0000040082100000-0x000004008210ffff]: 0030:01:00.1
  mem addr range [0x0000040082110000-0x000004008211ffff]: 0030:01:00.0

Above is the list of cached io address ranges of pci 0030:01:00.<fn>.

Before this patch:

Tracing 'arg1' of function eeh_addr_cache_get_dev() during error injection clearly shows that 'addr=' contains wrong physical address:

kworker/u16:0-7 [001] .... 108.883775: eeh_addr_cache_get_dev:

	   (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x80103000a510

dmesg shows no EEH recovery messages:

  [  108.563768] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x9ae) != mcp_pulse (0x7fff)
  [  108.563788] bnx2x: [bnx2x_hw_stats_update:870(eth2)]NIG timer max (4294967295)
  [  108.883788] bnx2x: [bnx2x_acquire_hw_lock:2013(eth1)]lock_status 0xffffffff  resource_bit 0x1
  [  108.884407] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout
  [  108.884976] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout
  <..>

After this patch:

eeh_addr_cache_get_dev() trace shows correct physical address:

<idle>-0 [001] ..s. 1043.123828: eeh_addr_cache_get_dev:

	  (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x40080bc7cd8

dmesg logs shows EEH recovery getting triggerred:

  [  964.323980] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x746f) != mcp_pulse (0x7fff)
  [  964.323991] EEH: Recovering PHB#30-PE#10000
  [  964.324002] EEH: PE location: N/A, PHB location: N/A
  [  964.324006] EEH: Frozen PHB#30-PE#10000 detected
  <..>

Fixes 33439620680b ("powerpc/eeh: Handle hugepages in ioremap space")

Cc [email protected] # v5.3+

Reported-by Dominic DeMarco <[email protected]>

Signed-off-by Mahesh Salgaonkar <[email protected]>

Signed-off-by Aneesh Kumar K.V <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/161821396263.48361.2796709239866588652.stgit@jupiter open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/eeh.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

arch/powerpc/kernel/eeh.c +4 -7

@@ -366,14 +366,11 @@ static inline unsigned long eeh_token_to
 	pa = pte_pfn(*ptep);
 
 	/* On radix we can do hugepage mappings for io, so handle that */
-	if (hugepage_shift) {
-		pa <<= hugepage_shift;
-		pa |= token & ((1ul << hugepage_shift) - 1);
-	} else {
-		pa <<= PAGE_SHIFT;
-		pa |= token & (PAGE_SIZE - 1);
-	}
+	if (!hugepage_shift)
+		hugepage_shift = PAGE_SHIFT;
 
+	pa <<= PAGE_SHIFT;
+	pa |= token & ((1ul << hugepage_shift) - 1);
 	return pa;
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 10:49 UTC #56 lore raw

PATCH 56/240 jffs2: check the validity of dstlen in jffs2_zlib_compress()

In reply to Greg Kroah-Hartman

From: Yang Yang <[email protected]>

commit 90ada91f4610c5ef11bc52576516d96c496fc3f1 upstream.

KASAN reports a BUG when download file in jffs2 filesystem.It is because when dstlen == 1, cpage_out will write array out of bounds. Actually, data will not be compressed in jffs2_zlib_compress() if data's length less than 4.

[  393.799778] BUG: KASAN: slab-out-of-bounds in jffs2_rtime_compress+0x214/0x2f0 at addr ffff800062e3b281
[  393.809166] Write of size 1 by task tftp/2918
[  393.813526] CPU: 3 PID: 2918 Comm: tftp Tainted: G    B           4.9.115-rt93-EMBSYS-CGEL-6.1.R6-dirty #1
[  393.823173] Hardware name: LS1043A RDB Board (DT)
[  393.827870] Call trace:
[  393.830322] [<ffff20000808c700>] dump_backtrace+0x0/0x2f0
[  393.835721] [<ffff20000808ca04>] show_stack+0x14/0x20
[  393.840774] [<ffff2000086ef700>] dump_stack+0x90/0xb0
[  393.845829] [<ffff20000827b19c>] kasan_object_err+0x24/0x80
[  393.851402] [<ffff20000827b404>] kasan_report_error+0x1b4/0x4d8
[  393.857323] [<ffff20000827bae8>] kasan_report+0x38/0x40
[  393.862548] [<ffff200008279d44>] __asan_store1+0x4c/0x58
[  393.867859] [<ffff2000084ce2ec>] jffs2_rtime_compress+0x214/0x2f0
[  393.873955] [<ffff2000084bb3b0>] jffs2_selected_compress+0x178/0x2a0
[  393.880308] [<ffff2000084bb530>] jffs2_compress+0x58/0x478
[  393.885796] [<ffff2000084c5b34>] jffs2_write_inode_range+0x13c/0x450
[  393.892150] [<ffff2000084be0b8>] jffs2_write_end+0x2a8/0x4a0
[  393.897811] [<ffff2000081f3008>] generic_perform_write+0x1c0/0x280
[  393.903990] [<ffff2000081f5074>] __generic_file_write_iter+0x1c4/0x228
[  393.910517] [<ffff2000081f5210>] generic_file_write_iter+0x138/0x288
[  393.916870] [<ffff20000829ec1c>] __vfs_write+0x1b4/0x238
[  393.922181] [<ffff20000829ff00>] vfs_write+0xd0/0x238
[  393.927232] [<ffff2000082a1ba8>] SyS_write+0xa0/0x110
[  393.932283] [<ffff20000808429c>] __sys_trace_return+0x0/0x4
[  393.937851] Object at ffff800062e3b280, in cache kmalloc-64 size: 64
[  393.944197] Allocated:
[  393.946552] PID = 2918
[  393.948913]  save_stack_trace_tsk+0x0/0x220
[  393.953096]  save_stack_trace+0x18/0x20
[  393.956932]  kasan_kmalloc+0xd8/0x188
[  393.960594]  __kmalloc+0x144/0x238
[  393.963994]  jffs2_selected_compress+0x48/0x2a0
[  393.968524]  jffs2_compress+0x58/0x478
[  393.972273]  jffs2_write_inode_range+0x13c/0x450
[  393.976889]  jffs2_write_end+0x2a8/0x4a0
[  393.980810]  generic_perform_write+0x1c0/0x280
[  393.985251]  __generic_file_write_iter+0x1c4/0x228
[  393.990040]  generic_file_write_iter+0x138/0x288
[  393.994655]  __vfs_write+0x1b4/0x238
[  393.998228]  vfs_write+0xd0/0x238
[  394.001543]  SyS_write+0xa0/0x110
[  394.004856]  __sys_trace_return+0x0/0x4
[  394.008684] Freed:
[  394.010691] PID = 2918
[  394.013051]  save_stack_trace_tsk+0x0/0x220
[  394.017233]  save_stack_trace+0x18/0x20
[  394.021069]  kasan_slab_free+0x88/0x188
[  394.024902]  kfree+0x6c/0x1d8
[  394.027868]  jffs2_sum_write_sumnode+0x2c4/0x880
[  394.032486]  jffs2_do_reserve_space+0x198/0x598
[  394.037016]  jffs2_reserve_space+0x3f8/0x4d8
[  394.041286]  jffs2_write_inode_range+0xf0/0x450
[  394.045816]  jffs2_write_end+0x2a8/0x4a0
[  394.049737]  generic_perform_write+0x1c0/0x280
[  394.054179]  __generic_file_write_iter+0x1c4/0x228
[  394.058968]  generic_file_write_iter+0x138/0x288
[  394.063583]  __vfs_write+0x1b4/0x238
[  394.067157]  vfs_write+0xd0/0x238
[  394.070470]  SyS_write+0xa0/0x110
[  394.073783]  __sys_trace_return+0x0/0x4
[  394.077612] Memory state around the buggy address:
[  394.082404]  ffff800062e3b180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[  394.089623]  ffff800062e3b200: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
[  394.096842] >ffff800062e3b280: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  394.104056]                    ^
[  394.107283]  ffff800062e3b300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[  394.114502]  ffff800062e3b380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
[  394.121718] ==================================================================

Signed-off-by Yang Yang <[email protected]>

Cc Joel Stanley <[email protected]>

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/jffs2/compr_rtime.c |    3 +++
 1 file changed, 3 insertions(+)

fs/jffs2/compr_rtime.c +3 -0

@@ -37,6 +37,9 @@ static int jffs2_rtime_compress(unsigned
 	int outpos = 0;
 	int pos=0;
 
+	if (*dstlen <= 3)
+		return -1;
+
 	memset(positions,0,sizeof(positions));
 
 	while (pos < (*sourcelen) && outpos <= (*dstlen)-2) {

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #55 lore raw

PATCH 55/240 powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

In reply to Greg Kroah-Hartman

From: Tony Ambardar <[email protected]>

commit 7de21e679e6a789f3729e8402bc440b623a28eae upstream.

A few archs like powerpc have different errno.h values for macros EDEADLOCK and EDEADLK. In code including both libc and linux versions of errno.h, this can result in multiple definitions of EDEADLOCK in the include chain. Definitions to the same value (e.g. seen with mips) do not raise warnings, but on powerpc there are redefinitions changing the value, which raise warnings and errors (if using "-Werror").

Guard against these redefinitions to avoid build errors like the following, first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with musl 1.1.24:

In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5,

                   from ../../include/linux/err.h:8,
                   from libbpf.c:29:

../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined [-Werror]
#define EDEADLOCK EDEADLK

In file included from toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10,

                   from libbpf.c:26:

toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this is the location of the previous definition
#define EDEADLOCK 58

cc1: all warnings being treated as errors

Cc Stable <[email protected]>

Reported-by Rosen Penev <[email protected]>

Signed-off-by Tony Ambardar <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/uapi/asm/errno.h |    1 +
 1 file changed, 1 insertion(+)

arch/powerpc/include/uapi/asm/errno.h +1 -0

@@ -1,6 +1,7 @@
 #ifndef _ASM_POWERPC_ERRNO_H
 #define _ASM_POWERPC_ERRNO_H
 
+#undef	EDEADLOCK
 #include <asm-generic/errno.h>
 
 #undef	EDEADLOCK

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #57 lore raw

PATCH 57/240 Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op")

In reply to Greg Kroah-Hartman

From: Thomas Gleixner <[email protected]>

commit 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 upstream.

The FUTEX_WAIT operand has historically a relative timeout which means that the clock id is irrelevant as relative timeouts on CLOCK_REALTIME are not subject to wall clock changes and therefore are mapped by the kernel to CLOCK_MONOTONIC for simplicity.

If a caller would set FUTEX_CLOCK_REALTIME for FUTEX_WAIT the timeout is still treated relative vs. CLOCK_MONOTONIC and then the wait arms that timeout based on CLOCK_REALTIME which is broken and obviously has never been used or even tested.

Reject any attempt to use FUTEX_CLOCK_REALTIME with FUTEX_WAIT again.

The desired functionality can be achieved with FUTEX_WAIT_BITSET and a FUTEX_BITSET_MATCH_ANY argument.

Fixes 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op")

Signed-off-by Thomas Gleixner <[email protected]>

Acked-by Peter Zijlstra (Intel) <[email protected]>

Cc [email protected]

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/futex.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

kernel/futex.c +1 -2

@@ -3860,8 +3860,7 @@ long do_futex(u32 __user *uaddr, int op,
 
 	if (op & FUTEX_CLOCK_REALTIME) {
 		flags |= FLAGS_CLOCKRT;
-		if (cmd != FUTEX_WAIT && cmd != FUTEX_WAIT_BITSET && \
-		    cmd != FUTEX_WAIT_REQUEUE_PI)
+		if (cmd != FUTEX_WAIT_BITSET &&	cmd != FUTEX_WAIT_REQUEUE_PI)
 			return -ENOSYS;
 	}

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #58 lore raw

PATCH 58/240 ftrace: Handle commands when closing set_ftrace_filter file

In reply to Greg Kroah-Hartman

From: Steven Rostedt (VMware) <[email protected]>

commit 8c9af478c06bb1ab1422f90d8ecbc53defd44bc3 upstream.

 # echo switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter

will cause switch_mm to stop tracing by the traceoff command.

 # echo -n switch_mm:traceoff > /sys/kernel/tracing/set_ftrace_filter

does nothing.

The reason is that the parsing in the write function only processes commands if it finished parsing (there is white space written after the command). That's to handle:

write(fd, "switch_mm:", 10);
write(fd, "traceoff", 8);

cases, where the command is broken over multiple writes.

The problem is if the file descriptor is closed, then the write call is not processed, and the command needs to be processed in the release code. The release code can handle matching of functions, but does not handle commands.

Cc [email protected]

Fixes eda1e32855656 ("tracing: handle broken names in ftrace filter")

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/ftrace.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

kernel/trace/ftrace.c +4 -1

@@ -4486,8 +4486,11 @@ int ftrace_regex_release(struct inode *i
 
 	parser = &iter->parser;
 	if (trace_parser_loaded(parser)) {
+		int enable = !(iter->flags & FTRACE_ITER_NOTRACE);
+
 		parser->buffer[parser->idx] = 0;
-		ftrace_match_records(iter->hash, parser->buffer, parser->idx);
+		ftrace_process_regex(iter->hash, parser->buffer,
+				     parser->idx, enable);
 	}
 
 	trace_parser_put(parser);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #59 lore raw

PATCH 59/240 ext4: fix check to prevent false positive report of incorrect used inodes

In reply to Greg Kroah-Hartman

From: Zhang Yi <[email protected]>

commit a149d2a5cabbf6507a7832a1c4fd2593c55fd450 upstream.

Commit <50122847007> ("ext4: fix check to prevent initializing reserved inodes") check the block group zero and prevent initializing reserved inodes. But in some special cases, the reserved inode may not all belong to the group zero, it may exist into the second group if we format filesystem below.

mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda

So, it will end up triggering a false positive report of a corrupted file system. This patch fix it by avoid check reserved inodes if no free inode blocks will be zeroed.

Cc [email protected]

Fixes 50122847007 ("ext4: fix check to prevent initializing reserved inodes")

Signed-off-by Zhang Yi <[email protected]>

Suggested-by Jan Kara <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Theodore Ts'o <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/ialloc.c |   48 ++++++++++++++++++++++++++++++++----------------
 1 file changed, 32 insertions(+), 16 deletions(-)

fs/ext4/ialloc.c +32 ~~-16~~

@@ -1286,6 +1286,7 @@ int ext4_init_inode_table(struct super_b
 	handle_t *handle;
 	ext4_fsblk_t blk;
 	int num, ret = 0, used_blks = 0;
+	unsigned long used_inos = 0;
 
 	/* This should not happen, but just to be sure check this */
 	if (sb->s_flags & MS_RDONLY) {

@@ -1316,22 +1317,37 @@ int ext4_init_inode_table(struct super_b
 	 * used inodes so we need to skip blocks with used inodes in
 	 * inode table.
 	 */
-	if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)))
-		used_blks = DIV_ROUND_UP((EXT4_INODES_PER_GROUP(sb) -
-			    ext4_itable_unused_count(sb, gdp)),
-			    sbi->s_inodes_per_block);
-
-	if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group) ||
-	    ((group == 0) && ((EXT4_INODES_PER_GROUP(sb) -
-			       ext4_itable_unused_count(sb, gdp)) <
-			      EXT4_FIRST_INO(sb)))) {
-		ext4_error(sb, "Something is wrong with group %u: "
-			   "used itable blocks: %d; "
-			   "itable unused count: %u",
-			   group, used_blks,
-			   ext4_itable_unused_count(sb, gdp));
-		ret = 1;
-		goto err_out;
+	if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT))) {
+		used_inos = EXT4_INODES_PER_GROUP(sb) -
+			    ext4_itable_unused_count(sb, gdp);
+		used_blks = DIV_ROUND_UP(used_inos, sbi->s_inodes_per_block);
+
+		/* Bogus inode unused count? */
+		if (used_blks < 0 || used_blks > sbi->s_itb_per_group) {
+			ext4_error(sb, "Something is wrong with group %u: "
+				   "used itable blocks: %d; "
+				   "itable unused count: %u",
+				   group, used_blks,
+				   ext4_itable_unused_count(sb, gdp));
+			ret = 1;
+			goto err_out;
+		}
+
+		used_inos += group * EXT4_INODES_PER_GROUP(sb);
+		/*
+		 * Are there some uninitialized inodes in the inode table
+		 * before the first normal inode?
+		 */
+		if ((used_blks != sbi->s_itb_per_group) &&
+		     (used_inos < EXT4_FIRST_INO(sb))) {
+			ext4_error(sb, "Something is wrong with group %u: "
+				   "itable unused count: %u; "
+				   "itables initialized count: %ld",
+				   group, ext4_itable_unused_count(sb, gdp),
+				   used_inos);
+			ret = 1;
+			goto err_out;
+		}
 	}
 
 	blk = ext4_inode_table(sb, gdp) + used_blks;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #60 lore raw

PATCH 60/240 ext4: fix error code in ext4_commit_super

In reply to Greg Kroah-Hartman

From: Fengnan Chang <[email protected]>

commit f88f1466e2a2e5ca17dfada436d3efa1b03a3972 upstream.

We should set the error code when ext4_commit_super check argument failed. Found in code review.

Fixes c4be0c1dc4cdc ("filesystem freeze: add error handling of write_super_lockfs/unlockfs").

Cc [email protected]

Signed-off-by Fengnan Chang <[email protected]>

Reviewed-by Andreas Dilger <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Theodore Ts'o <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/super.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

fs/ext4/super.c +4 -2

@@ -4678,8 +4678,10 @@ static int ext4_commit_super(struct supe
 	struct buffer_head *sbh = EXT4_SB(sb)->s_sbh;
 	int error = 0;
 
-	if (!sbh || block_device_ejected(sb))
-		return error;
+	if (!sbh)
+		return -EINVAL;
+	if (block_device_ejected(sb))
+		return -ENODEV;
 
 	/*
 	 * If the file system is mounted read-only, don't update the

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #61 lore raw

PATCH 61/240 media: dvbdev: Fix memory leak in dvb_media_device_free()

In reply to Greg Kroah-Hartman

From: Peilin Ye <[email protected]>

commit bf9a40ae8d722f281a2721779595d6df1c33a0bf upstream.

dvb_media_device_free() is leaking memory. Free dvbdev->adapter->conn before setting it to NULL, as documented in include/media/media-device.h:
"The media_entity instance itself must be freed explicitly by the driver if required."

Link https://syzkaller.appspot.com/bug?id=9bbe4b842c98f0ed05c5eed77a226e9de33bf298

Link https://lore.kernel.org/linux-media/[email protected] open here

Cc [email protected]

Fixes 0230d60e4661 ("[media] dvbdev: Add RF connector if needed")

Reported-by [email protected]

Signed-off-by Peilin Ye <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/dvb-core/dvbdev.c |    1 +
 1 file changed, 1 insertion(+)

drivers/media/dvb-core/dvbdev.c +1 -0

@@ -216,6 +216,7 @@ static void dvb_media_device_free(struct
 
 	if (dvbdev->adapter->conn) {
 		media_device_unregister_entity(dvbdev->adapter->conn);
+		kfree(dvbdev->adapter->conn);
 		dvbdev->adapter->conn = NULL;
 		kfree(dvbdev->adapter->conn_pads);
 		dvbdev->adapter->conn_pads = NULL;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #62 lore raw

PATCH 62/240 usb: gadget: dummy_hcd: fix gpf in gadget_setup

In reply to Greg Kroah-Hartman

From: Anirudh Rayabharam <[email protected]>

commit 4a5d797a9f9c4f18585544237216d7812686a71f upstream.

Fix a general protection fault reported by syzbot due to a race between gadget_setup() and gadget_unbind() in raw_gadget.

The gadget core is supposed to guarantee that there won't be any more callbacks to the gadget driver once the driver's unbind routine is called. That guarantee is enforced in usb_gadget_remove_driver as follows:

        usb_gadget_disconnect(udc->gadget);
        if (udc->gadget->irq)
                synchronize_irq(udc->gadget->irq);
        udc->driver->unbind(udc->gadget);
        usb_gadget_udc_stop(udc);

usb_gadget_disconnect turns off the pullup resistor, telling the host that the gadget is no longer connected and preventing the transmission of any more USB packets. Any packets that have already been received are sure to processed by the UDC driver's interrupt handler by the time synchronize_irq returns.

But this doesn't work with dummy_hcd, because dummy_hcd doesn't use interrupts; it uses a timer instead. It does have code to emulate the effect of synchronize_irq, but that code doesn't get invoked at the right time -- it currently runs in usb_gadget_udc_stop, after the unbind callback instead of before. Indeed, there's no way for usb_gadget_remove_driver to invoke this code before the unbind callback.

To fix this, move the synchronize_irq() emulation code to dummy_pullup so that it runs before unbind. Also, add a comment explaining why it is necessary to have it there.

Reported-by [email protected]

Acked-by Alan Stern <[email protected]>

Signed-off-by Anirudh Rayabharam <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/udc/dummy_hcd.c |   23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

drivers/usb/gadget/udc/dummy_hcd.c +15 -8

@@ -918,6 +918,21 @@ static int dummy_pullup(struct usb_gadge
 	spin_lock_irqsave(&dum->lock, flags);
 	dum->pullup = (value != 0);
 	set_link_state(dum_hcd);
+	if (value == 0) {
+		/*
+		 * Emulate synchronize_irq(): wait for callbacks to finish.
+		 * This seems to be the best place to emulate the call to
+		 * synchronize_irq() that's in usb_gadget_remove_driver().
+		 * Doing it in dummy_udc_stop() would be too late since it
+		 * is called after the unbind callback and unbind shouldn't
+		 * be invoked until all the other callbacks are finished.
+		 */
+		while (dum->callback_usage > 0) {
+			spin_unlock_irqrestore(&dum->lock, flags);
+			usleep_range(1000, 2000);
+			spin_lock_irqsave(&dum->lock, flags);
+		}
+	}
 	spin_unlock_irqrestore(&dum->lock, flags);
 
 	usb_hcd_poll_rh_status(dummy_hcd_to_hcd(dum_hcd));

@@ -998,14 +1013,6 @@ static int dummy_udc_stop(struct usb_gad
 	spin_lock_irq(&dum->lock);
 	dum->ints_enabled = 0;
 	stop_activity(dum);
-
-	/* emulate synchronize_irq(): wait for callbacks to finish */
-	while (dum->callback_usage > 0) {
-		spin_unlock_irq(&dum->lock);
-		usleep_range(1000, 2000);
-		spin_lock_irq(&dum->lock);
-	}
-
 	dum->driver = NULL;
 	spin_unlock_irq(&dum->lock);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #36 lore raw

PATCH 36/240 clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 657d4d1934f75a2d978c3cf2086495eaa542e7a9 ]

There is an error return path that is not kfree'ing socfpga_clk leading to a memory leak. Fix this by adding in the missing kfree call.

Addresses-Coverity: ("Resource leak")

Signed-off-by Colin Ian King <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Acked-by Dinh Nguyen <[email protected]>

Reviewed-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/clk/socfpga/clk-gate-a10.c | 1 +
 1 file changed, 1 insertion(+)

drivers/clk/socfpga/clk-gate-a10.c +1 -0

index c2d572748167..7913dbedba89 100644
@@ -157,6 +157,7 @@ static void __init __socfpga_gate_init(struct device_node *node,
 		if (IS_ERR(socfpga_clk->sys_mgr_base_addr)) {
 			pr_err("%s: failed to find altr,sys-mgr regmap!\n",
 					__func__);
+			kfree(socfpga_clk);
 			return;
 		}
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #63 lore raw

PATCH 63/240 usb: gadget: Fix double free of device descriptor pointers

In reply to Greg Kroah-Hartman

From: Hemant Kumar <[email protected]>

commit 43c4cab006f55b6ca549dd1214e22f5965a8675f upstream.

Upon driver unbind usb_free_all_descriptors() function frees all speed descriptor pointers without setting them to NULL. In case gadget speed changes (i.e from super speed plus to super speed) after driver unbind only upto super speed descriptor pointers get populated. Super speed plus desc still holds the stale (already freed) pointer. Fix this issue by setting all descriptor pointers to NULL after freeing them in usb_free_all_descriptors().

Fixes f5c61225cf29 ("usb: gadget: Update function for SuperSpeedPlus")

cc [email protected]

Reviewed-by Peter Chen <[email protected]>

Signed-off-by Hemant Kumar <[email protected]>

Signed-off-by Wesley Cheng <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/config.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/usb/gadget/config.c +4 -0

@@ -198,9 +198,13 @@ EXPORT_SYMBOL_GPL(usb_assign_descriptors
 void usb_free_all_descriptors(struct usb_function *f)
 {
 	usb_free_descriptors(f->fs_descriptors);
+	f->fs_descriptors = NULL;
 	usb_free_descriptors(f->hs_descriptors);
+	f->hs_descriptors = NULL;
 	usb_free_descriptors(f->ss_descriptors);
+	f->ss_descriptors = NULL;
 	usb_free_descriptors(f->ssp_descriptors);
+	f->ssp_descriptors = NULL;
 }
 EXPORT_SYMBOL_GPL(usb_free_all_descriptors);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #64 lore raw

PATCH 64/240 usb: gadget/function/f_fs string table fix for multiple languages

In reply to Greg Kroah-Hartman

From: Dean Anderson <[email protected]>

commit 55b74ce7d2ce0b0058f3e08cab185a0afacfe39e upstream.

Fixes bug with the handling of more than one language in the string table in f_fs.c.
str_count was not reset for subsequent language codes. str_count-- "rolls under" and processes u32 max strings on the processing of the second language entry.
The existing bug can be reproduced by adding a second language table to the structure "strings" in tools/usb/ffs-test.c.

Signed-off-by Dean Anderson <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/function/f_fs.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/usb/gadget/function/f_fs.c +2 -1

@@ -2543,6 +2543,7 @@ static int __ffs_data_got_strings(struct
 
 	do { /* lang_count > 0 so we can use do-while */
 		unsigned needed = needed_count;
+		u32 str_per_lang = str_count;
 
 		if (unlikely(len < 3))
 			goto error_free;

@@ -2578,7 +2579,7 @@ static int __ffs_data_got_strings(struct
 
 			data += length + 1;
 			len -= length + 1;
-		} while (--str_count);
+		} while (--str_per_lang);
 
 		s->id = 0;   /* terminator */
 		s->s = NULL;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #65 lore raw

PATCH 65/240 dm persistent data: packed struct should have an aligned() attribute too

In reply to Greg Kroah-Hartman

From: Joe Thornber <[email protected]>

commit a88b2358f1da2c9f9fcc432f2e0a79617fea397c upstream.

Otherwise most non-x86 architectures (e.g. riscv, arm) will resort to byte-by-byte access.

Cc [email protected]

Signed-off-by Joe Thornber <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/persistent-data/dm-btree-internal.h   |    4 ++--
 drivers/md/persistent-data/dm-space-map-common.h |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

drivers/md/persistent-data/dm-btree-internal.h +2 -2

@@ -34,12 +34,12 @@ struct node_header {
 	__le32 max_entries;
 	__le32 value_size;
 	__le32 padding;
-} __packed;
+} __attribute__((packed, aligned(8)));
 
 struct btree_node {
 	struct node_header header;
 	__le64 keys[0];
-} __packed;
+} __attribute__((packed, aligned(8)));
 
 
 /*

drivers/md/persistent-data/dm-space-map-common.h +4 -4

@@ -33,7 +33,7 @@ struct disk_index_entry {
 	__le64 blocknr;
 	__le32 nr_free;
 	__le32 none_free_before;
-} __packed;
+} __attribute__ ((packed, aligned(8)));
 
 
 #define MAX_METADATA_BITMAPS 255

@@ -43,7 +43,7 @@ struct disk_metadata_index {
 	__le64 blocknr;
 
 	struct disk_index_entry index[MAX_METADATA_BITMAPS];
-} __packed;
+} __attribute__ ((packed, aligned(8)));
 
 struct ll_disk;

@@ -86,7 +86,7 @@ struct disk_sm_root {
 	__le64 nr_allocated;
 	__le64 bitmap_root;
 	__le64 ref_count_root;
-} __packed;
+} __attribute__ ((packed, aligned(8)));
 
 #define ENTRIES_PER_BYTE 4

@@ -94,7 +94,7 @@ struct disk_bitmap_header {
 	__le32 csum;
 	__le32 not_used;
 	__le64 blocknr;
-} __packed;
+} __attribute__ ((packed, aligned(8)));
 
 enum allocation_event {
 	SM_NONE,

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #66 lore raw

PATCH 66/240 dm space map common: fix division bug in sm_ll_find_free_block()

In reply to Greg Kroah-Hartman

From: Joe Thornber <[email protected]>

commit 5208692e80a1f3c8ce2063a22b675dd5589d1d80 upstream.

This division bug meant the search for free metadata space could skip the final allocation bitmap's worth of entries. Fix affects DM thinp, cache and era targets.

Cc [email protected]

Signed-off-by Joe Thornber <[email protected]>

Tested-by Ming-Hung Tsai <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/persistent-data/dm-space-map-common.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/md/persistent-data/dm-space-map-common.c +2 -0

@@ -337,6 +337,8 @@ int sm_ll_find_free_block(struct ll_disk
 	 */
 	begin = do_div(index_begin, ll->entries_per_block);
 	end = do_div(end, ll->entries_per_block);
+	if (end == 0)
+		end = ll->entries_per_block;
 
 	for (i = index_begin; i < index_end; i++, begin = 0) {
 		struct dm_block *blk;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #67 lore raw

PATCH 67/240 dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails

In reply to Greg Kroah-Hartman

From: Benjamin Block <[email protected]>

commit 8e947c8f4a5620df77e43c9c75310dc510250166 upstream.

When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free.

E.g. (dmesg):
device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device
device-mapper: ioctl: unable to set up device queue for new table.

  Unable to handle kernel pointer dereference in virtual kernel address space
  Failing address: 0305e098835de000 TEID: 0305e098835de803
  Fault in home space mode while using kernel ASCE.
  AS:000000025efe0007 R3:0000000000000024
  Oops: 0038 ilc:3 [#1] SMP
  Modules linked in: ... lots of modules ...
  Supported: Yes, External
  CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G        W      X    5.3.18-53-default #1 SLE15-SP3
  Hardware name: IBM 8561 T01 7I2 (LPAR)
  Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)
             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
  Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000
             000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000
             000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640
             00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8
  Krnl Code: 000000025e368eb8: c4180041e100       lgrl    %r1,25eba50b8
             000000025e368ebe: ecba06b93a55       risbg   %r11,%r10,6,185,58
            #000000025e368ec4: e3b010000008       ag      %r11,0(%r1)
            >000000025e368eca: e310b0080004       lg      %r1,8(%r11)
             000000025e368ed0: a7110001           tmll    %r1,1
             000000025e368ed4: a7740129           brc     7,25e369126
             000000025e368ed8: e320b0080004       lg      %r2,8(%r11)
             000000025e368ede: b904001b           lgr     %r1,%r11
  Call Trace:
   [<000000025e368eca>] kfree+0x42/0x330
   [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8
   [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]
   [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]
   [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod]
   [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod]
   [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod]
   [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod]
   [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0
   [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40
   [<000000025e8c15ac>] system_call+0xd8/0x2c8
  Last Breaking-Event-Address:
   [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8
  Kernel panic - not syncing: Fatal exception: panic_on_oops

When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again.

Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().

Cc <[email protected]> # 4.6+

Fixes 1c357a1e86a4 ("dm: allocate blk_mq_tag_set rather than embed in mapped_device")

Signed-off-by Benjamin Block <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-rq.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/md/dm-rq.c +2 -0

@@ -1009,6 +1009,7 @@ out_tag_set:
 	blk_mq_free_tag_set(md->tag_set);
 out_kfree_tag_set:
 	kfree(md->tag_set);
+	md->tag_set = NULL;
 
 	return err;
 }

@@ -1018,6 +1019,7 @@ void dm_mq_cleanup_mapped_device(struct
 	if (md->tag_set) {
 		blk_mq_free_tag_set(md->tag_set);
 		kfree(md->tag_set);
+		md->tag_set = NULL;
 	}
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #68 lore raw

PATCH 68/240 Bluetooth: verify AMP hci_chan before amp_destroy

In reply to Greg Kroah-Hartman

From: Archie Pusaka <[email protected]>

commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 upstream.

hci_chan can be created in 2 places: hci_loglink_complete_evt() if it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory, Only AMP hci_chan should be removed by a call to hci_disconn_loglink_complete_evt(). However, the controller might mess up, call that function, and destroy an hci_chan which is not initiated by hci_loglink_complete_evt().

This patch adds a verification that the destroyed hci_chan must have been init'd by hci_loglink_complete_evt().

Example crash call trace:

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xe3/0x144 lib/dump_stack.c:118
 print_address_description+0x67/0x22a mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report mm/kasan/report.c:412 [inline]
 kasan_report+0x251/0x28f mm/kasan/report.c:396
 hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072
 l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877
 l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661
 l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline]
 l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline]
 l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline]
 l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023
 l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596
 hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline]
 hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796
 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
 kthread+0x2f0/0x304 kernel/kthread.c:253
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

Allocated by task 38:
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553
 kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787
 kmalloc include/linux/slab.h:515 [inline]
 kzalloc include/linux/slab.h:709 [inline]
 hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674
 l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062
 l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline]
 l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381
 hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404
 hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline]
 hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981
 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
 kthread+0x2f0/0x304 kernel/kthread.c:253
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

Freed by task 1732:
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free mm/kasan/kasan.c:521 [inline]
 __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493
 slab_free_hook mm/slub.c:1409 [inline]
 slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436
 slab_free mm/slub.c:3009 [inline]
 kfree+0x182/0x21e mm/slub.c:3972
 hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline]
 hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050
 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
 kthread+0x2f0/0x304 kernel/kthread.c:253
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415

The buggy address belongs to the object at ffff8881d7af9180
 which belongs to the cache kmalloc-128 of size 128
The buggy address is located 24 bytes inside of
 128-byte region [ffff8881d7af9180, ffff8881d7af9200)
The buggy address belongs to the page:
page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0
flags: 0x8000000000000200(slab)
raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
 ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Signed-off-by Archie Pusaka <[email protected]>

Reported-by [email protected]

Reviewed-by Alain Michaud <[email protected]>

Reviewed-by Abhishek Pandit-Subedi <[email protected]>

Signed-off-by Marcel Holtmann <[email protected]>

Cc George Kennedy <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/net/bluetooth/hci_core.h |    1 +
 net/bluetooth/hci_event.c        |    3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

include/net/bluetooth/hci_core.h +1 -0

@@ -512,6 +512,7 @@ struct hci_chan {
 	struct sk_buff_head data_q;
 	unsigned int	sent;
 	__u8		state;
+	bool		amp;
 };
 
 struct hci_conn_params {

net/bluetooth/hci_event.c +2 -1

@@ -4399,6 +4399,7 @@ static void hci_loglink_complete_evt(str
 		return;
 
 	hchan->handle = le16_to_cpu(ev->handle);
+	hchan->amp = true;
 
 	BT_DBG("hcon %p mgr %p hchan %p", hcon, hcon->amp_mgr, hchan);

@@ -4431,7 +4432,7 @@ static void hci_disconn_loglink_complete
 	hci_dev_lock(hdev);
 
 	hchan = hci_chan_lookup_handle(hdev, le16_to_cpu(ev->handle));
-	if (!hchan)
+	if (!hchan || !hchan->amp)
 		goto unlock;
 
 	amp_destroy_logical_link(hchan, ev->reason);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #37 lore raw

PATCH 37/240 power: supply: generic-adc-battery: fix possible use-after-free in gab_remove()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit b6cfa007b3b229771d9588970adb4ab3e0487f49 ]

Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself.

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Signed-off-by Sebastian Reichel <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/power/supply/generic-adc-battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/power/supply/generic-adc-battery.c +1 -1

index f627b39f64bf..b77fd751945d 100644
@@ -384,7 +384,7 @@ static int gab_remove(struct platform_device *pdev)
 	}
 
 	kfree(adc_bat->psy_desc.properties);
-	cancel_delayed_work(&adc_bat->bat_work);
+	cancel_delayed_work_sync(&adc_bat->bat_work);
 	return 0;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #38 lore raw

PATCH 38/240 power: supply: s3c_adc_battery: fix possible use-after-free in s3c_adc_bat_remove()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit 68ae256945d2abe9036a7b68af4cc65aff79d5b7 ]

Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself.

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Reviewed-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Sebastian Reichel <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/power/supply/s3c_adc_battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/power/supply/s3c_adc_battery.c +1 -1

index 0ffe5cd3abf6..06b412c43aa7 100644
@@ -392,7 +392,7 @@ static int s3c_adc_bat_remove(struct platform_device *pdev)
 		gpio_free(pdata->gpio_charge_finished);
 	}
 
-	cancel_delayed_work(&bat_work);
+	cancel_delayed_work_sync(&bat_work);
 
 	if (pdata->exit)
 		pdata->exit();

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:50 UTC #39 lore raw

PATCH 39/240 media: adv7604: fix possible use-after-free in adv76xx_remove()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit fa56f5f1fe31c2050675fa63b84963ebd504a5b3 ]

Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself.

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/adv7604.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/i2c/adv7604.c +1 -1

index ce6f93074ae0..56b8b7bf759e 100644
@@ -3541,7 +3541,7 @@ static int adv76xx_remove(struct i2c_client *client)
 	io_write(sd, 0x6e, 0);
 	io_write(sd, 0x73, 0);
 
-	cancel_delayed_work(&state->delayed_work_enable_hotplug);
+	cancel_delayed_work_sync(&state->delayed_work_enable_hotplug);
 	v4l2_async_unregister_subdev(sd);
 	media_entity_cleanup(&sd->entity);
 	adv76xx_unregister_clients(to_state(sd));

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #41 lore raw

PATCH 41/240 media: i2c: adv7842: fix possible use-after-free in adv7842_remove()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit 4a15275b6a18597079f18241c87511406575179a ]

Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself.

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/adv7842.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/i2c/adv7842.c +1 -1

index cf3b42c9417e..d7af4fbcb84b 100644
@@ -3598,7 +3598,7 @@ static int adv7842_remove(struct i2c_client *client)
 	struct adv7842_state *state = to_state(sd);
 
 	adv7842_irq_enable(sd, false);
-	cancel_delayed_work(&state->delayed_work_enable_hotplug);
+	cancel_delayed_work_sync(&state->delayed_work_enable_hotplug);
 	v4l2_device_unregister_subdev(sd);
 	media_entity_cleanup(&sd->entity);
 	adv7842_unregister_clients(sd);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #40 lore raw

PATCH 40/240 media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit 2c9541720c66899adf6f3600984cf3ef151295ad ]

Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself.

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/adv7511-v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/i2c/adv7511-v4l2.c +1 -1

index b87c9e7ff146..e81c4cca50c6 100644
@@ -1976,7 +1976,7 @@ static int adv7511_remove(struct i2c_client *client)
 
 	adv7511_set_isr(sd, false);
 	adv7511_init_setup(sd);
-	cancel_delayed_work(&state->edid_handler);
+	cancel_delayed_work_sync(&state->edid_handler);
 	i2c_unregister_device(state->i2c_edid);
 	if (state->i2c_cec)
 		i2c_unregister_device(state->i2c_cec);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #42 lore raw

PATCH 42/240 media: dvb-usb: fix memory leak in dvb_usb_adapter_init

In reply to Greg Kroah-Hartman

From: Pavel Skripkin <[email protected]>

[ Upstream commit b7cd0da982e3043f2eec7235ac5530cb18d6af1d ]

syzbot reported memory leak in dvb-usb. The problem was in invalid error handling in dvb_usb_adapter_init().

for (n = 0; n < d->props.num_adapters; n++) {
....

	if ((ret = dvb_usb_adapter_stream_init(adap)) ||
		(ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs)) ||
		(ret = dvb_usb_adapter_frontend_init(adap))) {
		return ret;
	}
...
	d->num_adapters_initialized++;

...
}

In case of error in dvb_usb_adapter_dvb_init() or dvb_usb_adapter_dvb_init() d->num_adapters_initialized won't be incremented, but dvb_usb_adapter_exit() relies on it:

	for (n = 0; n < d->num_adapters_initialized; n++)

So, allocated objects won't be freed.

Signed-off-by Pavel Skripkin <[email protected]>

Reported-by [email protected]

Signed-off-by Sean Young <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/dvb-usb/dvb-usb-init.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

drivers/media/usb/dvb-usb/dvb-usb-init.c +16 -4

index b3413404f91a..690c1e06fbfa 100644
@@ -82,11 +82,17 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs)
 			}
 		}
 
-		if ((ret = dvb_usb_adapter_stream_init(adap)) ||
-			(ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs)) ||
-			(ret = dvb_usb_adapter_frontend_init(adap))) {
+		ret = dvb_usb_adapter_stream_init(adap);
+		if (ret)
 			return ret;
-		}
+
+		ret = dvb_usb_adapter_dvb_init(adap, adapter_nrs);
+		if (ret)
+			goto dvb_init_err;
+
+		ret = dvb_usb_adapter_frontend_init(adap);
+		if (ret)
+			goto frontend_init_err;
 
 		/* use exclusive FE lock if there is multiple shared FEs */
 		if (adap->fe_adap[1].fe)

@@ -106,6 +112,12 @@ static int dvb_usb_adapter_init(struct dvb_usb_device *d, short *adapter_nrs)
 	}
 
 	return 0;
+
+frontend_init_err:
+	dvb_usb_adapter_dvb_exit(adap);
+dvb_init_err:
+	dvb_usb_adapter_stream_exit(adap);
+	return ret;
 }
 
 static int dvb_usb_adapter_exit(struct dvb_usb_device *d)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #70 lore raw

PATCH 70/240 bluetooth: eliminate the potential race condition when removing the HCI controller

In reply to Greg Kroah-Hartman

From: Lin Ma <[email protected]>

commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 upstream.

There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below:

thread-A in hci_req_sync()      |   thread-B in hci_dev_do_close()
                                |   hci_req_sync_lock(hdev);
test_bit(HCI_UP, &hdev->flags); |
...                             |   test_and_clear_bit(HCI_UP, &hdev->flags)
hci_req_sync_lock(hdev);        |
                                |

In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th.

Signed-off-by Lin Ma <[email protected]>

Cc Marcel Holtmann <[email protected]>

Fixes 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/bluetooth/hci_request.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

net/bluetooth/hci_request.c +8 -4

@@ -275,12 +275,16 @@ int hci_req_sync(struct hci_dev *hdev, i
 {
 	int ret;
 
-	if (!test_bit(HCI_UP, &hdev->flags))
-		return -ENETDOWN;
-
 	/* Serialize all requests */
 	hci_req_sync_lock(hdev);
-	ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);
+	/* check the state after obtaing the lock to protect the HCI_UP
+	 * against any races from hci_dev_do_close when the controller
+	 * gets removed.
+	 */
+	if (test_bit(HCI_UP, &hdev->flags))
+		ret = __hci_req_sync(hdev, req, opt, timeout, hci_status);
+	else
+		ret = -ENETDOWN;
 	hci_req_sync_unlock(hdev);
 
 	return ret;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #33 lore raw

PATCH 33/240 scsi: qla2xxx: Always check the return value of qla24xx_get_isp_stats()

In reply to Greg Kroah-Hartman

From: Bart Van Assche <[email protected]>

[ Upstream commit a2b2cc660822cae08c351c7f6b452bfd1330a4f7 ]

This patch fixes the following Coverity warning:

CID 361199 (#1 of 1): Unchecked return value (CHECKED_RETURN)
3. check_return: Calling qla24xx_get_isp_stats without checking return value (as is done elsewhere 4 out of 5 times).

Link https://lore.kernel.org/r/[email protected] open here

Cc Quinn Tran <[email protected]>

Cc Mike Christie <[email protected]>

Cc Himanshu Madhani <[email protected]>

Cc Daniel Wagner <[email protected]>

Cc Lee Duncan <[email protected]>

Reviewed-by Daniel Wagner <[email protected]>

Reviewed-by Himanshu Madhani <[email protected]>

Signed-off-by Bart Van Assche <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/qla2xxx/qla_attr.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/scsi/qla2xxx/qla_attr.c +7 -1

index 33f4181ba9f7..591e2e89ae9f 100644
@@ -1909,6 +1909,8 @@ qla2x00_reset_host_stats(struct Scsi_Host *shost)
 	vha->qla_stats.jiffies_at_last_reset = get_jiffies_64();
 
 	if (IS_FWI2_CAPABLE(ha)) {
+		int rval;
+
 		stats = dma_alloc_coherent(&ha->pdev->dev,
 		    sizeof(*stats), &stats_dma, GFP_KERNEL);
 		if (!stats) {

@@ -1918,7 +1920,11 @@ qla2x00_reset_host_stats(struct Scsi_Host *shost)
 		}
 
 		/* reset firmware statistics */
-		qla24xx_get_isp_stats(base_vha, stats, stats_dma, BIT_0);
+		rval = qla24xx_get_isp_stats(base_vha, stats, stats_dma, BIT_0);
+		if (rval != QLA_SUCCESS)
+			ql_log(ql_log_warn, vha, 0x70de,
+			       "Resetting ISP statistics failed: rval = %d\n",
+			       rval);
 
 		dma_free_coherent(&ha->pdev->dev, sizeof(*stats),
 		    stats, stats_dma);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #79 lore raw

PATCH 79/240 tracing: Restructure trace_clock_global() to never block

In reply to Greg Kroah-Hartman

From: Steven Rostedt (VMware) <[email protected]>

commit aafe104aa9096827a429bc1358f8260ee565b7cc upstream.

It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case:

Call Trace:
 trace_clock_global+0x91/0xa0
 __rb_reserve_next+0x237/0x460
 ring_buffer_lock_reserve+0x12a/0x3f0
 trace_buffer_lock_reserve+0x10/0x50
 __trace_graph_return+0x1f/0x80
 trace_graph_return+0xb7/0xf0
 ? trace_clock_global+0x91/0xa0
 ftrace_return_to_handler+0x8b/0xf0
 ? pv_hash+0xa0/0xa0
 return_to_handler+0x15/0x30
 ? ftrace_graph_caller+0xa0/0xa0
 ? trace_clock_global+0x91/0xa0
 ? __rb_reserve_next+0x237/0x460
 ? ring_buffer_lock_reserve+0x12a/0x3f0
 ? trace_event_buffer_lock_reserve+0x3c/0x120
 ? trace_event_buffer_reserve+0x6b/0xc0
 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0
 ? dpm_run_callback+0x3b/0xc0
 ? pm_ops_is_empty+0x50/0x50
 ? platform_get_irq_byname_optional+0x90/0x90
 ? trace_device_pm_callback_start+0x82/0xd0
 ? dpm_run_callback+0x49/0xc0

With the following RIP:

RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again:

ring_buffer_lock_reserve() {

  trace_clock_global() {
    arch_spin_lock() {
      queued_spin_lock_slowpath() {
        /* lock taken */
        (something else gets traced by function graph tracer)
          ring_buffer_lock_reserve() {
            trace_clock_global() {
              arch_spin_lock() {
                queued_spin_lock_slowpath() {
                /* DEAD LOCK! */

Tracing should *never* block, as it can lead to strange lockups like the above.

Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it.

Link https://lkml.kernel.org/r/[email protected] open here

Cc [email protected]

Tested-by Konstantin Kharlamov <[email protected]>

Tested-by Todd Brandt <[email protected]>

Fixes b02414c8f045 ("ring-buffer: Fix recursion protection transitions between interrupt context") # started showing the problem

Fixes 14131f2f98ac3 ("tracing: implement trace_clock_*() APIs") # where the bug happened

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/trace_clock.c |   48 ++++++++++++++++++++++++++++++---------------
 1 file changed, 32 insertions(+), 16 deletions(-)

kernel/trace/trace_clock.c +32 ~~-16~~

@@ -93,33 +93,49 @@ u64 notrace trace_clock_global(void)
 {
 	unsigned long flags;
 	int this_cpu;
-	u64 now;
+	u64 now, prev_time;
 
 	local_irq_save(flags);
 
 	this_cpu = raw_smp_processor_id();
-	now = sched_clock_cpu(this_cpu);
+
 	/*
-	 * If in an NMI context then dont risk lockups and return the
-	 * cpu_clock() time:
+	 * The global clock "guarantees" that the events are ordered
+	 * between CPUs. But if two events on two different CPUS call
+	 * trace_clock_global at roughly the same time, it really does
+	 * not matter which one gets the earlier time. Just make sure
+	 * that the same CPU will always show a monotonic clock.
+	 *
+	 * Use a read memory barrier to get the latest written
+	 * time that was recorded.
 	 */
-	if (unlikely(in_nmi()))
-		goto out;
+	smp_rmb();
+	prev_time = READ_ONCE(trace_clock_struct.prev_time);
+	now = sched_clock_cpu(this_cpu);
 
-	arch_spin_lock(&trace_clock_struct.lock);
+	/* Make sure that now is always greater than prev_time */
+	if ((s64)(now - prev_time) < 0)
+		now = prev_time + 1;
 
 	/*
-	 * TODO: if this happens often then maybe we should reset
-	 * my_scd->clock to prev_time+1, to make sure
-	 * we start ticking with the local clock from now on?
+	 * If in an NMI context then dont risk lockups and simply return
+	 * the current time.
 	 */
-	if ((s64)(now - trace_clock_struct.prev_time) < 0)
-		now = trace_clock_struct.prev_time + 1;
-
-	trace_clock_struct.prev_time = now;
-
-	arch_spin_unlock(&trace_clock_struct.lock);
+	if (unlikely(in_nmi()))
+		goto out;
 
+	/* Tracing can cause strange recursion, always use a try lock */
+	if (arch_spin_trylock(&trace_clock_struct.lock)) {
+		/* Reread prev_time in case it was already updated */
+		prev_time = READ_ONCE(trace_clock_struct.prev_time);
+		if ((s64)(now - prev_time) < 0)
+			now = prev_time + 1;
+
+		trace_clock_struct.prev_time = now;
+
+		/* The unlock acts as the wmb for the above rmb */
+		arch_spin_unlock(&trace_clock_struct.lock);
+	}
  out:
 	local_irq_restore(flags);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #80 lore raw

PATCH 80/240 md-cluster: fix use-after-free issue when removing rdev

In reply to Greg Kroah-Hartman

From: Heming Zhao <[email protected]>

commit f7c7a2f9a23e5b6e0f5251f29648d0238bb7757e upstream.

md_kick_rdev_from_array will remove rdev, so we should use rdev_for_each_safe to search list.

How to trigger:

env: Two nodes on kvm-qemu x86_64 VMs (2C2G with 2 iscsi luns).

```
node2=192.168.0.3

for i in {1..20}; do
    echo ==== $i `date` ====;

    mdadm -Ss && ssh ${node2} "mdadm -Ss"
    wipefs -a /dev/sda /dev/sdb

    mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l 1 /dev/sda \
       /dev/sdb --assume-clean
    ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb"
    mdadm --wait /dev/md0
    ssh ${node2} "mdadm --wait /dev/md0"

    mdadm --manage /dev/md0 --fail /dev/sda --remove /dev/sda
    sleep 1
done
```

Crash stack:

```
stack segment: 0000 [#1] SMP
... ...
RIP: 0010:md_check_recovery+0x1e8/0x570 [md_mod]
... ...
RSP: 0018:ffffb149807a7d68 EFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff9d494c180800 RCX: ffff9d490fc01e50
RDX: fffff047c0ed8308 RSI: 0000000000000246 RDI: 0000000000000246
RBP: 6b6b6b6b6b6b6b6b R08: ffff9d490fc01e40 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
R13: ffff9d494c180818 R14: ffff9d493399ef38 R15: ffff9d4933a1d800
FS:  0000000000000000(0000) GS:ffff9d494f700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe68cab9010 CR3: 000000004c6be001 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 raid1d+0x5c/0xd40 [raid1]
 ? finish_task_switch+0x75/0x2a0
 ? lock_timer_base+0x67/0x80
 ? try_to_del_timer_sync+0x4d/0x80
 ? del_timer_sync+0x41/0x50
 ? schedule_timeout+0x254/0x2d0
 ? md_start_sync+0xe0/0xe0 [md_mod]
 ? md_thread+0x127/0x160 [md_mod]
 md_thread+0x127/0x160 [md_mod]
 ? wait_woken+0x80/0x80
 kthread+0x10d/0x130
 ? kthread_park+0xa0/0xa0
 ret_from_fork+0x1f/0x40
```

Fixes dbb64f8635f5d ("md-cluster: Fix adding of new disk with new reload code")

Fixes 659b254fa7392 ("md-cluster: remove a disk asynchronously from cluster environment")

Cc [email protected]

Reviewed-by Gang He <[email protected]>

Signed-off-by Heming Zhao <[email protected]>

Signed-off-by Song Liu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/md.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/md/md.c +4 -4

@@ -8462,11 +8462,11 @@ void md_check_recovery(struct mddev *mdd
 		}
 
 		if (mddev_is_clustered(mddev)) {
-			struct md_rdev *rdev;
+			struct md_rdev *rdev, *tmp;
 			/* kick the device if another node issued a
 			 * remove disk.
 			 */
-			rdev_for_each(rdev, mddev) {
+			rdev_for_each_safe(rdev, tmp, mddev) {
 				if (test_and_clear_bit(ClusterRemove, &rdev->flags) &&
 						rdev->raid_disk < 0)
 					md_kick_rdev_from_array(rdev);

@@ -8775,12 +8775,12 @@ err_wq:
 static void check_sb_changes(struct mddev *mddev, struct md_rdev *rdev)
 {
 	struct mdp_superblock_1 *sb = page_address(rdev->sb_page);
-	struct md_rdev *rdev2;
+	struct md_rdev *rdev2, *tmp;
 	int role, ret;
 	char b[BDEVNAME_SIZE];
 
 	/* Check for change of roles in the active devices */
-	rdev_for_each(rdev2, mddev) {
+	rdev_for_each_safe(rdev2, tmp, mddev) {
 		if (test_bit(Faulty, &rdev2->flags))
 			continue;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #81 lore raw

PATCH 81/240 md: factor out a mddev_find_locked helper from mddev_find

In reply to Greg Kroah-Hartman

From: Christoph Hellwig <[email protected]>

commit 8b57251f9a91f5e5a599de7549915d2d226cc3af upstream.

Factor out a self-contained helper to just lookup a mddev by the dev_t "unit".

Cc [email protected]

Reviewed-by Heming Zhao <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Song Liu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/md.c |   32 +++++++++++++++++++-------------
 1 file changed, 19 insertions(+), 13 deletions(-)

drivers/md/md.c +19 ~~-13~~

@@ -508,6 +508,17 @@ void mddev_init(struct mddev *mddev)
 }
 EXPORT_SYMBOL_GPL(mddev_init);
 
+static struct mddev *mddev_find_locked(dev_t unit)
+{
+	struct mddev *mddev;
+
+	list_for_each_entry(mddev, &all_mddevs, all_mddevs)
+		if (mddev->unit == unit)
+			return mddev;
+
+	return NULL;
+}
+
 static struct mddev *mddev_find(dev_t unit)
 {
 	struct mddev *mddev, *new = NULL;

@@ -519,13 +530,13 @@ static struct mddev *mddev_find(dev_t un
 	spin_lock(&all_mddevs_lock);
 
 	if (unit) {
-		list_for_each_entry(mddev, &all_mddevs, all_mddevs)
-			if (mddev->unit == unit) {
-				mddev_get(mddev);
-				spin_unlock(&all_mddevs_lock);
-				kfree(new);
-				return mddev;
-			}
+		mddev = mddev_find_locked(unit);
+		if (mddev) {
+			mddev_get(mddev);
+			spin_unlock(&all_mddevs_lock);
+			kfree(new);
+			return mddev;
+		}
 
 		if (new) {
 			list_add(&new->all_mddevs, &all_mddevs);

@@ -551,12 +562,7 @@ static struct mddev *mddev_find(dev_t un
 				return NULL;
 			}
 
-			is_free = 1;
-			list_for_each_entry(mddev, &all_mddevs, all_mddevs)
-				if (mddev->unit == dev) {
-					is_free = 0;
-					break;
-				}
+			is_free = !mddev_find_locked(dev);
 		}
 		new->unit = dev;
 		new->md_minor = MINOR(dev);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #82 lore raw

PATCH 82/240 md: md_open returns -EBUSY when entering racing area

In reply to Greg Kroah-Hartman

From: Zhao Heming <[email protected]>

commit 6a4db2a60306eb65bfb14ccc9fde035b74a4b4e7 upstream.

commit d3374825ce57 ("md: make devices disappear when they are no longer needed.") introduced protection between mddev creating & removing. The md_open shouldn't create mddev when all_mddevs list doesn't contain mddev. With currently code logic, there will be very easy to trigger soft lockup in non-preempt env.

This patch changes md_open returning from -ERESTARTSYS to -EBUSY, which will break the infinitely retry when md_open enter racing area.

This patch is partly fix soft lockup issue, full fix needs mddev_find is split into two functions: mddev_find & mddev_find_or_alloc. And md_open should call new mddev_find (it only does searching job).

For more detail, please refer with Christoph's "split mddev_find" patch in later commits.

*** env ***
kvm-qemu VM 2C1G with 2 iscsi luns
kernel should be non-preempt

*** script ***

about trigger every time with below script

```
1  node1="mdcluster1"
2  node2="mdcluster2"
3
4  mdadm -Ss
5  ssh ${node2} "mdadm -Ss"
6  wipefs -a /dev/sda /dev/sdb
7  mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda \
   /dev/sdb --assume-clean
8
9  for i in {1..10}; do
10    echo ==== $i ====;
11
12    echo "test  ...."
13    ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb"
14    sleep 1
15
16    echo "clean  ....."
17    ssh ${node2} "mdadm -Ss"
18 done
```

I use mdcluster env to trigger soft lockup, but it isn't mdcluster speical bug. To stop md array in mdcluster env will do more jobs than non-cluster array, which will leave enough time/gap to allow kernel to run md_open.

*** stack ***

```
[  884.226509]  mddev_put+0x1c/0xe0 [md_mod]
[  884.226515]  md_open+0x3c/0xe0 [md_mod]
[  884.226518]  __blkdev_get+0x30d/0x710
[  884.226520]  ? bd_acquire+0xd0/0xd0
[  884.226522]  blkdev_get+0x14/0x30
[  884.226524]  do_dentry_open+0x204/0x3a0
[  884.226531]  path_openat+0x2fc/0x1520
[  884.226534]  ? seq_printf+0x4e/0x70
[  884.226536]  do_filp_open+0x9b/0x110
[  884.226542]  ? md_release+0x20/0x20 [md_mod]
[  884.226543]  ? seq_read+0x1d8/0x3e0
[  884.226545]  ? kmem_cache_alloc+0x18a/0x270
[  884.226547]  ? do_sys_open+0x1bd/0x260
[  884.226548]  do_sys_open+0x1bd/0x260
[  884.226551]  do_syscall_64+0x5b/0x1e0
[  884.226554]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
```

*** rootcause ***

"mdadm -A" (or other array assemble commands) will start a daemon "mdadm --monitor" by default. When "mdadm -Ss" is running, the stop action will wakeup "mdadm --monitor". The "--monitor" daemon will immediately get info from /proc/mdstat. This time mddev in kernel still exist, so /proc/mdstat still show md device, which makes "mdadm --monitor" to open /dev/md0.

The previously "mdadm -Ss" is removing action, the "mdadm --monitor" open action will trigger md_open which is creating action. Racing is happening.

```
<thread 1>: "mdadm -Ss"
md_release
  mddev_put deletes mddev from all_mddevs
  queue_work for mddev_delayed_delete
  at this time, "/dev/md0" is still available for opening

<thread 2>: "mdadm --monitor ..."
md_open
 + mddev_find can't find mddev of /dev/md0, and create a new mddev and
 |    return.
 + trigger "if (mddev->gendisk != bdev->bd_disk)" and return
      -ERESTARTSYS.
```

In non-preempt kernel, <thread 2> is occupying on current CPU. and mddev_delayed_delete which was created in <thread 1> also can't be schedule.

In preempt kernel, it can also trigger above racing. But kernel doesn't allow one thread running on a CPU all the time. after <thread 2> running some time, the later "mdadm -A" (refer above script line 13) will call md_alloc to alloc a new gendisk for mddev. it will break md_open statement "if (mddev->gendisk != bdev->bd_disk)" and return 0 to caller, the soft lockup is broken.

Cc [email protected]

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Zhao Heming <[email protected]>

Signed-off-by Song Liu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/md.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/md/md.c +1 -2

index 368cad6cd53a..464cca5d5952 100644
@@ -7821,8 +7821,7 @@ static int md_open(struct block_device *bdev, fmode_t mode)
 		/* Wait until bdev->bd_disk is definitely gone */
 		if (work_pending(&mddev->del_work))
 			flush_workqueue(md_misc_wq);
-		/* Then retry the open from the top */
-		return -ERESTARTSYS;
+		return -EBUSY;
 	}
 	BUG_ON(mddev != bdev->bd_disk->private_data);

Signature · 1 line

2.31.1

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #86 lore raw

PATCH 86/240 ALSA: hda/realtek: Re-order ALC882 Acer quirk table entries

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit b265047ac56bad8c4f3d0c8bf9cb4e828ee0d28e upstream.

Just re-order the alc882_fixup_tbl[] entries for Acer devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes.

Also Cc-to-stable for the further patch applications.

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

sound/pci/hda/patch_realtek.c +3 -3

@@ -2219,13 +2219,13 @@ static const struct snd_pci_quirk alc882
 		      ALC882_FIXUP_ACER_ASPIRE_8930G),
 	SND_PCI_QUIRK(0x1025, 0x0146, "Acer Aspire 6935G",
 		      ALC882_FIXUP_ACER_ASPIRE_8930G),
+	SND_PCI_QUIRK(0x1025, 0x0142, "Acer Aspire 7730G",
+		      ALC882_FIXUP_ACER_ASPIRE_4930G),
+	SND_PCI_QUIRK(0x1025, 0x0155, "Packard-Bell M5120", ALC882_FIXUP_PB_M5210),
 	SND_PCI_QUIRK(0x1025, 0x015e, "Acer Aspire 6930G",
 		      ALC882_FIXUP_ACER_ASPIRE_4930G),
 	SND_PCI_QUIRK(0x1025, 0x0166, "Acer Aspire 6530G",
 		      ALC882_FIXUP_ACER_ASPIRE_4930G),
-	SND_PCI_QUIRK(0x1025, 0x0142, "Acer Aspire 7730G",
-		      ALC882_FIXUP_ACER_ASPIRE_4930G),
-	SND_PCI_QUIRK(0x1025, 0x0155, "Packard-Bell M5120", ALC882_FIXUP_PB_M5210),
 	SND_PCI_QUIRK(0x1025, 0x021e, "Acer Aspire 5739G",
 		      ALC882_FIXUP_ACER_ASPIRE_4930G),
 	SND_PCI_QUIRK(0x1025, 0x0259, "Acer Aspire 5935", ALC889_FIXUP_DAC_ROUTE),

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #85 lore raw

PATCH 85/240 drm/radeon: fix copy of uninitialized variable back to userspace

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

commit 8dbc2ccac5a65c5b57e3070e36a3dc97c7970d96 upstream.

Currently the ioctl command RADEON_INFO_SI_BACKEND_ENABLED_MASK can copy back uninitialised data in value_tmp that pointer *value points to. This can occur when rdev->family is less than CHIP_BONAIRE and less than CHIP_TAHITI. Fix this by adding in a missing -EINVAL so that no invalid value is copied back to userspace.

Addresses-Coverity: ("Uninitialized scalar variable)

Cc [email protected] # 3.13+

Fixes 439a1cfffe2c ("drm/radeon: expose render backend mask to the userspace")

Reviewed-by Christian König <[email protected]>

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Alex Deucher <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/radeon/radeon_kms.c |    1 +
 1 file changed, 1 insertion(+)

drivers/gpu/drm/radeon/radeon_kms.c +1 -0

@@ -506,6 +506,7 @@ static int radeon_info_ioctl(struct drm_
 			*value = rdev->config.si.backend_enable_mask;
 		} else {
 			DRM_DEBUG_KMS("BACKEND_ENABLED_MASK is si+ only!\n");
+			return -EINVAL;
 		}
 		break;
 	case RADEON_INFO_MAX_SCLK:

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #84 lore raw

PATCH 84/240 cfg80211: scan: drop entry from hidden_list on overflow

In reply to Greg Kroah-Hartman

From: Johannes Berg <[email protected]>

commit 010bfbe768f7ecc876ffba92db30432de4997e2a upstream.

If we overflow the maximum number of BSS entries and free the new entry, drop it from any hidden_list that it may have been added to in the code above or in cfg80211_combine_bsses().

Reported-by Dan Carpenter <[email protected]>

Link https://lore.kernel.org/r/20210416094212.5de7d1676ad7.Ied283b0bc5f504845e7d6ab90626bdfa68bb3dc0@changeid open here

Cc [email protected]

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/wireless/scan.c |    2 ++
 1 file changed, 2 insertions(+)

net/wireless/scan.c +2 -0

@@ -956,6 +956,8 @@ cfg80211_bss_update(struct cfg80211_regi
 
 		if (rdev->bss_entries >= bss_entries_limit &&
 		    !cfg80211_bss_expire_oldest(rdev)) {
+			if (!list_empty(&new->hidden_list))
+				list_del(&new->hidden_list);
 			kfree(new);
 			goto drop;
 		}

Greg Kroah-Hartman

author maintainer

2021-05-20 10:51 UTC #83 lore raw

PATCH 83/240 ipw2x00: potential buffer overflow in libipw_wx_set_encodeext()

In reply to Greg Kroah-Hartman

From: Dan Carpenter <[email protected]>

commit 260a9ad9446723d4063ed802989758852809714d upstream.

The "ext->key_len" is a u16 that comes from the user. If it's over SCM_KEY_LEN (32) that could lead to memory corruption.

Fixes e0d369d1d969 ("[PATCH] ieee82011: Added WE-18 support to default wireless extension handler")

Cc [email protected]

Signed-off-by Dan Carpenter <[email protected]>

Acked-by Stanislav Yakovlev <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/YHaoA1i+8uT4ir4h@mwanda open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/intel/ipw2x00/libipw_wx.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/net/wireless/intel/ipw2x00/libipw_wx.c +4 -2

@@ -649,8 +649,10 @@ int libipw_wx_set_encodeext(struct libip
 	}
 
 	if (ext->alg != IW_ENCODE_ALG_NONE) {
-		memcpy(sec.keys[idx], ext->key, ext->key_len);
-		sec.key_sizes[idx] = ext->key_len;
+		int key_len = clamp_val(ext->key_len, 0, SCM_KEY_LEN);
+
+		memcpy(sec.keys[idx], ext->key, key_len);
+		sec.key_sizes[idx] = key_len;
 		sec.flags |= (1 << idx);
 		if (ext->alg == IW_ENCODE_ALG_WEP) {
 			sec.encode_alg[idx] = SEC_ALG_WEP;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:52 UTC #87 lore raw

PATCH 87/240 ALSA: hda/realtek: Re-order ALC882 Sony quirk table entries

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit b7529c18feecb1af92f9db08c8e7fe446a82d96d upstream.

Just re-order the alc882_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes.

Also Cc-to-stable for the further patch applications.

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/pci/hda/patch_realtek.c +2 -2

@@ -2237,11 +2237,11 @@ static const struct snd_pci_quirk alc882
 	SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601),
 	SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS),
 	SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII", ALC882_FIXUP_GPIO3),
+	SND_PCI_QUIRK(0x104d, 0x9043, "Sony Vaio VGC-LN51JGB", ALC882_FIXUP_NO_PRIMARY_HP),
+	SND_PCI_QUIRK(0x104d, 0x9044, "Sony VAIO AiO", ALC882_FIXUP_NO_PRIMARY_HP),
 	SND_PCI_QUIRK(0x104d, 0x9047, "Sony Vaio TT", ALC889_FIXUP_VAIO_TT),
 	SND_PCI_QUIRK(0x104d, 0x905a, "Sony Vaio Z", ALC882_FIXUP_NO_PRIMARY_HP),
 	SND_PCI_QUIRK(0x104d, 0x9060, "Sony Vaio VPCL14M1R", ALC882_FIXUP_NO_PRIMARY_HP),
-	SND_PCI_QUIRK(0x104d, 0x9043, "Sony Vaio VGC-LN51JGB", ALC882_FIXUP_NO_PRIMARY_HP),
-	SND_PCI_QUIRK(0x104d, 0x9044, "Sony VAIO AiO", ALC882_FIXUP_NO_PRIMARY_HP),
 
 	/* All Apple entries are in codec SSIDs */
 	SND_PCI_QUIRK(0x106b, 0x00a0, "MacBookPro 3,1", ALC889_FIXUP_MBP_VREF),

Greg Kroah-Hartman

author maintainer

2021-05-20 10:52 UTC #71 lore raw

PATCH 71/240 net/nfc: fix use-after-free llcp_sock_bind/connect

In reply to Greg Kroah-Hartman

From: Or Cohen <[email protected]>

commit c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6 upstream.

Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets.

This can be triggered by the following simple program:

    int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );
    int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );
    memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) );
    addr.sa_family = AF_NFC;
    addr.nfc_protocol = NFC_PROTO_NFC_DEP;
    bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) )
    bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) )
    close(sock1);
    close(sock2);

Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put.

This addresses CVE-2021-23134.

Reported-by Or Cohen <[email protected]>

Reported-by Nadav Markus <[email protected]>

Fixes c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()")

Signed-off-by Or Cohen <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/nfc/llcp_sock.c |    4 ++++
 1 file changed, 4 insertions(+)

net/nfc/llcp_sock.c +4 -0

@@ -120,12 +120,14 @@ static int llcp_sock_bind(struct socket
 					  GFP_KERNEL);
 	if (!llcp_sock->service_name) {
 		nfc_llcp_local_put(llcp_sock->local);
+		llcp_sock->local = NULL;
 		ret = -ENOMEM;
 		goto put_dev;
 	}
 	llcp_sock->ssap = nfc_llcp_get_sdp_ssap(local, llcp_sock);
 	if (llcp_sock->ssap == LLCP_SAP_MAX) {
 		nfc_llcp_local_put(llcp_sock->local);
+		llcp_sock->local = NULL;
 		kfree(llcp_sock->service_name);
 		llcp_sock->service_name = NULL;
 		ret = -EADDRINUSE;

@@ -721,6 +723,7 @@ static int llcp_sock_connect(struct sock
 	llcp_sock->ssap = nfc_llcp_get_local_ssap(local);
 	if (llcp_sock->ssap == LLCP_SAP_MAX) {
 		nfc_llcp_local_put(llcp_sock->local);
+		llcp_sock->local = NULL;
 		ret = -ENOMEM;
 		goto put_dev;
 	}

@@ -759,6 +762,7 @@ static int llcp_sock_connect(struct sock
 sock_unlink:
 	nfc_llcp_put_ssap(local, llcp_sock->ssap);
 	nfc_llcp_local_put(llcp_sock->local);
+	llcp_sock->local = NULL;
 
 	nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
 	kfree(llcp_sock->service_name);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:52 UTC #88 lore raw

PATCH 88/240 ALSA: hda/realtek: Re-order ALC269 Sony quirk table entries

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit cab561f8d4bc9b196ae20c960aa5da89fd786ab5 upstream.

Just re-order the alc269_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes.

Also Cc-to-stable for the further patch applications.

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/pci/hda/patch_realtek.c +2 -2

@@ -5821,12 +5821,12 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x1043, 0x8398, "ASUS P1005", ALC269_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005", ALC269_FIXUP_STEREO_DMIC),
 	SND_PCI_QUIRK(0x1043, 0x8516, "ASUS X101CH", ALC269_FIXUP_ASUS_X101),
-	SND_PCI_QUIRK(0x104d, 0x90b5, "Sony VAIO Pro 11", ALC286_FIXUP_SONY_MIC_NO_PRESENCE),
-	SND_PCI_QUIRK(0x104d, 0x90b6, "Sony VAIO Pro 13", ALC286_FIXUP_SONY_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x104d, 0x9073, "Sony VAIO", ALC275_FIXUP_SONY_VAIO_GPIO2),
 	SND_PCI_QUIRK(0x104d, 0x907b, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ),
 	SND_PCI_QUIRK(0x104d, 0x9084, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ),
 	SND_PCI_QUIRK(0x104d, 0x9099, "Sony VAIO S13", ALC275_FIXUP_SONY_DISABLE_AAMIX),
+	SND_PCI_QUIRK(0x104d, 0x90b5, "Sony VAIO Pro 11", ALC286_FIXUP_SONY_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0x104d, 0x90b6, "Sony VAIO Pro 13", ALC286_FIXUP_SONY_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x10cf, 0x1475, "Lifebook", ALC269_FIXUP_LIFEBOOK),
 	SND_PCI_QUIRK(0x10cf, 0x159f, "Lifebook E780", ALC269_FIXUP_LIFEBOOK_NO_HP_TO_LINEOUT),
 	SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", ALC269_FIXUP_LIFEBOOK_HP_PIN),

Greg Kroah-Hartman

author maintainer

2021-05-20 10:52 UTC #89 lore raw

PATCH 89/240 ALSA: hda/realtek: Re-order ALC269 Lenovo quirk table entries

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit f552ff54c2a700616a02b038e4bf3cbf859f65b7 upstream.

Just re-order the alc269_fixup_tbl[] entries for Lenovo devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes.

Also Cc-to-stable for the further patch applications.

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/pci/hda/patch_realtek.c +2 -2

@@ -5841,9 +5841,9 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x17aa, 0x21b8, "Thinkpad Edge 14", ALC269_FIXUP_SKU_IGNORE),
 	SND_PCI_QUIRK(0x17aa, 0x21ca, "Thinkpad L412", ALC269_FIXUP_SKU_IGNORE),
 	SND_PCI_QUIRK(0x17aa, 0x21e9, "Thinkpad Edge 15", ALC269_FIXUP_SKU_IGNORE),
+	SND_PCI_QUIRK(0x17aa, 0x21f3, "Thinkpad T430", ALC269_FIXUP_LENOVO_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x21f6, "Thinkpad T530", ALC269_FIXUP_LENOVO_DOCK_LIMIT_BOOST),
 	SND_PCI_QUIRK(0x17aa, 0x21fa, "Thinkpad X230", ALC269_FIXUP_LENOVO_DOCK),
-	SND_PCI_QUIRK(0x17aa, 0x21f3, "Thinkpad T430", ALC269_FIXUP_LENOVO_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x21fb, "Thinkpad T430s", ALC269_FIXUP_LENOVO_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet", ALC269_FIXUP_LENOVO_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x2208, "Thinkpad T431s", ALC269_FIXUP_LENOVO_DOCK),

@@ -5875,6 +5875,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
 	SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
 	SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo B50-70", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
+	SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
 	SND_PCI_QUIRK(0x17aa, 0x5013, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x17aa, 0x501a, "Thinkpad", ALC283_FIXUP_INT_MIC),
 	SND_PCI_QUIRK(0x17aa, 0x501e, "Thinkpad L440", ALC292_FIXUP_TPT440_DOCK),

@@ -5893,7 +5894,6 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x17aa, 0x5109, "Thinkpad", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x17aa, 0x511e, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
 	SND_PCI_QUIRK(0x17aa, 0x511f, "Thinkpad", ALC298_FIXUP_TPT470_DOCK),
-	SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
 	SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
 	SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #90 lore raw

PATCH 90/240 ALSA: hda/realtek: Remove redundant entry for ALC861 Haier/Uniwill devices

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit defce244b01ee12534910a4544e11be5eb927d25 upstream.

The quirk entry for Uniwill ECS M31EI is with the PCI SSID device 0, which means matching with all. That is, it's essentially equivalent with SND_PCI_QUIRK_VENDOR(0x1584), which also matches with the previous entry for Haier W18 applying the very same quirk.

Let's unify them with the single vendor-quirk entry.

Cc <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

sound/pci/hda/patch_realtek.c +1 -2

@@ -6569,8 +6569,7 @@ static const struct snd_pci_quirk alc861
 	SND_PCI_QUIRK(0x1043, 0x1393, "ASUS A6Rp", ALC861_FIXUP_ASUS_A6RP),
 	SND_PCI_QUIRK_VENDOR(0x1043, "ASUS laptop", ALC861_FIXUP_AMP_VREF_0F),
 	SND_PCI_QUIRK(0x1462, 0x7254, "HP DX2200", ALC861_FIXUP_NO_JACK_DETECT),
-	SND_PCI_QUIRK(0x1584, 0x2b01, "Haier W18", ALC861_FIXUP_AMP_VREF_0F),
-	SND_PCI_QUIRK(0x1584, 0x0000, "Uniwill ECS M31EI", ALC861_FIXUP_AMP_VREF_0F),
+	SND_PCI_QUIRK_VENDOR(0x1584, "Haier/Uniwill", ALC861_FIXUP_AMP_VREF_0F),
 	SND_PCI_QUIRK(0x1734, 0x10c7, "FSC Amilo Pi1505", ALC861_FIXUP_FSC_AMILO_PI1505),
 	{}
 };

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #91 lore raw

PATCH 91/240 usb: gadget: pch_udc: Revert d3cb25a12138 completely

In reply to Greg Kroah-Hartman

From: Andy Shevchenko <[email protected]>

commit 50a318cc9b54a36f00beadf77e578a50f3620477 upstream.

The commit d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") obviously was not thought through and had made the situation even worse than it was before. Two changes after almost reverted it. but a few leftovers have been left as it. With this revert d3cb25a12138 completely.

While at it, narrow down the scope of unlocked section to prevent potential race when prot_stall is assigned.

Fixes d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc")

Fixes 9903b6bedd38 ("usb: gadget: pch-udc: fix lock")

Fixes 1d23d16a88e6 ("usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock")

Cc Iago Abal <[email protected]>

Signed-off-by Andy Shevchenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/udc/pch_udc.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

drivers/usb/gadget/udc/pch_udc.c +13 -4

@@ -604,18 +604,22 @@ static void pch_udc_reconnect(struct pch
 static inline void pch_udc_vbus_session(struct pch_udc_dev *dev,
 					  int is_active)
 {
+	unsigned long		iflags;
+
+	spin_lock_irqsave(&dev->lock, iflags);
 	if (is_active) {
 		pch_udc_reconnect(dev);
 		dev->vbus_session = 1;
 	} else {
 		if (dev->driver && dev->driver->disconnect) {
-			spin_lock(&dev->lock);
+			spin_unlock_irqrestore(&dev->lock, iflags);
 			dev->driver->disconnect(&dev->gadget);
-			spin_unlock(&dev->lock);
+			spin_lock_irqsave(&dev->lock, iflags);
 		}
 		pch_udc_set_disconnect(dev);
 		dev->vbus_session = 0;
 	}
+	spin_unlock_irqrestore(&dev->lock, iflags);
 }
 
 /**

@@ -1172,20 +1176,25 @@ static int pch_udc_pcd_selfpowered(struc
 static int pch_udc_pcd_pullup(struct usb_gadget *gadget, int is_on)
 {
 	struct pch_udc_dev	*dev;
+	unsigned long		iflags;
 
 	if (!gadget)
 		return -EINVAL;
+
 	dev = container_of(gadget, struct pch_udc_dev, gadget);
+
+	spin_lock_irqsave(&dev->lock, iflags);
 	if (is_on) {
 		pch_udc_reconnect(dev);
 	} else {
 		if (dev->driver && dev->driver->disconnect) {
-			spin_lock(&dev->lock);
+			spin_unlock_irqrestore(&dev->lock, iflags);
 			dev->driver->disconnect(&dev->gadget);
-			spin_unlock(&dev->lock);
+			spin_lock_irqsave(&dev->lock, iflags);
 		}
 		pch_udc_set_disconnect(dev);
 	}
+	spin_unlock_irqrestore(&dev->lock, iflags);
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #94 lore raw

PATCH 94/240 ARM: dts: exynos: correct PMIC interrupt trigger level on Snow

In reply to Greg Kroah-Hartman

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit 8987efbb17c2522be8615085df9a14da2ab53d34 ]

The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware.

Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races.

Fixes c61248afa819 ("ARM: dts: Add max77686 RTC interrupt to cros5250-common")

Signed-off-by Krzysztof Kozlowski <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/exynos5250-snow-common.dtsi +1 -1

index d5d51916bb74..b24a77781e75 100644
@@ -280,7 +280,7 @@
 	max77686: max77686@09 {
 		compatible = "maxim,max77686";
 		interrupt-parent = <&gpx3>;
-		interrupts = <2 IRQ_TYPE_NONE>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&max77686_irq>;
 		wakeup-source;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #92 lore raw

PATCH 92/240 memory: gpmc: fix out of bounds read and dereference on gpmc_cs[]

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit e004c3e67b6459c99285b18366a71af467d869f5 ]

Currently the array gpmc_cs is indexed by cs before it cs is range checked and the pointer read from this out-of-index read is dereferenced. Fix this by performing the range check on cs before the read and the following pointer dereference.

Addresses-Coverity: ("Negative array index read")

Fixes 9ed7a776eb50 ("ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select")

Signed-off-by Colin Ian King <[email protected]>

Reviewed-by Tony Lindgren <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/memory/omap-gpmc.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/memory/omap-gpmc.c +5 -2

index a9d47c06f80f..4af2f5b231dd 100644
@@ -1028,8 +1028,8 @@ EXPORT_SYMBOL(gpmc_cs_request);
 
 void gpmc_cs_free(int cs)
 {
-	struct gpmc_cs_data *gpmc = &gpmc_cs[cs];
-	struct resource *res = &gpmc->mem;
+	struct gpmc_cs_data *gpmc;
+	struct resource *res;
 
 	spin_lock(&gpmc_mem_lock);
 	if (cs >= gpmc_cs_num || cs < 0 || !gpmc_cs_reserved(cs)) {

@@ -1038,6 +1038,9 @@ void gpmc_cs_free(int cs)
 		spin_unlock(&gpmc_mem_lock);
 		return;
 	}
+	gpmc = &gpmc_cs[cs];
+	res = &gpmc->mem;
+
 	gpmc_cs_disable_mem(cs);
 	if (res->flags)
 		release_resource(res);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #93 lore raw

PATCH 93/240 ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250

In reply to Greg Kroah-Hartman

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit f6368c60561370e4a92fac22982a3bd656172170 ]

Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races.

Fixes 47580e8d94c2 ("ARM: dts: Specify MAX77686 pmic interrupt for exynos5250-smdk5250")

Signed-off-by Krzysztof Kozlowski <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/exynos5250-smdk5250.dts +1 -1

index a97a785ccc6b..f0906d67a107 100644
@@ -134,7 +134,7 @@
 		compatible = "maxim,max77686";
 		reg = <0x09>;
 		interrupt-parent = <&gpx3>;
-		interrupts = <2 IRQ_TYPE_NONE>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&max77686_irq>;
 		wakeup-source;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #95 lore raw

PATCH 95/240 serial: stm32: fix incorrect characters on console

In reply to Greg Kroah-Hartman

From: Erwan Le Ray <[email protected]>

[ Upstream commit f264c6f6aece81a9f8fbdf912b20bd3feb476a7a ]

Incorrect characters are observed on console during boot. This issue occurs when init/main.c is modifying termios settings to open /dev/console on the rootfs.

This patch adds a waiting loop in set_termios to wait for TX shift register empty (and TX FIFO if any) before stopping serial port.

Fixes 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")

Signed-off-by Erwan Le Ray <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/tty/serial/stm32-usart.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

drivers/tty/serial/stm32-usart.c +11 -1

index ea8b591dd46f..f325019887b2 100644
@@ -476,8 +476,9 @@ static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
 	unsigned int baud;
 	u32 usartdiv, mantissa, fraction, oversampling;
 	tcflag_t cflag = termios->c_cflag;
-	u32 cr1, cr2, cr3;
+	u32 cr1, cr2, cr3, isr;
 	unsigned long flags;
+	int ret;
 
 	if (!stm32_port->hw_flow_control)
 		cflag &= ~CRTSCTS;

@@ -486,6 +487,15 @@ static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
 
 	spin_lock_irqsave(&port->lock, flags);
 
+	ret = readl_relaxed_poll_timeout_atomic(port->membase + ofs->isr,
+						isr,
+						(isr & USART_SR_TC),
+						10, 100000);
+
+	/* Send the TC error message only when ISR_TC is not set. */
+	if (ret)
+		dev_err(port->dev, "Transmission is not complete\n");
+
 	/* Stop serial port and reset value */
 	writel_relaxed(0, port->membase + ofs->cr1);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #96 lore raw

PATCH 96/240 usb: gadget: pch_udc: Replace cpu_to_le32() by lower_32_bits()

In reply to Greg Kroah-Hartman

From: Andy Shevchenko <[email protected]>

[ Upstream commit 91356fed6afd1c83bf0d3df1fc336d54e38f0458 ]

Either way ~0 will be in the correct byte order, hence replace cpu_to_le32() by lower_32_bits(). Moreover, it makes sparse happy, otherwise it complains:

.../pch_udc.c:1813:27: warning: incorrect type in assignment (different base types)
.../pch_udc.c:1813:27: expected unsigned int [usertype] dataptr
.../pch_udc.c:1813:27: got restricted __le32 [usertype]

Fixes f646cf94520e ("USB device driver of Topcliff PCH")

Signed-off-by Andy Shevchenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/pch_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/gadget/udc/pch_udc.c +1 -1

index fe0887578117..b143830285f6 100644
@@ -1786,7 +1786,7 @@ static struct usb_request *pch_udc_alloc_request(struct usb_ep *usbep,
 	}
 	/* prevent from using desc. - set HOST BUSY */
 	dma_desc->status |= PCH_UDC_BS_HST_BSY;
-	dma_desc->dataptr = cpu_to_le32(DMA_ADDR_INVALID);
+	dma_desc->dataptr = lower_32_bits(DMA_ADDR_INVALID);
 	req->td_data = dma_desc;
 	req->td_data_last = dma_desc;
 	req->chain_len = 1;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #100 lore raw

PATCH 100/240 crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init

In reply to Greg Kroah-Hartman

From: Tong Zhang <[email protected]>

[ Upstream commit 8609f5cfdc872fc3a462efa6a3eca5cb1e2f6446 ]

ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue.
To fix this issue, only set this flag if adf_dev_init() returns 0.

[    7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0
[    7.180345] Call Trace:
[    7.182576]  mutex_lock+0xc9/0xd0
[    7.183257]  adf_iov_putmsg+0x118/0x1a0 [intel_qat]
[    7.183541]  adf_vf2pf_shutdown+0x4d/0x7b [intel_qat]
[    7.183834]  adf_dev_shutdown+0x172/0x2b0 [intel_qat]
[    7.184127]  adf_probe+0x5e9/0x600 [qat_dh895xccvf]

Signed-off-by Tong Zhang <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Fixes 25c6ffb249f6 ("crypto: qat - check if PF is running")

Acked-by Giovanni Cabiddu <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/qat/qat_c3xxxvf/adf_drv.c    | 4 ++--
 drivers/crypto/qat/qat_c62xvf/adf_drv.c     | 4 ++--
 drivers/crypto/qat/qat_dh895xccvf/adf_drv.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

drivers/crypto/qat/qat_c3xxxvf/adf_drv.c +2 -2

index 0dd8d2dc2ec1..26931325dfa2 100644
@@ -238,12 +238,12 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ret)
 		goto out_err_free_reg;
 
-	set_bit(ADF_STATUS_PF_RUNNING, &accel_dev->status);
-
 	ret = adf_dev_init(accel_dev);
 	if (ret)
 		goto out_err_dev_shutdown;
 
+	set_bit(ADF_STATUS_PF_RUNNING, &accel_dev->status);
+
 	ret = adf_dev_start(accel_dev);
 	if (ret)
 		goto out_err_dev_stop;

drivers/crypto/qat/qat_c62xvf/adf_drv.c +2 -2

index cd9e63468b18..722a06aac9fa 100644
@@ -238,12 +238,12 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ret)
 		goto out_err_free_reg;
 
-	set_bit(ADF_STATUS_PF_RUNNING, &accel_dev->status);
-
 	ret = adf_dev_init(accel_dev);
 	if (ret)
 		goto out_err_dev_shutdown;
 
+	set_bit(ADF_STATUS_PF_RUNNING, &accel_dev->status);
+
 	ret = adf_dev_start(accel_dev);
 	if (ret)
 		goto out_err_dev_stop;

drivers/crypto/qat/qat_dh895xccvf/adf_drv.c +2 -2

index 15de9cbed3bf..cc3f5171a523 100644
@@ -238,12 +238,12 @@ static int adf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ret)
 		goto out_err_free_reg;
 
-	set_bit(ADF_STATUS_PF_RUNNING, &accel_dev->status);
-
 	ret = adf_dev_init(accel_dev);
 	if (ret)
 		goto out_err_dev_shutdown;
 
+	set_bit(ADF_STATUS_PF_RUNNING, &accel_dev->status);
+
 	ret = adf_dev_start(accel_dev);
 	if (ret)
 		goto out_err_dev_stop;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #101 lore raw

PATCH 101/240 fotg210-udc: Fix DMA on EP0 for length > max packet size

In reply to Greg Kroah-Hartman

From: Fabian Vogt <[email protected]>

[ Upstream commit 755915fc28edfc608fa89a163014acb2f31c1e19 ]

For a 75 Byte request, it would send the first 64 separately, then detect that the remaining 11 Byte fit into a single DMA, but due to this bug set the length to the original 75 Bytes. This leads to a DMA failure (which is ignored...) and the request completes without the remaining bytes having been sent.

Fixes b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")

Signed-off-by Fabian Vogt <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/fotg210-udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/gadget/udc/fotg210-udc.c +1 -1

index 76e991557116..7831c556a40b 100644
@@ -348,7 +348,7 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
 		if (req->req.length - req->req.actual > ep->ep.maxpacket)
 			length = ep->ep.maxpacket;
 		else
-			length = req->req.length;
+			length = req->req.length - req->req.actual;
 	}
 
 	d = dma_map_single(NULL, buffer, length,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:53 UTC #99 lore raw

PATCH 99/240 crypto: qat - dont release uninitialized resources

In reply to Greg Kroah-Hartman

From: Tong Zhang <[email protected]>

[ Upstream commit b66accaab3791e15ac99c92f236d0d3a6d5bd64e ]

adf_vf_isr_resource_alloc() is not unwinding correctly when error happens and it want to release uninitialized resources. To fix this, only release initialized resources.

[    1.792845] Trying to free already-free IRQ 11
[    1.793091] WARNING: CPU: 0 PID: 182 at kernel/irq/manage.c:1821 free_irq+0x202/0x380
[    1.801340] Call Trace:
[    1.801477]  adf_vf_isr_resource_free+0x32/0xb0 [intel_qat]
[    1.801785]  adf_vf_isr_resource_alloc+0x14d/0x150 [intel_qat]
[    1.802105]  adf_dev_init+0xba/0x140 [intel_qat]

Signed-off-by Tong Zhang <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Fixes dd0f368398ea ("crypto: qat - Add qat dh895xcc VF driver")

Acked-by Giovanni Cabiddu <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/qat/qat_common/adf_vf_isr.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

drivers/crypto/qat/qat_common/adf_vf_isr.c +13 -4

index bf99e11a3403..4c1217ba83ae 100644
@@ -304,17 +304,26 @@ int adf_vf_isr_resource_alloc(struct adf_accel_dev *accel_dev)
 		goto err_out;
 
 	if (adf_setup_pf2vf_bh(accel_dev))
-		goto err_out;
+		goto err_disable_msi;
 
 	if (adf_setup_bh(accel_dev))
-		goto err_out;
+		goto err_cleanup_pf2vf_bh;
 
 	if (adf_request_msi_irq(accel_dev))
-		goto err_out;
+		goto err_cleanup_bh;
 
 	return 0;
+
+err_cleanup_bh:
+	adf_cleanup_bh(accel_dev);
+
+err_cleanup_pf2vf_bh:
+	adf_cleanup_pf2vf_bh(accel_dev);
+
+err_disable_msi:
+	adf_disable_msi(accel_dev);
+
 err_out:
-	adf_vf_isr_resource_free(accel_dev);
 	return -EFAULT;
 }
 EXPORT_SYMBOL_GPL(adf_vf_isr_resource_alloc);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #102 lore raw

PATCH 102/240 fotg210-udc: Fix EP0 IN requests bigger than two packets

In reply to Greg Kroah-Hartman

From: Fabian Vogt <[email protected]>

[ Upstream commit 078ba935651e149c92c41161e0322e3372cc2705 ]

For a 134 Byte packet, it sends the first two 64 Byte packets just fine, but then notice that less than a packet is remaining and call fotg210_done without actually sending the rest.

Fixes b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")

Signed-off-by Fabian Vogt <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/fotg210-udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/gadget/udc/fotg210-udc.c +1 -1

index 7831c556a40b..1eda6fc750c1 100644
@@ -827,7 +827,7 @@ static void fotg210_ep0in(struct fotg210_udc *fotg210)
 		if (req->req.length)
 			fotg210_start_dma(ep, req);
 
-		if ((req->req.length - req->req.actual) < ep->ep.maxpacket)
+		if (req->req.actual == req->req.length)
 			fotg210_done(ep, req, 0);
 	} else {
 		fotg210_set_cxdone(fotg210);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #103 lore raw

PATCH 103/240 fotg210-udc: Remove a dubious condition leading to fotg210_done

In reply to Greg Kroah-Hartman

From: Fabian Vogt <[email protected]>

[ Upstream commit c7f755b243494d6043aadcd9a2989cb157958b95 ]

When the EP0 IN request was not completed but less than a packet sent, it would complete the request successfully. That doesn't make sense and can't really happen as fotg210_start_dma always sends min(length, maxpkt) bytes.

Fixes b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")

Signed-off-by Fabian Vogt <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/fotg210-udc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/usb/gadget/udc/fotg210-udc.c +1 -2

index 1eda6fc750c1..d0a9ce7d0635 100644
@@ -385,8 +385,7 @@ static void fotg210_ep0_queue(struct fotg210_ep *ep,
 	}
 	if (ep->dir_in) { /* if IN */
 		fotg210_start_dma(ep, req);
-		if ((req->req.length == req->req.actual) ||
-		    (req->req.actual < ep->ep.maxpacket))
+		if (req->req.length == req->req.actual)
 			fotg210_done(ep, req, 0);
 	} else { /* OUT */
 		u32 value = ioread32(ep->fotg210->reg + FOTG210_DMISGR0);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #98 lore raw

PATCH 98/240 usb: gadget: pch_udc: Check for DMA mapping error

In reply to Greg Kroah-Hartman

From: Andy Shevchenko <[email protected]>

[ Upstream commit 4a28d77e359009b846951b06f7c0d8eec8dce298 ]

DMA mapping might fail, we have to check it with dma_mapping_error(). Otherwise DMA-API is not happy:

DMA-API: pch_udc 0000:02:02.4: device driver failed to check map error[device address=0x00000000027ee678] [size=64 bytes] [mapped as single]

Fixes abab0c67c061 ("usb: pch_udc: Fixed issue which does not work with g_serial")

Signed-off-by Andy Shevchenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/pch_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/gadget/udc/pch_udc.c +1 -1

index 2363e3f66647..18ce19162804 100644
@@ -2977,7 +2977,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
 	dev->dma_addr = dma_map_single(&dev->pdev->dev, ep0out_buf,
 				       UDC_EP0OUT_BUFF_SIZE * 4,
 				       DMA_FROM_DEVICE);
-	return 0;
+	return dma_mapping_error(&dev->pdev->dev, dev->dma_addr);
 }
 
 static int pch_udc_start(struct usb_gadget *g,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #104 lore raw

PATCH 104/240 fotg210-udc: Mask GRP2 interrupts we dont handle

In reply to Greg Kroah-Hartman

From: Fabian Vogt <[email protected]>

[ Upstream commit 9aee3a23d6455200702f3a57e731fa11e8408667 ]

Currently it leaves unhandled interrupts unmasked, but those are never acked. In the case of a "device idle" interrupt, this leads to an effectively frozen system until plugging it in.

Fixes b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")

Signed-off-by Fabian Vogt <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/fotg210-udc.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/usb/gadget/udc/fotg210-udc.c +6 -0

index d0a9ce7d0635..491b04dd6db7 100644
@@ -1033,6 +1033,12 @@ static void fotg210_init(struct fotg210_udc *fotg210)
 	value &= ~DMCR_GLINT_EN;
 	iowrite32(value, fotg210->reg + FOTG210_DMCR);
 
+	/* enable only grp2 irqs we handle */
+	iowrite32(~(DISGR2_DMA_ERROR | DISGR2_RX0BYTE_INT | DISGR2_TX0BYTE_INT
+		    | DISGR2_ISO_SEQ_ABORT_INT | DISGR2_ISO_SEQ_ERR_INT
+		    | DISGR2_RESM_INT | DISGR2_SUSP_INT | DISGR2_USBRST_INT),
+		  fotg210->reg + FOTG210_DMISGR2);
+
 	/* disable all fifo interrupt */
 	iowrite32(~(u32)0, fotg210->reg + FOTG210_DMISGR1);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #72 lore raw

PATCH 72/240 FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR

In reply to Greg Kroah-Hartman

From: Maciej W. Rozycki <[email protected]>

commit f626ca682912fab55dff15469ce893ae16b65c7e upstream.

Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them.

For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned:

# lspci -s 0031:02:04.0 -v
0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02)
	Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA)
	Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8
	Memory at 620c080020000 (32-bit, non-prefetchable) [size=128]
	I/O ports at <unassigned> [disabled]
	Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: defxx
	Kernel modules: defxx

Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry:

# cat /proc/ioports
00000000-ffffffffffffffff : 0031:02:04.0
#

Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like:

defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000
IPMI: dropping non severe PEL event
LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
IPMI: dropping non severe PEL event
LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
IPMI: dropping non severe PEL event

and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state:

0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00

This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it.

Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like:

defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y"

Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O.

Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like:

eisa 00:05: EISA: slot 5: DEC3002 detected
defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location

with the last two lines now swapped for easier handling in the driver.

There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway.

While at it factor out the error message calls into helpers and fix an argument order bug with the pr_err' call now in dfx_register_res_err'.

Signed-off-by Maciej W. Rozycki <[email protected]>

Fixes 4d0438e56a8f ("defxx: Clean up DEFEA resource management")

Cc [email protected] # v3.19+

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/fddi/defxx.c |   47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)

drivers/net/fddi/defxx.c +30 ~~-17~~

@@ -495,6 +495,25 @@ static const struct net_device_ops dfx_n
 	.ndo_set_mac_address	= dfx_ctl_set_mac_address,
 };
 
+static void dfx_register_res_alloc_err(const char *print_name, bool mmio,
+				       bool eisa)
+{
+	pr_err("%s: Cannot use %s, no address set, aborting\n",
+	       print_name, mmio ? "MMIO" : "I/O");
+	pr_err("%s: Recompile driver with \"CONFIG_DEFXX_MMIO=%c\"\n",
+	       print_name, mmio ? 'n' : 'y');
+	if (eisa && mmio)
+		pr_err("%s: Or run ECU and set adapter's MMIO location\n",
+		       print_name);
+}
+
+static void dfx_register_res_err(const char *print_name, bool mmio,
+				 unsigned long start, unsigned long len)
+{
+	pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, aborting\n",
+	       print_name, mmio ? "MMIO" : "I/O", len, start);
+}
+
 /*
  * ================
  * = dfx_register =

@@ -568,15 +587,12 @@ static int dfx_register(struct device *b
 	dev_set_drvdata(bdev, dev);
 
 	dfx_get_bars(bdev, bar_start, bar_len);
-	if (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0) {
-		pr_err("%s: Cannot use MMIO, no address set, aborting\n",
-		       print_name);
-		pr_err("%s: Run ECU and set adapter's MMIO location\n",
-		       print_name);
-		pr_err("%s: Or recompile driver with \"CONFIG_DEFXX_MMIO=n\""
-		       "\n", print_name);
+	if (bar_len[0] == 0 ||
+	    (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0)) {
+		dfx_register_res_alloc_err(print_name, dfx_use_mmio,
+					   dfx_bus_eisa);
 		err = -ENXIO;
-		goto err_out;
+		goto err_out_disable;
 	}
 
 	if (dfx_use_mmio)

@@ -585,18 +601,16 @@ static int dfx_register(struct device *b
 	else
 		region = request_region(bar_start[0], bar_len[0], print_name);
 	if (!region) {
-		pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, "
-		       "aborting\n", dfx_use_mmio ? "MMIO" : "I/O", print_name,
-		       (long)bar_len[0], (long)bar_start[0]);
+		dfx_register_res_err(print_name, dfx_use_mmio,
+				     bar_start[0], bar_len[0]);
 		err = -EBUSY;
 		goto err_out_disable;
 	}
 	if (bar_start[1] != 0) {
 		region = request_region(bar_start[1], bar_len[1], print_name);
 		if (!region) {
-			pr_err("%s: Cannot reserve I/O resource "
-			       "0x%lx @ 0x%lx, aborting\n", print_name,
-			       (long)bar_len[1], (long)bar_start[1]);
+			dfx_register_res_err(print_name, 0,
+					     bar_start[1], bar_len[1]);
 			err = -EBUSY;
 			goto err_out_csr_region;
 		}

@@ -604,9 +618,8 @@ static int dfx_register(struct device *b
 	if (bar_start[2] != 0) {
 		region = request_region(bar_start[2], bar_len[2], print_name);
 		if (!region) {
-			pr_err("%s: Cannot reserve I/O resource "
-			       "0x%lx @ 0x%lx, aborting\n", print_name,
-			       (long)bar_len[2], (long)bar_start[2]);
+			dfx_register_res_err(print_name, 0,
+					     bar_start[2], bar_len[2]);
 			err = -EBUSY;
 			goto err_out_bh_region;
 		}

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #97 lore raw

PATCH 97/240 usb: gadget: pch_udc: Check if driver is present before calling ->setup()

In reply to Greg Kroah-Hartman

From: Andy Shevchenko <[email protected]>

[ Upstream commit fbdbbe6d3ee502b3bdeb4f255196bb45003614be ]

Since we have a separate routine for VBUS sense, the interrupt may occur before gadget driver is present. Hence, ->setup() call may oops the kernel:

[   55.245843] BUG: kernel NULL pointer dereference, address: 00000010
...
[   55.245843] EIP: pch_udc_isr.cold+0x162/0x33f
...
[   55.245843]  <IRQ>
[   55.245843]  ? pch_udc_svc_data_out+0x160/0x160

Check if driver is present before calling ->setup().

Fixes f646cf94520e ("USB device driver of Topcliff PCH")

Signed-off-by Andy Shevchenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/pch_udc.c | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

drivers/usb/gadget/udc/pch_udc.c +18 ~~-10~~

index b143830285f6..2363e3f66647 100644
@@ -2329,6 +2329,21 @@ static void pch_udc_svc_data_out(struct pch_udc_dev *dev, int ep_num)
 		pch_udc_set_dma(dev, DMA_DIR_RX);
 }
 
+static int pch_udc_gadget_setup(struct pch_udc_dev *dev)
+	__must_hold(&dev->lock)
+{
+	int rc;
+
+	/* In some cases we can get an interrupt before driver gets setup */
+	if (!dev->driver)
+		return -ESHUTDOWN;
+
+	spin_unlock(&dev->lock);
+	rc = dev->driver->setup(&dev->gadget, &dev->setup_data);
+	spin_lock(&dev->lock);
+	return rc;
+}
+
 /**
  * pch_udc_svc_control_in() - Handle Control IN endpoint interrupts
  * @dev:	Reference to the device structure

@@ -2400,15 +2415,12 @@ static void pch_udc_svc_control_out(struct pch_udc_dev *dev)
 			dev->gadget.ep0 = &dev->ep[UDC_EP0IN_IDX].ep;
 		else /* OUT */
 			dev->gadget.ep0 = &ep->ep;
-		spin_lock(&dev->lock);
 		/* If Mass storage Reset */
 		if ((dev->setup_data.bRequestType == 0x21) &&
 		    (dev->setup_data.bRequest == 0xFF))
 			dev->prot_stall = 0;
 		/* call gadget with setup data received */
-		setup_supported = dev->driver->setup(&dev->gadget,
-						     &dev->setup_data);
-		spin_unlock(&dev->lock);
+		setup_supported = pch_udc_gadget_setup(dev);
 
 		if (dev->setup_data.bRequestType & USB_DIR_IN) {
 			ep->td_data->status = (ep->td_data->status &

@@ -2656,9 +2668,7 @@ static void pch_udc_svc_intf_interrupt(struct pch_udc_dev *dev)
 		dev->ep[i].halted = 0;
 	}
 	dev->stall = 0;
-	spin_unlock(&dev->lock);
-	dev->driver->setup(&dev->gadget, &dev->setup_data);
-	spin_lock(&dev->lock);
+	pch_udc_gadget_setup(dev);
 }
 
 /**

@@ -2693,9 +2703,7 @@ static void pch_udc_svc_cfg_interrupt(struct pch_udc_dev *dev)
 	dev->stall = 0;
 
 	/* call gadget zero with setup data received */
-	spin_unlock(&dev->lock);
-	dev->driver->setup(&dev->gadget, &dev->setup_data);
-	spin_lock(&dev->lock);
+	pch_udc_gadget_setup(dev);
 }
 
 /**

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #105 lore raw

PATCH 105/240 fotg210-udc: Dont DMA more than the buffer can take

In reply to Greg Kroah-Hartman

From: Fabian Vogt <[email protected]>

[ Upstream commit 3e7c2510bdfe89a9ec223dd7acd6bfc8bb1cbeb6 ]

Before this, it wrote as much as available into the buffer, even if it didn't fit.

Fixes b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")

Signed-off-by Fabian Vogt <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/fotg210-udc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/usb/gadget/udc/fotg210-udc.c +3 -2

index 491b04dd6db7..b2910bc65e51 100644
@@ -340,8 +340,9 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
 		} else {
 			buffer = req->req.buf + req->req.actual;
 			length = ioread32(ep->fotg210->reg +
-					FOTG210_FIBCR(ep->epnum - 1));
-			length &= FIBCR_BCFX;
+					FOTG210_FIBCR(ep->epnum - 1)) & FIBCR_BCFX;
+			if (length > req->req.length - req->req.actual)
+				length = req->req.length - req->req.actual;
 		}
 	} else {
 		buffer = req->req.buf + req->req.actual;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #106 lore raw

PATCH 106/240 fotg210-udc: Complete OUT requests on short packets

In reply to Greg Kroah-Hartman

From: Fabian Vogt <[email protected]>

[ Upstream commit 75bb93be0027123b5db6cbcce89eb62f0f6b3c5b ]

A short packet indicates the end of a transfer and marks the request as complete.

Fixes b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")

Signed-off-by Fabian Vogt <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/fotg210-udc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/usb/gadget/udc/fotg210-udc.c +6 -2

index b2910bc65e51..9e102ba9cf66 100644
@@ -856,12 +856,16 @@ static void fotg210_out_fifo_handler(struct fotg210_ep *ep)
 {
 	struct fotg210_request *req = list_entry(ep->queue.next,
 						 struct fotg210_request, queue);
+	int disgr1 = ioread32(ep->fotg210->reg + FOTG210_DISGR1);
 
 	fotg210_start_dma(ep, req);
 
-	/* finish out transfer */
+	/* Complete the request when it's full or a short packet arrived.
+	 * Like other drivers, short_not_ok isn't handled.
+	 */
+
 	if (req->req.length == req->req.actual ||
-	    req->req.actual < ep->ep.maxpacket)
+	    (disgr1 & DISGR1_SPK_INT(ep->epnum - 1)))
 		fotg210_done(ep, req, 0);
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #73 lore raw

PATCH 73/240 misc: lis3lv02d: Fix false-positive WARN on various HP models

In reply to Greg Kroah-Hartman

From: Hans de Goede <[email protected]>

commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream.

Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch a potential divide by 0. WARN macros should only be used to catch internal kernel bugs and that is not the case here. We have been receiving a lot of bug reports about kernel backtraces caused by this WARN.

The div value being checked comes from the lis3->odrs[] array. Which is sized to be a power-of-2 matching the number of bits in lis3->odr_mask.

The only lis3 model where this array is not entirely filled with non zero values. IOW the only model where we can hit the div == 0 check is the 3dc ("8 bits 3DC sensor") model:

int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000};

Note the 0 value at index 0, according to the datasheet an odr index of 0 means "Power-down mode". HP typically uses a lis3 accelerometer for HDD fall protection. What I believe is happening here is that on newer HP devices, which only contain a SDD, the BIOS is leaving the lis3 device powered-down since it is not used for HDD fall protection.

Note that the lis3_3dc_rates array initializer only specifies 10 values, which matches the datasheet. So it also contains 6 zero values at the end.

Replace the WARN with a normal check, which treats an odr index of 0 as power-down and uses a normal dev_err() to report the error in case odr index point past the initialized part of the array.

Fixes 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked")

Cc [email protected]

Signed-off-by Hans de Goede <[email protected]>

BugLink https://bugzilla.redhat.com/show_bug.cgi?id=785814

BugLink https://bugzilla.redhat.com/show_bug.cgi?id=1817027

BugLink https://bugs.centos.org/view.php?id=10720

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/lis3lv02d/lis3lv02d.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

drivers/misc/lis3lv02d/lis3lv02d.c +16 -5

@@ -220,7 +220,7 @@ static int lis3_3dc_rates[16] = {0, 1, 1
 static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
 
 /* ODR is Output Data Rate */
-static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
+static int lis3lv02d_get_odr_index(struct lis3lv02d *lis3)
 {
 	u8 ctrl;
 	int shift;

@@ -228,15 +228,23 @@ static int lis3lv02d_get_odr(struct lis3
 	lis3->read(lis3, CTRL_REG1, &ctrl);
 	ctrl &= lis3->odr_mask;
 	shift = ffs(lis3->odr_mask) - 1;
-	return lis3->odrs[(ctrl >> shift)];
+	return (ctrl >> shift);
 }
 
 static int lis3lv02d_get_pwron_wait(struct lis3lv02d *lis3)
 {
-	int div = lis3lv02d_get_odr(lis3);
+	int odr_idx = lis3lv02d_get_odr_index(lis3);
+	int div = lis3->odrs[odr_idx];
 
-	if (WARN_ONCE(div == 0, "device returned spurious data"))
+	if (div == 0) {
+		if (odr_idx == 0) {
+			/* Power-down mode, not sampling no need to sleep */
+			return 0;
+		}
+
+		dev_err(&lis3->pdev->dev, "Error unknown odrs-index: %d\n", odr_idx);
 		return -ENXIO;
+	}
 
 	/* LIS3 power on delay is quite long */
 	msleep(lis3->pwron_delay / div);

@@ -819,9 +827,12 @@ static ssize_t lis3lv02d_rate_show(struc
 			struct device_attribute *attr, char *buf)
 {
 	struct lis3lv02d *lis3 = dev_get_drvdata(dev);
+	int odr_idx;
 
 	lis3lv02d_sysfs_poweron(lis3);
-	return sprintf(buf, "%d\n", lis3lv02d_get_odr(lis3));
+
+	odr_idx = lis3lv02d_get_odr_index(lis3);
+	return sprintf(buf, "%d\n", lis3->odrs[odr_idx]);
 }
 
 static ssize_t lis3lv02d_rate_set(struct device *dev,

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #74 lore raw

PATCH 74/240 misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct

In reply to Greg Kroah-Hartman

From: Tetsuo Handa <[email protected]>

commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream.

KMSAN complains that the vmci_use_ppn64() == false path in vmci_dbell_register_notification_bitmap() left upper 32bits of bitmap_set_msg.bitmap_ppn64 member uninitialized.

=====================================================

  BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10
  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
  Call Trace:
   dump_stack+0x21c/0x280
   kmsan_report+0xfb/0x1e0
   kmsan_internal_check_memory+0x484/0x520
   kmsan_check_memory+0xd/0x10
   iowrite8_rep+0x86/0x380
   vmci_send_datagram+0x150/0x280
   vmci_dbell_register_notification_bitmap+0x133/0x1e0
   vmci_guest_probe_device+0xcab/0x1e70
   pci_device_probe+0xab3/0xe70
   really_probe+0xd16/0x24d0
   driver_probe_device+0x29d/0x3a0
   device_driver_attach+0x25a/0x490
   __driver_attach+0x78c/0x840
   bus_for_each_dev+0x210/0x340
   driver_attach+0x89/0xb0
   bus_add_driver+0x677/0xc40
   driver_register+0x485/0x8e0
   __pci_register_driver+0x1ff/0x350
   vmci_guest_init+0x3e/0x41
   vmci_drv_init+0x1d6/0x43f
   do_one_initcall+0x39c/0x9a0
   do_initcall_level+0x1d7/0x259
   do_initcalls+0x127/0x1cb
   do_basic_setup+0x33/0x36
   kernel_init_freeable+0x29a/0x3ed
   kernel_init+0x1f/0x840
   ret_from_fork+0x1f/0x30

Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at:

   vmci_dbell_register_notification_bitmap+0x50/0x1e0
   vmci_dbell_register_notification_bitmap+0x50/0x1e0

Bytes 28-31 of 32 are uninitialized
Memory access of size 32 starts at ffff88810098f570
=====================================================

Fixes 83e2ec765be03e8a ("VMCI: doorbell implementation.")

Cc <[email protected]>

Signed-off-by Tetsuo Handa <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/vmw_vmci/vmci_doorbell.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/misc/vmw_vmci/vmci_doorbell.c +1 -1

@@ -334,7 +334,7 @@ int vmci_dbell_host_context_notify(u32 s
 bool vmci_dbell_register_notification_bitmap(u32 bitmap_ppn)
 {
 	int result;
-	struct vmci_notify_bm_set_msg bitmap_set_msg;
+	struct vmci_notify_bm_set_msg bitmap_set_msg = { };
 
 	bitmap_set_msg.hdr.dst = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
 						  VMCI_SET_NOTIFY_BITMAP);

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #75 lore raw

PATCH 75/240 misc: vmw_vmci: explicitly initialize vmci_datagram payload

In reply to Greg Kroah-Hartman

From: Tetsuo Handa <[email protected]>

commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream.

KMSAN complains that vmci_check_host_caps() left the payload part of check_msg uninitialized.

=====================================================

  BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10
  CPU: 1 PID: 1 Comm: swapper/0 Tainted: G    B             5.11.0-rc7+ #4
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
  Call Trace:
   dump_stack+0x21c/0x280
   kmsan_report+0xfb/0x1e0
   kmsan_internal_check_memory+0x202/0x520
   kmsan_check_memory+0xd/0x10
   iowrite8_rep+0x86/0x380
   vmci_guest_probe_device+0xf0b/0x1e70
   pci_device_probe+0xab3/0xe70
   really_probe+0xd16/0x24d0
   driver_probe_device+0x29d/0x3a0
   device_driver_attach+0x25a/0x490
   __driver_attach+0x78c/0x840
   bus_for_each_dev+0x210/0x340
   driver_attach+0x89/0xb0
   bus_add_driver+0x677/0xc40
   driver_register+0x485/0x8e0
   __pci_register_driver+0x1ff/0x350
   vmci_guest_init+0x3e/0x41
   vmci_drv_init+0x1d6/0x43f
   do_one_initcall+0x39c/0x9a0
   do_initcall_level+0x1d7/0x259
   do_initcalls+0x127/0x1cb
   do_basic_setup+0x33/0x36
   kernel_init_freeable+0x29a/0x3ed
   kernel_init+0x1f/0x840
   ret_from_fork+0x1f/0x30

Uninit was created at:

   kmsan_internal_poison_shadow+0x5c/0xf0
   kmsan_slab_alloc+0x8d/0xe0
   kmem_cache_alloc+0x84f/0xe30
   vmci_guest_probe_device+0xd11/0x1e70
   pci_device_probe+0xab3/0xe70
   really_probe+0xd16/0x24d0
   driver_probe_device+0x29d/0x3a0
   device_driver_attach+0x25a/0x490
   __driver_attach+0x78c/0x840
   bus_for_each_dev+0x210/0x340
   driver_attach+0x89/0xb0
   bus_add_driver+0x677/0xc40
   driver_register+0x485/0x8e0
   __pci_register_driver+0x1ff/0x350
   vmci_guest_init+0x3e/0x41
   vmci_drv_init+0x1d6/0x43f
   do_one_initcall+0x39c/0x9a0
   do_initcall_level+0x1d7/0x259
   do_initcalls+0x127/0x1cb
   do_basic_setup+0x33/0x36
   kernel_init_freeable+0x29a/0x3ed
   kernel_init+0x1f/0x840
   ret_from_fork+0x1f/0x30

Bytes 28-31 of 36 are uninitialized
Memory access of size 36 starts at ffff8881675e5f00
=====================================================

Fixes 1f166439917b69d3 ("VMCI: guest side driver implementation.")

Cc <[email protected]>

Signed-off-by Tetsuo Handa <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/vmw_vmci/vmci_guest.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/misc/vmw_vmci/vmci_guest.c +1 -1

@@ -172,7 +172,7 @@ static int vmci_check_host_caps(struct p
 				VMCI_UTIL_NUM_RESOURCES * sizeof(u32);
 	struct vmci_datagram *check_msg;
 
-	check_msg = kmalloc(msg_size, GFP_KERNEL);
+	check_msg = kzalloc(msg_size, GFP_KERNEL);
 	if (!check_msg) {
 		dev_err(&pdev->dev, "%s: Insufficient memory\n", __func__);
 		return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2021-05-20 10:54 UTC #76 lore raw

PATCH 76/240 tracing: Treat recording comm for idle task as a success

In reply to Greg Kroah-Hartman

From: Joel Fernandes <[email protected]>

commit eaf260ac04d9b4cf9f458d5c97555bfff2da526e upstream.

Currently we stop recording comm for non-idle tasks when switching from/to idle task since we treat that as a record failure. Fix that by treat recording of comm for idle task as a success.

Link http://lkml.kernel.org/r/[email protected] open here

Cc [email protected]

Cc Ingo Molnar <[email protected]>

Reported-by Michael Sartain <[email protected]>

Signed-off-by Joel Fernandes <[email protected]>

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/trace.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

kernel/trace/trace.c +5 -1

@@ -1811,7 +1811,11 @@ static int trace_save_cmdline(struct tas
 {
 	unsigned pid, idx;
 
-	if (!tsk->pid || unlikely(tsk->pid > PID_MAX_DEFAULT))
+	/* treat recording of idle task as a success */
+	if (!tsk->pid)
+		return 1;
+
+	if (unlikely(tsk->pid > PID_MAX_DEFAULT))
 		return 0;
 
 	/*

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #77 lore raw

PATCH 77/240 tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline()

In reply to Greg Kroah-Hartman

From: Amey Telawane <[email protected]>

commit e09e28671cda63e6308b31798b997639120e2a21 upstream.

Strcpy is inherently not safe, and strlcpy() should be used instead. __trace_find_cmdline() uses strcpy() because the comms saved must have a terminating nul character, but it doesn't hurt to add the extra protection of using strlcpy() instead of strcpy().

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Amey Telawane <[email protected]>

[AmitP: Cherry-picked this commit from CodeAurora kernel/msm-3.10
https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=2161ae9a70b12cf18ac8e5952a20161ffbccb477]

Signed-off-by Amit Pundir <[email protected]>

[ Updated change log and removed the "- 1" from len parameter ]

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/trace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

kernel/trace/trace.c +1 -1

@@ -1875,7 +1875,7 @@ static void __trace_find_cmdline(int pid
 
 	map = savedcmd->map_pid_to_cmdline[pid];
 	if (map != NO_CMDLINE_MAP)
-		strcpy(comm, get_saved_cmdlines(map));
+		strlcpy(comm, get_saved_cmdlines(map), TASK_COMM_LEN);
 	else
 		strcpy(comm, "<...>");
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #108 lore raw

PATCH 108/240 bus: qcom: Put child node before return

In reply to Greg Kroah-Hartman

From: Pan Bian <[email protected]>

[ Upstream commit ac6ad7c2a862d682bb584a4bc904d89fa7721af8 ]

Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body.

Reviewed-by Linus Walleij <[email protected]>

Fixes 335a12754808 ("bus: qcom: add EBI2 driver")

Signed-off-by Pan Bian <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Bjorn Andersson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/bus/qcom-ebi2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/bus/qcom-ebi2.c +3 -1

index a6444244c411..bfb67aa00bec 100644
@@ -357,8 +357,10 @@ static int qcom_ebi2_probe(struct platform_device *pdev)
 
 		/* Figure out the chipselect */
 		ret = of_property_read_u32(child, "reg", &csindex);
-		if (ret)
+		if (ret) {
+			of_node_put(child);
 			return ret;
+		}
 
 		if (csindex > 5) {
 			dev_err(dev,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #69 lore raw

PATCH 69/240 hsr: use netdev_err() instead of WARN_ONCE()

In reply to Greg Kroah-Hartman

From: Taehee Yoo <[email protected]>

commit 4b793acdca0050739b99ace6a8b9e7f717f57c6b upstream.

When HSR interface is sending a frame, it finds a node with the destination ethernet address from the list.
If there is no node, it calls WARN_ONCE().
But, using WARN_ONCE() for this situation is a little bit overdoing. So, in this patch, the netdev_err() is used instead.

Signed-off-by Taehee Yoo <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Cc George Kennedy <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/hsr/hsr_framereg.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/hsr/hsr_framereg.c +2 -1

@@ -310,7 +310,8 @@ void hsr_addr_subst_dest(struct hsr_node
 
 	node_dst = find_node_by_AddrA(&port->hsr->node_db, eth_hdr(skb)->h_dest);
 	if (!node_dst) {
-		WARN_ONCE(1, "%s: Unknown node\n", __func__);
+		if (net_ratelimit())
+			netdev_err(skb->dev, "%s: Unknown node\n", __func__);
 		return;
 	}
 	if (port->type != node_dst->AddrB_port)

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #78 lore raw

PATCH 78/240 tracing: Map all PIDs to command lines

In reply to Greg Kroah-Hartman

From: Steven Rostedt (VMware) <[email protected]>

commit 785e3c0a3a870e72dc530856136ab4c8dd207128 upstream.

The default max PID is set by PID_MAX_DEFAULT, and the tracing infrastructure uses this number to map PIDs to the comm names of the tasks, such output of the trace can show names from the recorded PIDs in the ring buffer. This mapping is also exported to user space via the "saved_cmdlines" file in the tracefs directory.

But currently the mapping expects the PIDs to be less than PID_MAX_DEFAULT, which is the default maximum and not the real maximum. Recently, systemd will increases the maximum value of a PID on the system, and when tasks are traced that have a PID higher than PID_MAX_DEFAULT, its comm is not recorded. This leads to the entire trace to have "<...>" as the comm name, which is pretty useless.

Instead, keep the array mapping the size of PID_MAX_DEFAULT, but instead of just mapping the index to the comm, map a mask of the PID (PID_MAX_DEFAULT - 1) to the comm, and find the full PID from the map_cmdline_to_pid array (that already exists).

This bug goes back to the beginning of ftrace, but hasn't been an issue until user space started increasing the maximum value of PIDs.

Link https://lkml.kernel.org/r/[email protected] open here

Cc [email protected]

Fixes bc0c38d139ec7 ("ftrace: latency tracer infrastructure")

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/trace.c |   41 +++++++++++++++--------------------------
 1 file changed, 15 insertions(+), 26 deletions(-)

kernel/trace/trace.c +15 ~~-26~~

@@ -1809,14 +1809,13 @@ void trace_stop_cmdline_recording(void);
 
 static int trace_save_cmdline(struct task_struct *tsk)
 {
-	unsigned pid, idx;
+	unsigned tpid, idx;
 
 	/* treat recording of idle task as a success */
 	if (!tsk->pid)
 		return 1;
 
-	if (unlikely(tsk->pid > PID_MAX_DEFAULT))
-		return 0;
+	tpid = tsk->pid & (PID_MAX_DEFAULT - 1);
 
 	/*
 	 * It's not the end of the world if we don't get

@@ -1827,26 +1826,15 @@ static int trace_save_cmdline(struct tas
 	if (!arch_spin_trylock(&trace_cmdline_lock))
 		return 0;
 
-	idx = savedcmd->map_pid_to_cmdline[tsk->pid];
+	idx = savedcmd->map_pid_to_cmdline[tpid];
 	if (idx == NO_CMDLINE_MAP) {
 		idx = (savedcmd->cmdline_idx + 1) % savedcmd->cmdline_num;
 
-		/*
-		 * Check whether the cmdline buffer at idx has a pid
-		 * mapped. We are going to overwrite that entry so we
-		 * need to clear the map_pid_to_cmdline. Otherwise we
-		 * would read the new comm for the old pid.
-		 */
-		pid = savedcmd->map_cmdline_to_pid[idx];
-		if (pid != NO_CMDLINE_MAP)
-			savedcmd->map_pid_to_cmdline[pid] = NO_CMDLINE_MAP;
-
-		savedcmd->map_cmdline_to_pid[idx] = tsk->pid;
-		savedcmd->map_pid_to_cmdline[tsk->pid] = idx;
-
+		savedcmd->map_pid_to_cmdline[tpid] = idx;
 		savedcmd->cmdline_idx = idx;
 	}
 
+	savedcmd->map_cmdline_to_pid[idx] = tsk->pid;
 	set_cmdline(idx, tsk->comm);
 
 	arch_spin_unlock(&trace_cmdline_lock);

@@ -1857,6 +1845,7 @@ static int trace_save_cmdline(struct tas
 static void __trace_find_cmdline(int pid, char comm[])
 {
 	unsigned map;
+	int tpid;
 
 	if (!pid) {
 		strcpy(comm, "<idle>");

@@ -1868,16 +1857,16 @@ static void __trace_find_cmdline(int pid
 		return;
 	}
 
-	if (pid > PID_MAX_DEFAULT) {
-		strcpy(comm, "<...>");
-		return;
+	tpid = pid & (PID_MAX_DEFAULT - 1);
+	map = savedcmd->map_pid_to_cmdline[tpid];
+	if (map != NO_CMDLINE_MAP) {
+		tpid = savedcmd->map_cmdline_to_pid[map];
+		if (tpid == pid) {
+			strlcpy(comm, get_saved_cmdlines(map), TASK_COMM_LEN);
+			return;
+		}
 	}
-
-	map = savedcmd->map_pid_to_cmdline[pid];
-	if (map != NO_CMDLINE_MAP)
-		strlcpy(comm, get_saved_cmdlines(map), TASK_COMM_LEN);
-	else
-		strcpy(comm, "<...>");
+	strcpy(comm, "<...>");
 }
 
 void trace_find_cmdline(int pid, char comm[])

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #118 lore raw

PATCH 118/240 firmware: qcom-scm: Fix QCOM_SCM configuration

In reply to Greg Kroah-Hartman

From: He Ying <[email protected]>

[ Upstream commit 2954a6f12f250890ec2433cec03ba92784d613e8 ]

When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows:

drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk':
qcom_scm-smc.c:(.text+0x36): undefined reference to __arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function scm_legacy_call':
qcom_scm-legacy.c:(.text+0xe2): undefined reference to __arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function scm_legacy_call_atomic':
qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc'

Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y. So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration.

Fixes 916f743da354 ("firmware: qcom: scm: Move the scm driver to drivers/firmware")

Reported-by Hulk Robot <[email protected]>

Signed-off-by He Ying <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/firmware/Kconfig | 1 +
 1 file changed, 1 insertion(+)

drivers/firmware/Kconfig +1 -0

index 854df538ae01..1fc29fca27c8 100644
@@ -194,6 +194,7 @@ config FW_CFG_SYSFS_CMDLINE
 config QCOM_SCM
 	bool
 	depends on ARM || ARM64
+	depends on HAVE_ARM_SMCCC
 	select RESET_CONTROLLER
 
 config QCOM_SCM_32

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #117 lore raw

PATCH 117/240 tty: fix return value for unsupported ioctls

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

[ Upstream commit 1b8b20868a6d64cfe8174a21b25b74367bdf0560 ]

Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments.

Fix up the TIOCMGET, TIOCMSET and TIOCGICOUNT helpers which returned -EINVAL when a tty driver did not implement the corresponding operations.

Note that the TIOCMGET and TIOCMSET helpers predate git and do not get a corresponding Fixes tag below.

Fixes d281da7ff6f7 ("tty: Make tiocgicount a handler")

Signed-off-by Johan Hovold <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/tty/tty_io.c       | 8 ++++----
 include/linux/tty_driver.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

drivers/tty/tty_io.c +4 -4

index 7b4aca20cb29..e16a74b68cd0 100644
@@ -2791,14 +2791,14 @@ out:
  *	@p: pointer to result
  *
  *	Obtain the modem status bits from the tty driver if the feature
- *	is supported. Return -EINVAL if it is not available.
+ *	is supported. Return -ENOTTY if it is not available.
  *
  *	Locking: none (up to the driver)
  */
 
 static int tty_tiocmget(struct tty_struct *tty, int __user *p)
 {
-	int retval = -EINVAL;
+	int retval = -ENOTTY;
 
 	if (tty->ops->tiocmget) {
 		retval = tty->ops->tiocmget(tty);

@@ -2816,7 +2816,7 @@ static int tty_tiocmget(struct tty_struct *tty, int __user *p)
  *	@p: pointer to desired bits
  *
  *	Set the modem status bits from the tty driver if the feature
- *	is supported. Return -EINVAL if it is not available.
+ *	is supported. Return -ENOTTY if it is not available.
  *
  *	Locking: none (up to the driver)
  */

@@ -2828,7 +2828,7 @@ static int tty_tiocmset(struct tty_struct *tty, unsigned int cmd,
 	unsigned int set, clear, val;
 
 	if (tty->ops->tiocmset == NULL)
-		return -EINVAL;
+		return -ENOTTY;
 
 	retval = get_user(val, p);
 	if (retval)

include/linux/tty_driver.h +1 -1

index b742b5e47cc2..ae63c962fa22 100644
@@ -235,7 +235,7 @@
  *
  *	Called when the device receives a TIOCGICOUNT ioctl. Passed a kernel
  *	structure to complete. This method is optional and will only be called
- *	if provided (otherwise EINVAL will be returned).
+ *	if provided (otherwise ENOTTY will be returned).
  */
 
 #include <linux/export.h>

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #119 lore raw

PATCH 119/240 x86/platform/uv: Fix !KEXEC build failure

In reply to Greg Kroah-Hartman

From: Ingo Molnar <[email protected]>

[ Upstream commit c2209ea55612efac75de0a58ef5f7394fae7fa0f ]

When KEXEC is disabled, the UV build fails:

arch/x86/platform/uv/uv_nmi.c:875:14: error: ‘uv_nmi_kexec_failed’ undeclared (first use in this function)

Since uv_nmi_kexec_failed is only defined in the KEXEC_CORE #ifdef branch, this code cannot ever have been build tested:

	if (main)
		pr_err("UV: NMI kdump: KEXEC not supported in this kernel\n");
	atomic_set(&uv_nmi_kexec_failed, 1);

Nor is this use possible in uv_handle_nmi():

                atomic_set(&uv_nmi_kexec_failed, 0);

These bugs were introduced in this commit:

d0a9964e9873: ("x86/platform/uv: Implement simple dump failover if kdump fails")

Which added the uv_nmi_kexec_failed assignments to !KEXEC code, while making the definition KEXEC-only - apparently without testing the !KEXEC case.

Instead of complicating the #ifdef maze, simplify the code by requiring X86_UV to depend on KEXEC_CORE. This pattern is present in other architectures as well.

( We'll remove the untested, 7 years old !KEXEC complications from the file in a
separate commit. )

Fixes d0a9964e9873: ("x86/platform/uv: Implement simple dump failover if kdump fails")

Signed-off-by Ingo Molnar <[email protected]>

Cc Mike Travis <[email protected]>

Cc [email protected]

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

arch/x86/Kconfig +1 -0

index 80636caee07c..3ce5b5bd1dc4 100644
@@ -495,6 +495,7 @@ config X86_UV
 	depends on X86_EXTENDED_PLATFORM
 	depends on NUMA
 	depends on EFI
+	depends on KEXEC_CORE
 	depends on X86_X2APIC
 	depends on PCI
 	---help---

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:55 UTC #120 lore raw

PATCH 120/240 Drivers: hv: vmbus: Increase wait time for VMbus unload

In reply to Greg Kroah-Hartman

From: Michael Kelley <[email protected]>

[ Upstream commit 77db0ec8b7764cb9b09b78066ebfd47b2c0c1909 ]

When running in Azure, disks may be connected to a Linux VM with read/write caching enabled. If a VM panics and issues a VMbus UNLOAD request to Hyper-V, the response is delayed until all dirty data in the disk cache is flushed. In extreme cases, this flushing can take 10's of seconds, depending on the disk speed and the amount of dirty data. If kdump is configured for the VM, the current 10 second timeout in vmbus_wait_for_unload() may be exceeded, and the UNLOAD complete message may arrive well after the kdump kernel is already running, causing problems. Note that no problem occurs if kdump is not enabled because Hyper-V waits for the cache flush before doing a reboot through the BIOS/UEFI code.

Fix this problem by increasing the timeout in vmbus_wait_for_unload() to 100 seconds. Also output periodic messages so that if anyone is watching the serial console, they won't think the VM is completely hung.

Fixes 911e1987efc8 ("Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload")

Signed-off-by Michael Kelley <[email protected]>

Reviewed-by Vitaly Kuznetsov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Wei Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hv/channel_mgmt.c | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

drivers/hv/channel_mgmt.c +25 -5

index 7bf5e2fe1751..60c122b355ea 100644
@@ -675,6 +675,12 @@ static void init_vp_index(struct vmbus_channel *channel, u16 dev_type)
 	channel->target_vp = hv_context.vp_index[cur_cpu];
 }
 
+#define UNLOAD_DELAY_UNIT_MS	10		/* 10 milliseconds */
+#define UNLOAD_WAIT_MS		(100*1000)	/* 100 seconds */
+#define UNLOAD_WAIT_LOOPS	(UNLOAD_WAIT_MS/UNLOAD_DELAY_UNIT_MS)
+#define UNLOAD_MSG_MS		(5*1000)	/* Every 5 seconds */
+#define UNLOAD_MSG_LOOPS	(UNLOAD_MSG_MS/UNLOAD_DELAY_UNIT_MS)
+
 static void vmbus_wait_for_unload(void)
 {
 	int cpu;

@@ -692,12 +698,17 @@ static void vmbus_wait_for_unload(void)
 	 * vmbus_connection.unload_event. If not, the last thing we can do is
 	 * read message pages for all CPUs directly.
 	 *
-	 * Wait no more than 10 seconds so that the panic path can't get
-	 * hung forever in case the response message isn't seen.
+	 * Wait up to 100 seconds since an Azure host must writeback any dirty
+	 * data in its disk cache before the VMbus UNLOAD request will
+	 * complete. This flushing has been empirically observed to take up
+	 * to 50 seconds in cases with a lot of dirty data, so allow additional
+	 * leeway and for inaccuracies in mdelay(). But eventually time out so
+	 * that the panic path can't get hung forever in case the response
+	 * message isn't seen.
 	 */
-	for (i = 0; i < 1000; i++) {
+	for (i = 1; i <= UNLOAD_WAIT_LOOPS; i++) {
 		if (completion_done(&vmbus_connection.unload_event))
-			break;
+			goto completed;
 
 		for_each_online_cpu(cpu) {
 			page_addr = hv_context.synic_message_page[cpu];

@@ -717,9 +728,18 @@ static void vmbus_wait_for_unload(void)
 			vmbus_signal_eom(msg, message_type);
 		}
 
-		mdelay(10);
+		/*
+		 * Give a notice periodically so someone watching the
+		 * serial output won't think it is completely hung.
+		 */
+		if (!(i % UNLOAD_MSG_LOOPS))
+			pr_notice("Waiting for VMBus UNLOAD to complete\n");
+
+		mdelay(UNLOAD_DELAY_UNIT_MS);
 	}
+	pr_err("Continuing even though VMBus UNLOAD did not complete\n");
 
+completed:
 	/*
 	 * We're crashing and already got the UNLOAD_RESPONSE, cleanup all
 	 * maybe-pending messages on all CPUs to be able to receive new

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #126 lore raw

PATCH 126/240 pata_ipx4xx_cf: fix IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit e379b40cc0f179403ce0b82b7e539f635a568da5 ]

The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate errors upstream, and treat IRQ0 as error, returning -EINVAL, as the libata code treats 0 as an indication that polling should be used anyway...

Fixes 0df0d0a0ea9f ("[libata] ARM: add ixp4xx PATA driver")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/ata/pata_ixp4xx_cf.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/ata/pata_ixp4xx_cf.c +5 -1

index abda44183512..fb8d1f68f36f 100644
@@ -169,8 +169,12 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	irq = platform_get_irq(pdev, 0);
-	if (irq)
+	if (irq > 0)
 		irq_set_irq_type(irq, IRQ_TYPE_EDGE_RISING);
+	else if (irq < 0)
+		return irq;
+	else
+		return -EINVAL;
 
 	/* Setup expansion bus chip selects */
 	*data->cs0_cfg = data->cs0_bits;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #125 lore raw

PATCH 125/240 pata_arasan_cf: fix IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit c7e8f404d56b99c80990b19a402c3f640d74be05 ]

The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate upstream -EPROBE_DEFER, and set up the driver to polling mode on (negative) errors and IRQ0 (libata treats IRQ #0 as a polling mode anyway)...

Fixes a480167b23ef ("pata_arasan_cf: Adding support for arasan compact flash host controller")

Signed-off-by Sergey Shtylyov <[email protected]>

Acked-by Viresh Kumar <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/ata/pata_arasan_cf.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

drivers/ata/pata_arasan_cf.c +11 -4

index b4d54771c9fe..623199fab8fe 100644
@@ -819,12 +819,19 @@ static int arasan_cf_probe(struct platform_device *pdev)
 	else
 		quirk = CF_BROKEN_UDMA; /* as it is on spear1340 */
 
-	/* if irq is 0, support only PIO */
-	acdev->irq = platform_get_irq(pdev, 0);
-	if (acdev->irq)
+	/*
+	 * If there's an error getting IRQ (or we do get IRQ0),
+	 * support only PIO
+	 */
+	ret = platform_get_irq(pdev, 0);
+	if (ret > 0) {
+		acdev->irq = ret;
 		irq_handler = arasan_cf_interrupt;
-	else
+	} else	if (ret == -EPROBE_DEFER) {
+		return ret;
+	} else	{
 		quirk |= CF_BROKEN_MWDMA | CF_BROKEN_UDMA;
+	}
 
 	acdev->pbase = res->start;
 	acdev->vbase = devm_ioremap_nocache(&pdev->dev, res->start,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #124 lore raw

PATCH 124/240 media: m88rs6000t: avoid potential out-of-bounds reads on arrays

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 9baa3d64e8e2373ddd11c346439e5dfccb2cbb0d ]

There a 3 array for-loops that don't check the upper bounds of the index into arrays and this may lead to potential out-of-bounds reads. Fix this by adding array size upper bounds checks to be full safe.

Addresses-Coverity: ("Out-of-bounds read")

Link https://lore.kernel.org/linux-media/[email protected] open here

Fixes 333829110f1d ("[media] m88rs6000t: add new dvb-s/s2 tuner for integrated chip M88RS6000")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/tuners/m88rs6000t.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/media/tuners/m88rs6000t.c +3 -3

index 9f3e0fd4cad9..d4443f9c9fa3 100644
@@ -534,7 +534,7 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength)
 	PGA2_cri = PGA2_GC >> 2;
 	PGA2_crf = PGA2_GC & 0x03;
 
-	for (i = 0; i <= RF_GC; i++)
+	for (i = 0; i <= RF_GC && i < ARRAY_SIZE(RFGS); i++)
 		RFG += RFGS[i];
 
 	if (RF_GC == 0)

@@ -546,12 +546,12 @@ static int m88rs6000t_get_rf_strength(struct dvb_frontend *fe, u16 *strength)
 	if (RF_GC == 3)
 		RFG += 100;
 
-	for (i = 0; i <= IF_GC; i++)
+	for (i = 0; i <= IF_GC && i < ARRAY_SIZE(IFGS); i++)
 		IFG += IFGS[i];
 
 	TIAG = TIA_GC * TIA_GS;
 
-	for (i = 0; i <= BB_GC; i++)
+	for (i = 0; i <= BB_GC && i < ARRAY_SIZE(BBGS); i++)
 		BBG += BBGS[i];
 
 	PGA2G = PGA2_cri * PGA2_cri_GS + PGA2_crf * PGA2_crf_GS;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #123 lore raw

PATCH 123/240 media: omap4iss: return error code when omap4iss_get() failed

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

[ Upstream commit 8938c48fa25b491842ece9eb38f0bea0fcbaca44 ]

If omap4iss_get() failed, it need return error code in iss_probe().

Fixes 59f0ad807681 ("[media] v4l: omap4iss: Add support for OMAP4...")

Reported-by Hulk Robot <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/media/omap4iss/iss.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/staging/media/omap4iss/iss.c +3 -1

index c26c99fd4a24..1e10fe204d3b 100644
@@ -1244,8 +1244,10 @@ static int iss_probe(struct platform_device *pdev)
 	if (ret < 0)
 		goto error;
 
-	if (!omap4iss_get(iss))
+	if (!omap4iss_get(iss)) {
+		ret = -EINVAL;
 		goto error;
+	}
 
 	ret = iss_reset(iss);
 	if (ret < 0)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #121 lore raw

PATCH 121/240 ttyprintk: Add TTY hangup callback.

In reply to Greg Kroah-Hartman

From: Tetsuo Handa <[email protected]>

[ Upstream commit c0070e1e60270f6a1e09442a9ab2335f3eaeaad2 ]

syzbot is reporting hung task due to flood of

tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__,

           port->count);

message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true.

----------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>

int main(int argc, char *argv[])

{
	int i;
	int fd[10];

	for (i = 0; i < 10; i++)
		fd[i] = open("/dev/ttyprintk", O_WRONLY);
	ioctl(fd[0], TIOCVHANGUP);
	for (i = 0; i < 10; i++)
		close(fd[i]);
	close(open("/dev/ttyprintk", O_WRONLY));
	return 0;
}

----------

When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback.

[1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a

Reported-by syzbot <[email protected]>

Tested-by syzbot <[email protected]>

Signed-off-by Tetsuo Handa <[email protected]>

Fixes 24b4b67d17c308aa ("add ttyprintk driver")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/char/ttyprintk.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/char/ttyprintk.c +11 -0

index 774748497ace..e56ac5adb5fc 100644
@@ -159,12 +159,23 @@ static int tpk_ioctl(struct tty_struct *tty,
 	return 0;
 }
 
+/*
+ * TTY operations hangup function.
+ */
+static void tpk_hangup(struct tty_struct *tty)
+{
+	struct ttyprintk_port *tpkp = tty->driver_data;
+
+	tty_port_hangup(&tpkp->port);
+}
+
 static const struct tty_operations ttyprintk_ops = {
 	.open = tpk_open,
 	.close = tpk_close,
 	.write = tpk_write,
 	.write_room = tpk_write_room,
 	.ioctl = tpk_ioctl,
+	.hangup = tpk_hangup,
 };
 
 static const struct tty_port_operations null_ops = { };

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #122 lore raw

PATCH 122/240 media: vivid: fix assignment of dev->fbuf_out_flags

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 5cde22fcc7271812a7944c47b40100df15908358 ]

Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise mask and the following statement should be bit-wise or'ing in the new flag bits but instead is making a direct assignment. Fix this by using the |= operator rather than an assignment.

Addresses-Coverity: ("Unused value")

Fixes ef834f7836ec ("[media] vivid: add the video capture and output parts")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/vivid/vivid-vid-out.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/platform/vivid/vivid-vid-out.c +1 -1

index 8fed2fbe91a9..f78caf72cb3e 100644
@@ -1003,7 +1003,7 @@ int vivid_vid_out_s_fbuf(struct file *file, void *fh,
 		return -EINVAL;
 	}
 	dev->fbuf_out_flags &= ~(chroma_flags | alpha_flags);
-	dev->fbuf_out_flags = a->flags & (chroma_flags | alpha_flags);
+	dev->fbuf_out_flags |= a->flags & (chroma_flags | alpha_flags);
 	return 0;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #109 lore raw

PATCH 109/240 crypto: qat - fix error path in adf_isr_resource_alloc()

In reply to Greg Kroah-Hartman

From: Giovanni Cabiddu <[email protected]>

[ Upstream commit 83dc1173d73f80cbce2fee4d308f51f87b2f26ae ]

The function adf_isr_resource_alloc() is not unwinding correctly in case of error.
This patch fixes the error paths and propagate the errors to the caller.

Fixes 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator")

Signed-off-by Giovanni Cabiddu <[email protected]>

Reviewed-by Marco Chiappero <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/qat/qat_common/adf_isr.c | 29 ++++++++++++++++++-------
 1 file changed, 21 insertions(+), 8 deletions(-)

drivers/crypto/qat/qat_common/adf_isr.c +21 -8

index 06d49017a52b..2c0be14309cf 100644
@@ -330,19 +330,32 @@ int adf_isr_resource_alloc(struct adf_accel_dev *accel_dev)
 
 	ret = adf_isr_alloc_msix_entry_table(accel_dev);
 	if (ret)
-		return ret;
-	if (adf_enable_msix(accel_dev))
 		goto err_out;
 
-	if (adf_setup_bh(accel_dev))
-		goto err_out;
+	ret = adf_enable_msix(accel_dev);
+	if (ret)
+		goto err_free_msix_table;
 
-	if (adf_request_irqs(accel_dev))
-		goto err_out;
+	ret = adf_setup_bh(accel_dev);
+	if (ret)
+		goto err_disable_msix;
+
+	ret = adf_request_irqs(accel_dev);
+	if (ret)
+		goto err_cleanup_bh;
 
 	return 0;
+
+err_cleanup_bh:
+	adf_cleanup_bh(accel_dev);
+
+err_disable_msix:
+	adf_disable_msix(&accel_dev->accel_pci_dev);
+
+err_free_msix_table:
+	adf_isr_free_msix_entry_table(accel_dev);
+
 err_out:
-	adf_isr_resource_free(accel_dev);
-	return -EFAULT;
+	return ret;
 }
 EXPORT_SYMBOL_GPL(adf_isr_resource_alloc);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #127 lore raw

PATCH 127/240 sata_mv: add IRQ checks

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit e6471a65fdd5efbb8dd2732dd0f063f960685ceb ]

The function mv_platform_probe() neglects to check the results of the calls to platform_get_irq() and irq_of_parse_and_map() and blithely passes them to ata_host_activate() -- while the latter only checks for IRQ0 (treating it as a polling mode indicattion) and passes the negative values to devm_request_irq() causing it to fail as it takes unsigned values for the IRQ #...

Add to mv_platform_probe() the proper IRQ checks to pass the positive IRQ #s to ata_host_activate(), propagate upstream the negative error codes, and override the IRQ0 with -EINVAL (as we don't want the polling mode).

Fixes f351b2d638c3 ("sata_mv: Support SoC controllers")

Signed-off-by Sergey Shtylyov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/ata/sata_mv.c | 4 ++++
 1 file changed, 4 insertions(+)

drivers/ata/sata_mv.c +4 -0

index 513ef298dd96..ded3a66049d2 100644
@@ -4112,6 +4112,10 @@ static int mv_platform_probe(struct platform_device *pdev)
 		n_ports = mv_platform_data->n_ports;
 		irq = platform_get_irq(pdev, 0);
 	}
+	if (irq < 0)
+		return irq;
+	if (!irq)
+		return -EINVAL;
 
 	host = ata_host_alloc_pinfo(&pdev->dev, ppi, n_ports);
 	hpriv = devm_kzalloc(&pdev->dev, sizeof(*hpriv), GFP_KERNEL);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #128 lore raw

PATCH 128/240 ata: libahci_platform: fix IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit b30d0040f06159de97ad9c0b1536f47250719d7d ]

Iff platform_get_irq() returns 0, ahci_platform_init_host() would return 0 early (as if the call was successful). Override IRQ0 with -EINVAL instead as the 'libata' regards 0 as "no IRQ" (thus polling) anyway...

Fixes c034640a32f8 ("ata: libahci: properly propagate return value of platform_get_irq()")

Signed-off-by Sergey Shtylyov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/ata/libahci_platform.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/ata/libahci_platform.c +3 -1

index 0b80502bc1c5..bfa2e5eec263 100644
@@ -518,11 +518,13 @@ int ahci_platform_init_host(struct platform_device *pdev,
 	int i, irq, n_ports, rc;
 
 	irq = platform_get_irq(pdev, 0);
-	if (irq <= 0) {
+	if (irq < 0) {
 		if (irq != -EPROBE_DEFER)
 			dev_err(dev, "no irq\n");
 		return irq;
 	}
+	if (!irq)
+		return -EINVAL;
 
 	hpriv->irq = irq;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:56 UTC #129 lore raw

PATCH 129/240 scsi: fcoe: Fix mismatched fcoe_wwn_from_mac declaration

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

[ Upstream commit 5b11c9d80bde81f6896cc85b23aeaa9502a704ed ]

An old cleanup changed the array size from MAX_ADDR_LEN to unspecified in the declaration, but now gcc-11 warns about this:

drivers/scsi/fcoe/fcoe_ctlr.c:1972:37: error: argument 1 of type ‘unsigned char[32]’ with mismatched bound [-Werror=array-parameter=]
1972 | u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN],

      |                       ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In file included from /git/arm-soc/drivers/scsi/fcoe/fcoe_ctlr.c:33:
include/scsi/libfcoe.h:252:37: note: previously declared as ‘unsigned char[]’
  252 | u64 fcoe_wwn_from_mac(unsigned char mac[], unsigned int, unsigned int);
      |                       ~~~~~~~~~~~~~~^~~~~

Change the type back to what the function definition uses.

Link https://lore.kernel.org/r/[email protected] open here

Fixes fdd78027fd47 ("[SCSI] fcoe: cleans up libfcoe.h and adds fcoe.h for fcoe module")

Signed-off-by Arnd Bergmann <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/scsi/libfcoe.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

include/scsi/libfcoe.h +1 -1

index 6be92eede5c0..a911f993219d 100644
@@ -261,7 +261,7 @@ int fcoe_ctlr_recv_flogi(struct fcoe_ctlr *, struct fc_lport *,
 			 struct fc_frame *);
 
 /* libfcoe funcs */
-u64 fcoe_wwn_from_mac(unsigned char mac[], unsigned int, unsigned int);
+u64 fcoe_wwn_from_mac(unsigned char mac[MAX_ADDR_LEN], unsigned int, unsigned int);
 int fcoe_libfc_config(struct fc_lport *, struct fcoe_ctlr *,
 		      const struct libfc_function_template *, int init_fcp);
 u32 fcoe_fc_crc(struct fc_frame *fp);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #130 lore raw

PATCH 130/240 media: dvb-usb-remote: fix dvb_usb_nec_rc_key_to_event type mismatch

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

[ Upstream commit 0fa430e96d3c3561a78701f51fd8593da68b8474 ]

gcc-11 warns about the prototype not exactly matching the function definition:

drivers/media/usb/dvb-usb/dvb-usb-remote.c:363:20: error: argument 2 of type ‘u8[5]’ {aka ‘unsigned char[5]’} with mismatched bound [-Werror=array-parameter=]

  363 |                 u8 keybuf[5], u32 *event, int *state)
      |                 ~~~^~~~~~~~~

In file included from drivers/media/usb/dvb-usb/dvb-usb-common.h:13,
from drivers/media/usb/dvb-usb/dvb-usb-remote.c:9:
drivers/media/usb/dvb-usb/dvb-usb.h:490:65: note: previously declared as ‘u8[]’ {aka ‘unsigned char[]’}
490 | extern int dvb_usb_nec_rc_key_to_event(struct dvb_usb_device *, u8[], u32 *, int *);
| ^~~~

Fixes 776338e121b9 ("[PATCH] dvb: Add generalized dvb-usb driver")

Signed-off-by Arnd Bergmann <[email protected]>

Signed-off-by Sean Young <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/dvb-usb/dvb-usb.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/media/usb/dvb-usb/dvb-usb.h +2 -1

index 107255b08b2b..704d57e3ea1c 100644
@@ -471,7 +471,8 @@ extern int dvb_usb_generic_rw(struct dvb_usb_device *, u8 *, u16, u8 *, u16,int)
 extern int dvb_usb_generic_write(struct dvb_usb_device *, u8 *, u16);
 
 /* commonly used remote control parsing */
-extern int dvb_usb_nec_rc_key_to_event(struct dvb_usb_device *, u8[], u32 *, int *);
+int dvb_usb_nec_rc_key_to_event(struct dvb_usb_device *d, u8 keybuf[5],
+				u32 *event, int *state);
 
 /* commonly used firmware download types and function */
 struct hexline {

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #110 lore raw

PATCH 110/240 mtd: rawnand: gpmi: Fix a double free in gpmi_nand_init

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

[ Upstream commit 076de75de1e53160e9b099f75872c1f9adf41a0b ]

If the callee gpmi_alloc_dma_buffer() failed to alloc memory for this->raw_buffer, gpmi_free_dma_buffer() will be called to free this->auxiliary_virt. But this->auxiliary_virt is still a non-NULL and valid ptr.

Then gpmi_alloc_dma_buffer() returns err and gpmi_free_dma_buffer() is called again to free this->auxiliary_virt in err_out. This causes a double free.

As gpmi_free_dma_buffer() has already called in gpmi_alloc_dma_buffer's error path, so it should return err directly instead of releasing the dma buffer again.

Fixes 4d02423e9afe6 ("mtd: nand: gpmi: Fix gpmi_nand_init() error path")

Signed-off-by Lv Yunlong <[email protected]>

Signed-off-by Miquel Raynal <[email protected]>

Link https://lore.kernel.org/linux-mtd/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mtd/nand/gpmi-nand/gpmi-nand.c +1 -1

index f4a99e91c250..c43bd945d93a 100644
@@ -2020,7 +2020,7 @@ static int gpmi_nand_init(struct gpmi_nand_data *this)
 	this->bch_geometry.auxiliary_size = 128;
 	ret = gpmi_alloc_dma_buffer(this);
 	if (ret)
-		goto err_out;
+		return ret;
 
 	ret = nand_scan_ident(mtd, GPMI_IS_MX6(this) ? 2 : 1, NULL);
 	if (ret)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #135 lore raw

PATCH 135/240 HSI: core: fix resource leaks in hsi_add_client_from_dt()

In reply to Greg Kroah-Hartman

From: Dan Carpenter <[email protected]>

[ Upstream commit 5c08b0f75575648032f309a6f58294453423ed93 ]

If some of the allocations fail between the dev_set_name() and the device_register() then the name will not be freed. Fix this by moving dev_set_name() directly in front of the call to device_register().

Fixes a2aa24734d9d ("HSI: Add common DT binding for HSI client devices")

Signed-off-by Dan Carpenter <[email protected]>

Reviewed-by Jason Gunthorpe <[email protected]>

Signed-off-by Sebastian Reichel <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hsi/hsi_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/hsi/hsi_core.c +1 -2

index c2a2a9795b0b..e9d63b966caf 100644
@@ -223,8 +223,6 @@ static void hsi_add_client_from_dt(struct hsi_port *port,
 	if (err)
 		goto err;
 
-	dev_set_name(&cl->device, "%s", name);
-
 	err = hsi_of_property_parse_mode(client, "hsi-mode", &mode);
 	if (err) {
 		err = hsi_of_property_parse_mode(client, "hsi-rx-mode",

@@ -307,6 +305,7 @@ static void hsi_add_client_from_dt(struct hsi_port *port,
 	cl->device.release = hsi_client_release;
 	cl->device.of_node = client;
 
+	dev_set_name(&cl->device, "%s", name);
 	if (device_register(&cl->device) < 0) {
 		pr_err("hsi: failed to register client: %s\n", name);
 		put_device(&cl->device);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #136 lore raw

PATCH 136/240 x86/events/amd/iommu: Fix sysfs type mismatch

In reply to Greg Kroah-Hartman

From: Nathan Chancellor <[email protected]>

[ Upstream commit de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355 ]

dev_attr_show() calls _iommu_event_show() via an indirect call but _iommu_event_show()'s type does not currently match the type of the show() member in 'struct device_attribute', resulting in a Control Flow Integrity violation.

$ cat /sys/devices/amd_iommu_1/events/mem_dte_hit
csource=0x0a

$ dmesg | grep "CFI failure"
[ 3526.735140] CFI failure (target: _iommu_event_show...):

Change _iommu_event_show() and 'struct amd_iommu_event_desc' to 'struct device_attribute' so that there is no more CFI violation.

Fixes 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore PMU implementation")

Signed-off-by Nathan Chancellor <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/events/amd/iommu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/x86/events/amd/iommu.c +3 -3

index b28200dea715..2bbf3fba8097 100644
@@ -80,12 +80,12 @@ static struct attribute_group amd_iommu_format_group = {
  * sysfs events attributes
  *---------------------------------------------*/
 struct amd_iommu_event_desc {
-	struct kobj_attribute attr;
+	struct device_attribute attr;
 	const char *event;
 };
 
-static ssize_t _iommu_event_show(struct kobject *kobj,
-				struct kobj_attribute *attr, char *buf)
+static ssize_t _iommu_event_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
 {
 	struct amd_iommu_event_desc *event =
 		container_of(attr, struct amd_iommu_event_desc, attr);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #133 lore raw

PATCH 133/240 scsi: sun3x_esp: Add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit 14b321380eb333c82853d7d612d0995f05f88fdc ]

The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 0bb67f181834 ("[SCSI] sun3x_esp: convert to esp_scsi")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/sun3x_esp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/scsi/sun3x_esp.c +3 -1

index d50c5ed8f428..167ae2d29e47 100644
@@ -233,7 +233,9 @@ static int esp_sun3x_probe(struct platform_device *dev)
 	if (!esp->command_block)
 		goto fail_unmap_regs_dma;
 
-	host->irq = platform_get_irq(dev, 0);
+	host->irq = err = platform_get_irq(dev, 0);
+	if (err < 0)
+		goto fail_unmap_command_block;
 	err = request_irq(host->irq, scsi_esp_intr, IRQF_SHARED,
 			  "SUN3X ESP", esp);
 	if (err < 0)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #134 lore raw

PATCH 134/240 scsi: sni_53c710: Add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit 1160d61bc51e87e509cfaf9da50a0060f67b6de4 ]

The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #s), causing it to fail with -EINVAL (overridden by -ENODEV further below). Stop calling request_irq() with the invalid IRQ #s.

Link https://lore.kernel.org/r/[email protected] open here

Fixes c27d85f3f3c5 ("[SCSI] SNI RM 53c710 driver")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/sni_53c710.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/scsi/sni_53c710.c +4 -1

index b0f5220ae23a..fad68cb028d6 100644
@@ -71,6 +71,7 @@ static int snirm710_probe(struct platform_device *dev)
 	struct NCR_700_Host_Parameters *hostdata;
 	struct Scsi_Host *host;
 	struct  resource *res;
+	int rc;
 
 	res = platform_get_resource(dev, IORESOURCE_MEM, 0);
 	if (!res)

@@ -96,7 +97,9 @@ static int snirm710_probe(struct platform_device *dev)
 		goto out_kfree;
 	host->this_id = 7;
 	host->base = base;
-	host->irq = platform_get_irq(dev, 0);
+	host->irq = rc = platform_get_irq(dev, 0);
+	if (rc < 0)
+		goto out_put_host;
 	if(request_irq(host->irq, NCR_700_intr, IRQF_SHARED, "snirm710", host)) {
 		printk(KERN_ERR "snirm710: request_irq failed!\n");
 		goto out_put_host;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #132 lore raw

PATCH 132/240 scsi: jazz_esp: Add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit 38fca15c29db6ed06e894ac194502633e2a7d1fb ]

Link https://lore.kernel.org/r/[email protected] open here

Fixes 352e921f0dd4 ("[SCSI] jazz_esp: converted to use esp_core")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/jazz_esp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/scsi/jazz_esp.c +3 -1

index 9aaa74e349cc..65f0dbfc3a45 100644
@@ -170,7 +170,9 @@ static int esp_jazz_probe(struct platform_device *dev)
 	if (!esp->command_block)
 		goto fail_unmap_regs;
 
-	host->irq = platform_get_irq(dev, 0);
+	host->irq = err = platform_get_irq(dev, 0);
+	if (err < 0)
+		goto fail_unmap_command_block;
 	err = request_irq(host->irq, scsi_esp_intr, IRQF_SHARED, "ESP", esp);
 	if (err < 0)
 		goto fail_unmap_command_block;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:57 UTC #139 lore raw

PATCH 139/240 net: lapbether: Prevent racing when checking whether the netif is running

In reply to Greg Kroah-Hartman

From: Xie He <[email protected]>

[ Upstream commit 5acd0cfbfbb5a688da1bfb1a2152b0c855115a35 ]

There are two "netif_running" checks in this driver. One is in "lapbeth_xmit" and the other is in "lapbeth_rcv". They serve to make sure that the LAPB APIs called in these functions are called before "lapb_unregister" is called by the "ndo_stop" function.

However, these "netif_running" checks are unreliable, because it's possible that immediately after "netif_running" returns true, "ndo_stop" is called (which causes "lapb_unregister" to be called).

This patch adds locking to make sure "lapbeth_xmit" and "lapbeth_rcv" can reliably check and ensure the netif is running while doing their work.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Xie He <[email protected]>

Acked-by Martin Schiller <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wan/lapbether.c | 32 +++++++++++++++++++++++++-------
 1 file changed, 25 insertions(+), 7 deletions(-)

drivers/net/wan/lapbether.c +25 -7

index 666bbacb8cb4..24daa1d0e9c5 100644
@@ -56,6 +56,8 @@ struct lapbethdev {
 	struct list_head	node;
 	struct net_device	*ethdev;	/* link to ethernet device */
 	struct net_device	*axdev;		/* lapbeth device (lapb#) */
+	bool			up;
+	spinlock_t		up_lock;	/* Protects "up" */
 };
 
 static LIST_HEAD(lapbeth_devices);

@@ -103,8 +105,9 @@ static int lapbeth_rcv(struct sk_buff *skb, struct net_device *dev, struct packe
 	rcu_read_lock();
 	lapbeth = lapbeth_get_x25_dev(dev);
 	if (!lapbeth)
-		goto drop_unlock;
-	if (!netif_running(lapbeth->axdev))
+		goto drop_unlock_rcu;
+	spin_lock_bh(&lapbeth->up_lock);
+	if (!lapbeth->up)
 		goto drop_unlock;
 
 	len = skb->data[0] + skb->data[1] * 256;

@@ -119,11 +122,14 @@ static int lapbeth_rcv(struct sk_buff *skb, struct net_device *dev, struct packe
 		goto drop_unlock;
 	}
 out:
+	spin_unlock_bh(&lapbeth->up_lock);
 	rcu_read_unlock();
 	return 0;
 drop_unlock:
 	kfree_skb(skb);
 	goto out;
+drop_unlock_rcu:
+	rcu_read_unlock();
 drop:
 	kfree_skb(skb);
 	return 0;

@@ -151,13 +157,11 @@ static int lapbeth_data_indication(struct net_device *dev, struct sk_buff *skb)
 static netdev_tx_t lapbeth_xmit(struct sk_buff *skb,
 				      struct net_device *dev)
 {
+	struct lapbethdev *lapbeth = netdev_priv(dev);
 	int err;
 
-	/*
-	 * Just to be *really* sure not to send anything if the interface
-	 * is down, the ethernet device may have gone.
-	 */
-	if (!netif_running(dev))
+	spin_lock_bh(&lapbeth->up_lock);
+	if (!lapbeth->up)
 		goto drop;
 
 	/* There should be a pseudo header of 1 byte added by upper layers.

@@ -188,6 +192,7 @@ static netdev_tx_t lapbeth_xmit(struct sk_buff *skb,
 		goto drop;
 	}
 out:
+	spin_unlock_bh(&lapbeth->up_lock);
 	return NETDEV_TX_OK;
 drop:
 	kfree_skb(skb);

@@ -279,6 +284,7 @@ static const struct lapb_register_struct lapbeth_callbacks = {
  */
 static int lapbeth_open(struct net_device *dev)
 {
+	struct lapbethdev *lapbeth = netdev_priv(dev);
 	int err;
 
 	if ((err = lapb_register(dev, &lapbeth_callbacks)) != LAPB_OK) {

@@ -286,13 +292,22 @@ static int lapbeth_open(struct net_device *dev)
 		return -ENODEV;
 	}
 
+	spin_lock_bh(&lapbeth->up_lock);
+	lapbeth->up = true;
+	spin_unlock_bh(&lapbeth->up_lock);
+
 	return 0;
 }
 
 static int lapbeth_close(struct net_device *dev)
 {
+	struct lapbethdev *lapbeth = netdev_priv(dev);
 	int err;
 
+	spin_lock_bh(&lapbeth->up_lock);
+	lapbeth->up = false;
+	spin_unlock_bh(&lapbeth->up_lock);
+
 	if ((err = lapb_unregister(dev)) != LAPB_OK)
 		pr_err("lapb_unregister error: %d\n", err);

@@ -350,6 +365,9 @@ static int lapbeth_new_device(struct net_device *dev)
 	dev_hold(dev);
 	lapbeth->ethdev = dev;
 
+	lapbeth->up = false;
+	spin_lock_init(&lapbeth->up_lock);
+
 	rc = -EIO;
 	if (register_netdevice(ndev))
 		goto fail;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #140 lore raw

PATCH 140/240 powerpc/prom: Mark identical_pvr_fixup as __init

In reply to Greg Kroah-Hartman

From: Nathan Chancellor <[email protected]>

[ Upstream commit 1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc ]

If identical_pvr_fixup() is not inlined, there are two modpost warnings:

WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:of_get_flat_dt_prop()
The function identical_pvr_fixup() references
the function __init of_get_flat_dt_prop().
This is often because identical_pvr_fixup lacks a __init annotation or the annotation of of_get_flat_dt_prop is wrong.

WARNING: modpost: vmlinux.o(.text+0x551c): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:identify_cpu()
The function identical_pvr_fixup() references
the function __init identify_cpu().
This is often because identical_pvr_fixup lacks a __init annotation or the annotation of identify_cpu is wrong.

identical_pvr_fixup() calls two functions marked as __init and is only called by a function marked as __init so it should be marked as __init as well. At the same time, remove the inline keywork as it is not necessary to inline this function. The compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler:
remove CONFIG_OPTIMIZE_INLINING entirely").

Fixes 14b3d926a22b ("[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround")

Signed-off-by Nathan Chancellor <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://github.com/ClangBuiltLinux/linux/issues/1316

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/kernel/prom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/kernel/prom.c +1 -1

index b868f07c4246..11b4ecec04ee 100644
@@ -262,7 +262,7 @@ static struct feature_property {
 };
 
 #if defined(CONFIG_44x) && defined(CONFIG_PPC_FPU)
-static inline void identical_pvr_fixup(unsigned long node)
+static __init void identical_pvr_fixup(unsigned long node)
 {
 	unsigned int pvr;
 	const char *model = of_get_flat_dt_prop(node, "model", NULL);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #142 lore raw

PATCH 142/240 nfc: pn533: prevent potential memory corruption

In reply to Greg Kroah-Hartman

From: Dan Carpenter <[email protected]>

[ Upstream commit ca4d4c34ae9aa5c3c0da76662c5e549d2fc0cc86 ]

If the "type_a->nfcid_len" is too large then it would lead to memory corruption in pn533_target_found_type_a() when we do:

	memcpy(nfc_tgt->nfcid1, tgt_type_a->nfcid_data, nfc_tgt->nfcid1_len);

Fixes c3b1e1e8a76f ("NFC: Export NFCID1 from pn533")

Signed-off-by Dan Carpenter <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nfc/pn533/pn533.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/nfc/pn533/pn533.c +3 -0

index d9c55830b2b2..6c495664d2cb 100644
@@ -678,6 +678,9 @@ static bool pn533_target_type_a_is_valid(struct pn533_target_type_a *type_a,
 	if (PN533_TYPE_A_SEL_CASCADE(type_a->sel_res) != 0)
 		return false;
 
+	if (type_a->nfcid_len > NFC_NFCID1_MAXSIZE)
+		return false;
+
 	return true;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #111 lore raw

PATCH 111/240 staging: rtl8192u: Fix potential infinite loop

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit f9b9263a25dc3d2eaaa829e207434db6951ca7bc ]

The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of riv->ieee80211->LinkDetectInfo.SlotNum that is a u16 type. There is a potential infinite loop if SlotNum is larger than the u8 loop counter. Fix this by making the loop counter the same type as SlotNum.

Addresses-Coverity: ("Infinite loop")

Fixes 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")

Signed-off-by Colin Ian King <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/staging/rtl8192u/r8192U_core.c +1 -1

index fa4c47c7d216..53b77c8ae328 100644
@@ -3420,7 +3420,7 @@ static void rtl819x_update_rxcounts(struct r8192_priv *priv, u32 *TotalRxBcnNum,
 			     u32 *TotalRxDataNum)
 {
 	u16			SlotIndex;
-	u8			i;
+	u16			i;
 
 	*TotalRxBcnNum = 0;
 	*TotalRxDataNum = 0;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #112 lore raw

PATCH 112/240 staging: greybus: uart: fix unprivileged TIOCCSERIAL

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

[ Upstream commit 60c6b305c11b5fd167ce5e2ce42f3a9098c388f0 ]

TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters.

A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success.

Fix the greybus implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values.

Fixes e68453ed28c5 ("greybus: uart-gb: now builds, more framework added")

Signed-off-by Johan Hovold <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/greybus/uart.c | 2 --
 1 file changed, 2 deletions(-)

drivers/staging/greybus/uart.c +0 -2

index 9ef9cbfd8926..c35c9b766a00 100644
@@ -661,8 +661,6 @@ static int set_serial_info(struct gb_tty *gb_tty,
 		if ((close_delay != gb_tty->port.close_delay) ||
 		    (closing_wait != gb_tty->port.closing_wait))
 			retval = -EPERM;
-		else
-			retval = -EOPNOTSUPP;
 	} else {
 		gb_tty->port.close_delay = close_delay;
 		gb_tty->port.closing_wait = closing_wait;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #113 lore raw

PATCH 113/240 crypto: qat - Fix a double free in adf_create_ring

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

[ Upstream commit f7cae626cabb3350b23722b78fe34dd7a615ca04 ]

In adf_create_ring, if the callee adf_init_ring() failed, the callee will free the ring->base_addr by dma_free_coherent() and return -EFAULT. Then adf_create_ring will goto err and the ring->base_addr will be freed again in adf_cleanup_ring().

My patch sets ring->base_addr to NULL after the first freed to avoid the double free.

Fixes a672a9dc872ec ("crypto: qat - Intel(R) QAT transport code")

Signed-off-by Lv Yunlong <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/qat/qat_common/adf_transport.c | 1 +
 1 file changed, 1 insertion(+)

drivers/crypto/qat/qat_common/adf_transport.c +1 -0

index 57d2622728a5..4c0067f8c079 100644
@@ -197,6 +197,7 @@ static int adf_init_ring(struct adf_etr_ring_data *ring)
 		dev_err(&GET_DEV(accel_dev), "Ring address not aligned\n");
 		dma_free_coherent(&GET_DEV(accel_dev), ring_size_bytes,
 				  ring->base_addr, ring->dma_addr);
+		ring->base_addr = NULL;
 		return -EFAULT;
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #131 lore raw

PATCH 131/240 clk: uniphier: Fix potential infinite loop

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit f6b1340dc751a6caa2a0567b667d0f4f4172cd58 ]

The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of num_parents that is an int type. There is a potential infinite loop if num_parents is larger than the u8 loop counter. Fix this by making the loop counter the same type as num_parents. Also make num_parents an unsigned int to match the return type of the call to clk_hw_get_num_parents.

Addresses-Coverity: ("Infinite loop")

Fixes 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")

Signed-off-by Colin Ian King <[email protected]>

Reviewed-by Masahiro Yamada <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Stephen Boyd <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/clk/uniphier/clk-uniphier-mux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/clk/uniphier/clk-uniphier-mux.c +2 -2

index 2c243a894f3b..3a52ab968ac2 100644
@@ -40,10 +40,10 @@ static int uniphier_clk_mux_set_parent(struct clk_hw *hw, u8 index)
 static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
 {
 	struct uniphier_clk_mux *mux = to_uniphier_clk_mux(hw);
-	int num_parents = clk_hw_get_num_parents(hw);
+	unsigned int num_parents = clk_hw_get_num_parents(hw);
 	int ret;
 	unsigned int val;
-	u8 i;
+	unsigned int i;
 
 	ret = regmap_read(mux->regmap, mux->reg, &val);
 	if (ret)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #114 lore raw

PATCH 114/240 usb: gadget: r8a66597: Add missing null check on return from platform_get_resource

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 9c2076090c2815fe7c49676df68dde7e60a9b9fc ]

The call to platform_get_resource can potentially return a NULL pointer on failure, so add this check and return -EINVAL if it fails.

Fixes c41442474a26 ("usb: gadget: R8A66597 peripheral controller support.")

Signed-off-by Colin Ian King <[email protected]>

Addresses-Coverity: ("Dereference null return")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/gadget/udc/r8a66597-udc.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/usb/gadget/udc/r8a66597-udc.c +2 -0

index 230e3248f386..80503c3604ca 100644
@@ -1855,6 +1855,8 @@ static int r8a66597_probe(struct platform_device *pdev)
 		return PTR_ERR(reg);
 
 	ires = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!ires)
+		return -EINVAL;
 	irq = ires->start;
 	irq_trigger = ires->flags & IRQF_TRIGGER_MASK;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #115 lore raw

PATCH 115/240 USB: cdc-acm: fix unprivileged TIOCCSERIAL

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

[ Upstream commit dd5619582d60007139f0447382d2839f4f9e339b ]

TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters.

Fix the cdc-acm implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values.

Fixes ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)")

Acked-by Oliver Neukum <[email protected]>

Signed-off-by Johan Hovold <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/class/cdc-acm.c | 2 --
 1 file changed, 2 deletions(-)

drivers/usb/class/cdc-acm.c +0 -2

index 97b5b021a220..a70d2341ada6 100644
@@ -870,8 +870,6 @@ static int set_serial_info(struct acm *acm,
 		if ((new_serial.close_delay != old_close_delay) ||
 	            (new_serial.closing_wait != old_closing_wait))
 			retval = -EPERM;
-		else
-			retval = -EOPNOTSUPP;
 	} else {
 		acm->port.close_delay  = close_delay;
 		acm->port.closing_wait = closing_wait;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #116 lore raw

PATCH 116/240 tty: actually undefine superseded ASYNC flags

In reply to Greg Kroah-Hartman

From: Johan Hovold <[email protected]>

[ Upstream commit d09845e98a05850a8094ea8fd6dd09a8e6824fff ]

Some kernel-internal ASYNC flags have been superseded by tty-port flags and should no longer be used by kernel drivers.

Fix the misspelled "__KERNEL__" compile guards which failed their sole purpose to break out-of-tree drivers that have not yet been updated.

Fixes 5c0517fefc92 ("tty: core: Undefine ASYNC_* flags superceded by TTY_PORT* flags")

Signed-off-by Johan Hovold <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/uapi/linux/tty_flags.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

include/uapi/linux/tty_flags.h +2 -2

index 66e4d8bcb16f..9f9572b2a596 100644
@@ -38,7 +38,7 @@
  * WARNING: These flags are no longer used and have been superceded by the
  *	    TTY_PORT_ flags in the iflags field (and not userspace-visible)
  */
-#ifndef _KERNEL_
+#ifndef __KERNEL__
 #define ASYNCB_INITIALIZED	31 /* Serial port was initialized */
 #define ASYNCB_SUSPENDED	30 /* Serial port is suspended */
 #define ASYNCB_NORMAL_ACTIVE	29 /* Normal device is active */

@@ -80,7 +80,7 @@
 #define ASYNC_SPD_WARP		(ASYNC_SPD_HI|ASYNC_SPD_SHI)
 #define ASYNC_SPD_MASK		(ASYNC_SPD_HI|ASYNC_SPD_VHI|ASYNC_SPD_SHI)
 
-#ifndef _KERNEL_
+#ifndef __KERNEL__
 /* These flags are no longer used (and were always masked from userspace) */
 #define ASYNC_INITIALIZED	(1U << ASYNCB_INITIALIZED)
 #define ASYNC_NORMAL_ACTIVE	(1U << ASYNCB_NORMAL_ACTIVE)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #107 lore raw

PATCH 107/240 mtd: require write permissions for locking and badblock ioctls

In reply to Greg Kroah-Hartman

From: Michael Walle <[email protected]>

[ Upstream commit 1e97743fd180981bef5f01402342bb54bf1c6366 ]

MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once.

MEMSETBADBLOCK modifies the bad block table.

Fixes f7e6b19bc764 ("mtd: properly check all write ioctls for permissions")

Signed-off-by Michael Walle <[email protected]>

Reviewed-by Greg Kroah-Hartman <[email protected]>

Acked-by Rafał Miłecki <[email protected]>

Acked-by Richard Weinberger <[email protected]>

Signed-off-by Miquel Raynal <[email protected]>

Link https://lore.kernel.org/linux-mtd/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/mtd/mtdchar.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/mtd/mtdchar.c +4 -4

index 331183548bc5..b43b8edc18ec 100644
@@ -689,16 +689,12 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 	case MEMGETINFO:
 	case MEMREADOOB:
 	case MEMREADOOB64:
-	case MEMLOCK:
-	case MEMUNLOCK:
 	case MEMISLOCKED:
 	case MEMGETOOBSEL:
 	case MEMGETBADBLOCK:
-	case MEMSETBADBLOCK:
 	case OTPSELECT:
 	case OTPGETREGIONCOUNT:
 	case OTPGETREGIONINFO:
-	case OTPLOCK:
 	case ECCGETLAYOUT:
 	case ECCGETSTATS:
 	case MTDFILEMODE:

@@ -709,9 +705,13 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 	/* "dangerous" commands */
 	case MEMERASE:
 	case MEMERASE64:
+	case MEMLOCK:
+	case MEMUNLOCK:
+	case MEMSETBADBLOCK:
 	case MEMWRITEOOB:
 	case MEMWRITEOOB64:
 	case MEMWRITE:
+	case OTPLOCK:
 		if (!(file->f_mode & FMODE_WRITE))
 			return -EPERM;
 		break;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #144 lore raw

PATCH 144/240 liquidio: Fix unintented sign extension of a left shift of a u16

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 298b58f00c0f86868ea717426beb5c1198772f81 ]

The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow.

It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this.

Fix this by casting the port parameter to the macro to a u64 before the shift.

Addresses-Coverity: ("Unintended sign extension")

Fixes 5bc67f587ba7 ("liquidio: CN23XX register definitions")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/cavium/liquidio/cn23xx_pf_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/cavium/liquidio/cn23xx_pf_regs.h +1 -1

index 03d79d95ab75..d7e0d2ce15c1 100644
@@ -526,7 +526,7 @@
 #define    CN23XX_BAR1_INDEX_OFFSET                3
 
 #define    CN23XX_PEM_BAR1_INDEX_REG(port, idx)		\
-		(CN23XX_PEM_BAR1_INDEX_START + ((port) << CN23XX_PEM_OFFSET) + \
+		(CN23XX_PEM_BAR1_INDEX_START + (((u64)port) << CN23XX_PEM_OFFSET) + \
 		 ((idx) << CN23XX_BAR1_INDEX_OFFSET))
 
 /*############################ DPI #########################*/

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #153 lore raw

PATCH 153/240 i2c: sh7760: add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit e5b2e3e742015dd2aa6bc7bcef2cb59b2de1221c ]

The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s.

Fixes a26c20b1fa6d ("i2c: Renesas SH7760 I2C master driver")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-sh7760.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/i2c/busses/i2c-sh7760.c +4 -1

index c2005c789d2b..c79c9f542c5a 100644
@@ -471,7 +471,10 @@ static int sh7760_i2c_probe(struct platform_device *pdev)
 		goto out2;
 	}
 
-	id->irq = platform_get_irq(pdev, 0);
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		return ret;
+	id->irq = ret;
 
 	id->adap.nr = pdev->id;
 	id->adap.algo = &sh7760_i2c_algo;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #155 lore raw

PATCH 155/240 powerpc/pseries: extract host bridge from pci_bus prior to bus removal

In reply to Greg Kroah-Hartman

From: Tyrel Datwyler <[email protected]>

[ Upstream commit 38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 ]

The pci_bus->bridge reference may no longer be valid after pci_bus_remove() resulting in passing a bad value to device_unregister() for the associated bridge device.

Store the host_bridge reference in a separate variable prior to pci_bus_remove().

Fixes 7340056567e3 ("powerpc/pci: Reorder pci bus/bridge unregistration during PHB removal")

Signed-off-by Tyrel Datwyler <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/platforms/pseries/pci_dlpar.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

arch/powerpc/platforms/pseries/pci_dlpar.c +3 -1

index 547fd13e4f8e..35d035d68dce 100644
@@ -66,6 +66,7 @@ EXPORT_SYMBOL_GPL(init_phb_dynamic);
 int remove_phb_dynamic(struct pci_controller *phb)
 {
 	struct pci_bus *b = phb->bus;
+	struct pci_host_bridge *host_bridge = to_pci_host_bridge(b->bridge);
 	struct resource *res;
 	int rc, i;

@@ -92,7 +93,8 @@ int remove_phb_dynamic(struct pci_controller *phb)
 	/* Remove the PCI bus and unregister the bridge device from sysfs */
 	phb->bus = NULL;
 	pci_remove_bus(b);
-	device_unregister(b->bridge);
+	host_bridge->bus = NULL;
+	device_unregister(&host_bridge->dev);
 
 	/* Now release the IO resource */
 	if (res->flags & IORESOURCE_IO)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #154 lore raw

PATCH 154/240 MIPS: pci-legacy: stop using of_pci_range_to_resource

In reply to Greg Kroah-Hartman

From: Ilya Lipnitskiy <[email protected]>

[ Upstream commit 3ecb9dc1581eebecaee56decac70e35365260866 ]

Mirror commit aeba3731b150 ("powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change").

Most MIPS platforms do not define PCI_IOBASE, nor implement pci_address_to_pio(). Moreover, IO_SPACE_LIMIT is 0xffff for most MIPS platforms. of_pci_range_to_resource passes the _start address_ of the IO range into pci_address_to_pio, which then checks it against IO_SPACE_LIMIT and fails, because for MIPS platforms that use pci-legacy (pci-lantiq, pci-rt3883, pci-mt7620), IO ranges start much higher than 0xffff.

In fact, pci-mt7621 in staging already works around this problem, see commit 09dd629eeabb ("staging: mt7621-pci: fix io space and properly set resource limits")

So just stop using of_pci_range_to_resource, which does not work for MIPS.

Fixes PCI errors like:
pci_bus 0000:00: root bus resource [io 0xffffffff]

Fixes 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources")

Signed-off-by Ilya Lipnitskiy <[email protected]>

Cc Liviu Dudau <[email protected]>

Signed-off-by Thomas Bogendoerfer <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/mips/pci/pci-legacy.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

arch/mips/pci/pci-legacy.c +7 -2

index 2d6886f09ba3..009b840ee5ef 100644
@@ -158,8 +158,13 @@ void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
 			res = hose->mem_resource;
 			break;
 		}
-		if (res != NULL)
-			of_pci_range_to_resource(&range, node, res);
+		if (res != NULL) {
+			res->name = node->full_name;
+			res->flags = range.flags;
+			res->start = range.cpu_addr;
+			res->end = range.cpu_addr + range.size - 1;
+			res->parent = res->child = res->sibling = NULL;
+		}
 	}
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #156 lore raw

PATCH 156/240 i2c: sh7760: fix IRQ error path

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit 92dfb27240fea2776f61c5422472cb6defca7767 ]

While adding the invalid IRQ check after calling platform_get_irq(), I managed to overlook that the driver has a complex error path in its probe() method, thus a simple *return* couldn't be used. Use a proper *goto* instead!

Fixes e5b2e3e74201 ("i2c: sh7760: add IRQ check")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-sh7760.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/i2c/busses/i2c-sh7760.c +1 -1

index c79c9f542c5a..319d1fa617c8 100644
@@ -473,7 +473,7 @@ static int sh7760_i2c_probe(struct platform_device *pdev)
 
 	ret = platform_get_irq(pdev, 0);
 	if (ret < 0)
-		return ret;
+		goto out3;
 	id->irq = ret;
 
 	id->adap.nr = pdev->id;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #157 lore raw

PATCH 157/240 mwl8k: Fix a double Free in mwl8k_probe_hw

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

[ Upstream commit a8e083ee8e2a6c94c29733835adae8bf5b832748 ]

In mwl8k_probe_hw, hw->priv->txq is freed at the first time by dma_free_coherent() in the call chain:
if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i).

Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent().

My patch set txq->txd to NULL after the first free to avoid the double free.

Fixes a66098daacee2 ("mwl8k: Marvell TOPDOG wireless driver")

Signed-off-by Lv Yunlong <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/marvell/mwl8k.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/wireless/marvell/mwl8k.c +1 -0

index b1b400b59d86..66cd38d4f199 100644
@@ -1459,6 +1459,7 @@ static int mwl8k_txq_init(struct ieee80211_hw *hw, int index)
 	txq->skb = kcalloc(MWL8K_TX_DESCS, sizeof(*txq->skb), GFP_KERNEL);
 	if (txq->skb == NULL) {
 		pci_free_consistent(priv->pdev, size, txq->txd, txq->txd_dma);
+		txq->txd = NULL;
 		return -ENOMEM;
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #158 lore raw

PATCH 158/240 vsock/vmci: log once the failed queue pair allocation

In reply to Greg Kroah-Hartman

From: Stefano Garzarella <[email protected]>

[ Upstream commit e16edc99d658cd41c60a44cc14d170697aa3271f ]

VMCI feature is not supported in conjunction with the vSphere Fault Tolerance (FT) feature.

VMware Tools can repeatedly try to create a vsock connection. If FT is enabled the kernel logs is flooded with the following messages:

qp_alloc_hypercall result = -20
Could not attach to queue pair with -20

"qp_alloc_hypercall result = -20" was hidden by commit e8266c4c3307 ("VMCI: Stop log spew when qp allocation isn't possible"), but "Could not attach to queue pair with -20" is still there flooding the log.

Since the error message can be useful in some cases, print it only once.

Fixes d021c344051a ("VSOCK: Introduce VM Sockets")

Signed-off-by Stefano Garzarella <[email protected]>

Reviewed-by Jorgen Hansen <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/vmw_vsock/vmci_transport.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

net/vmw_vsock/vmci_transport.c +1 -2

index 102bf9194662..c09efcdf72d2 100644
@@ -593,8 +593,7 @@ vmci_transport_queue_pair_alloc(struct vmci_qp **qpair,
 			       peer, flags, VMCI_NO_PRIVILEGE_FLAGS);
 out:
 	if (err < 0) {
-		pr_err("Could not attach to queue pair with %d\n",
-		       err);
+		pr_err_once("Could not attach to queue pair with %d\n", err);
 		err = vmci_transport_error_to_vsock_error(err);
 	}

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #162 lore raw

PATCH 162/240 powerpc/52xx: Fix an invalid ASM expression (addi used instead of add)

In reply to Greg Kroah-Hartman

From: Christophe Leroy <[email protected]>

[ Upstream commit 8a87a507714386efc39c3ae6fa24d4f79846b522 ]

AS arch/powerpc/platforms/52xx/lite5200_sleep.o
arch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages:
arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression

In the following code, 'addi' is wrong, has to be 'add'

	/* local udelay in sram is needed */
  udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */
	mullw	r12, r12, r11
	mftb	r13	/* start */
	addi	r12, r13, r12 /* end */

Fixes ee983079ce04 ("[POWERPC] MPC5200 low power mode")

Signed-off-by Christophe Leroy <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/cb4cec9131c8577803367f1699209a7e104cec2a.1619025821.git.christophe.leroy@csgroup.eu open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/platforms/52xx/lite5200_sleep.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/platforms/52xx/lite5200_sleep.S +1 -1

index 08ab6fefcf7a..5f44e9223413 100644
@@ -180,7 +180,7 @@ sram_code:
   udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */
 	mullw	r12, r12, r11
 	mftb	r13	/* start */
-	addi	r12, r13, r12 /* end */
+	add	r12, r13, r12 /* end */
     1:
 	mftb	r13	/* current */
 	cmp	cr0, r13, r12

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #159 lore raw

PATCH 159/240 RDMA/i40iw: Fix error unwinding when i40iw_hmc_sd_one fails

In reply to Greg Kroah-Hartman

From: Sindhu Devale <[email protected]>

[ Upstream commit 783a11bf2400e5d5c42a943c3083dc0330751842 ]

When i40iw_hmc_sd_one fails, chunk is freed without the deletion of chunk entry in the PBLE info list.

Fix it by adding the chunk entry to the PBLE info list only after successful addition of SD in i40iw_hmc_sd_one.

This fixes a static checker warning reported here:
https://lore.kernel.org/linux-rdma/YHV4CFXzqTm23AOZ@mwanda/

Fixes 9715830157be ("i40iw: add pble resource files")

Link https://lore.kernel.org/r/[email protected] open here

Reported-by Dan Carpenter <[email protected]>

Signed-off-by Sindhu Devale <[email protected]>

Signed-off-by Shiraz Saleem <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/i40iw/i40iw_pble.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/infiniband/hw/i40iw/i40iw_pble.c +2 -4

index 85993dc44f6e..3fbf7a3b00de 100644
@@ -399,12 +399,9 @@ static enum i40iw_status_code add_pble_pool(struct i40iw_sc_dev *dev,
 	i40iw_debug(dev, I40IW_DEBUG_PBLE, "next_fpm_addr = %llx chunk_size[%u] = 0x%x\n",
 		    pble_rsrc->next_fpm_addr, chunk->size, chunk->size);
 	pble_rsrc->unallocated_pble -= (chunk->size >> 3);
-	list_add(&chunk->list, &pble_rsrc->pinfo.clist);
 	sd_reg_val = (sd_entry_type == I40IW_SD_TYPE_PAGED) ?
 			sd_entry->u.pd_table.pd_page_addr.pa : sd_entry->u.bp.addr.pa;
-	if (sd_entry->valid)
-		return 0;
-	if (dev->is_pf) {
+	if (dev->is_pf && !sd_entry->valid) {
 		ret_code = i40iw_hmc_sd_one(dev, hmc_info->hmc_fn_id,
 					    sd_reg_val, idx->sd_idx,
 					    sd_entry->entry_type, true);

@@ -415,6 +412,7 @@ static enum i40iw_status_code add_pble_pool(struct i40iw_sc_dev *dev,
 	}
 
 	sd_entry->valid = true;
+	list_add(&chunk->list, &pble_rsrc->pinfo.clist);
 	return 0;
  error:
 	kfree(chunk);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #161 lore raw

PATCH 161/240 ath9k: Fix error check in ath9k_hw_read_revisions() for PCI devices

In reply to Greg Kroah-Hartman

From: Toke Høiland-Jørgensen <[email protected]>

[ Upstream commit 7dd9a40fd6e0d0f1fd8e1931c007e080801dfdce ]

When the error check in ath9k_hw_read_revisions() was added, it checked for -EIO which is what ath9k_regread() in the ath9k_htc driver uses. However, for plain ath9k, the register read function uses ioread32(), which just returns -1 on error. So if such a read fails, it still gets passed through and ends up as a weird mac revision in the log output.

Fix this by changing ath9k_regread() to return -1 on error like ioread32() does, and fix the error check to look for that instead of -EIO.

Fixes 2f90c7e5d094 ("ath9k: Check for errors when reading SREV register")

Signed-off-by Toke Høiland-Jørgensen <[email protected]>

Reviewed-by Lorenzo Bianconi <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
 drivers/net/wireless/ath/ath9k/hw.c           | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

drivers/net/wireless/ath/ath9k/htc_drv_init.c +1 -1

index 15a0036dcc6e..09d737f3461b 100644
@@ -246,7 +246,7 @@ static unsigned int ath9k_regread(void *hw_priv, u32 reg_offset)
 	if (unlikely(r)) {
 		ath_dbg(common, WMI, "REGISTER READ FAILED: (0x%04x, %d)\n",
 			reg_offset, r);
-		return -EIO;
+		return -1;
 	}
 
 	return be32_to_cpu(val);

drivers/net/wireless/ath/ath9k/hw.c +1 -1

index e7fca78cdd96..9d664398a41b 100644
@@ -285,7 +285,7 @@ static bool ath9k_hw_read_revisions(struct ath_hw *ah)
 
 	srev = REG_READ(ah, AR_SREV);
 
-	if (srev == -EIO) {
+	if (srev == -1) {
 		ath_err(ath9k_hw_common(ah),
 			"Failed to read SREV register");
 		return false;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #160 lore raw

PATCH 160/240 net: davinci_emac: Fix incorrect masking of tx and rx error channel

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit d83b8aa5207d81f9f6daec9888390f079cc5db3f ]

The bit-masks used for the TXERRCH and RXERRCH (tx and rx error channels) are incorrect and always lead to a zero result. The mask values are currently the incorrect post-right shifted values, fix this by setting them to the currect values.

(I double checked these against the TMS320TCI6482 data sheet, section 5.30, page 127 to ensure I had the correct mask values for the TXERRCH and RXERRCH fields in the MACSTATUS register).

Addresses-Coverity: ("Operands don't affect result")

Fixes a6286ee630f6 ("net: Add TI DaVinci EMAC driver")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/ti/davinci_emac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/ti/davinci_emac.c +2 -2

index 413cf14dbacd..8b7596fef42a 100644
@@ -183,11 +183,11 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
 /* EMAC mac_status register */
 #define EMAC_MACSTATUS_TXERRCODE_MASK	(0xF00000)
 #define EMAC_MACSTATUS_TXERRCODE_SHIFT	(20)
-#define EMAC_MACSTATUS_TXERRCH_MASK	(0x7)
+#define EMAC_MACSTATUS_TXERRCH_MASK	(0x70000)
 #define EMAC_MACSTATUS_TXERRCH_SHIFT	(16)
 #define EMAC_MACSTATUS_RXERRCODE_MASK	(0xF000)
 #define EMAC_MACSTATUS_RXERRCODE_SHIFT	(12)
-#define EMAC_MACSTATUS_RXERRCH_MASK	(0x7)
+#define EMAC_MACSTATUS_RXERRCH_MASK	(0x700)
 #define EMAC_MACSTATUS_RXERRCH_SHIFT	(8)
 
 /* EMAC RX register masks */

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #137 lore raw

PATCH 137/240 HID: plantronics: Workaround for double volume key presses

In reply to Greg Kroah-Hartman

From: Maxim Mikityanskiy <[email protected]>

[ Upstream commit f567d6ef8606fb427636e824c867229ecb5aefab ]

Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice for each volume key press. This patch adds a quirk to hid-plantronics for this product ID, which will ignore the second volume key press if it happens within 5 ms from the last one that was handled.

The patch was tested on the mentioned model only, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected, because the rate is about 3 times per second, which is far less frequent than once in 5 ms.

Fixes 81bb773faed7 ("HID: plantronics: Update to map volume up/down controls")

Signed-off-by Maxim Mikityanskiy <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hid/hid-ids.h         |  1 +
 drivers/hid/hid-plantronics.c | 60 +++++++++++++++++++++++++++++++++--
 include/linux/hid.h           |  2 ++
 3 files changed, 61 insertions(+), 2 deletions(-)

drivers/hid/hid-ids.h +1 -0

index c4a53fc648e9..1f641870d860 100644
@@ -816,6 +816,7 @@
 #define USB_DEVICE_ID_ORTEK_WKB2000	0x2000
 
 #define USB_VENDOR_ID_PLANTRONICS	0x047f
+#define USB_DEVICE_ID_PLANTRONICS_BLACKWIRE_3220_SERIES	0xc056
 
 #define USB_VENDOR_ID_PANASONIC		0x04da
 #define USB_DEVICE_ID_PANABOARD_UBT780	0x1044

drivers/hid/hid-plantronics.c +58 -2

113 lines not on this page · raw message

include/linux/hid.h +2 -0

index 981657075f05..41c372573a28 100644
@@ -248,6 +248,8 @@ struct hid_item {
 #define HID_CP_SELECTION	0x000c0080
 #define HID_CP_MEDIASELECTION	0x000c0087
 #define HID_CP_SELECTDISC	0x000c00ba
+#define HID_CP_VOLUMEUP		0x000c00e9
+#define HID_CP_VOLUMEDOWN	0x000c00ea
 #define HID_CP_PLAYBACKSPEED	0x000c00f1
 #define HID_CP_PROXIMITY	0x000c0109
 #define HID_CP_SPEAKERSYSTEM	0x000c0160

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #138 lore raw

PATCH 138/240 perf symbols: Fix dso__fprintf_symbols_by_name() to return the number of printed chars

In reply to Greg Kroah-Hartman

From: Arnaldo Carvalho de Melo <[email protected]>

[ Upstream commit 210e4c89ef61432040c6cd828fefa441f4887186 ]

The 'ret' variable was initialized to zero but then it was not updated from the fprintf() return, fix it.

Reported-by Yang Li <[email protected]>

cc Alexander Shishkin <[email protected]>

cc Ingo Molnar <[email protected]>

cc Jiri Olsa <[email protected]>

cc Mark Rutland <[email protected]>

cc Namhyung Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Srikar Dronamraju <[email protected]>

Fixes 90f18e63fbd00513 ("perf symbols: List symbols in a dso in ascending name order")

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 tools/perf/util/symbol_fprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/util/symbol_fprintf.c +1 -1

index a680bdaa65dc..060957aeb79a 100644
@@ -64,7 +64,7 @@ size_t dso__fprintf_symbols_by_name(struct dso *dso,
 
 	for (nd = rb_first(&dso->symbol_names[type]); nd; nd = rb_next(nd)) {
 		pos = rb_entry(nd, struct symbol_name_rb_node, rb_node);
-		fprintf(fp, "%s\n", pos->sym.name);
+		ret += fprintf(fp, "%s\n", pos->sym.name);
 	}
 
 	return ret;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #141 lore raw

PATCH 141/240 ALSA: core: remove redundant spin_lock pair in snd_card_disconnect

In reply to Greg Kroah-Hartman

From: Jia Zhou <[email protected]>

[ Upstream commit abc21649b3e5c34b143bf86f0c78e33d5815e250 ]

modification in commit 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") resulting in this problem.

Fixes 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect")

Signed-off-by Jia Zhou <[email protected]>

Signed-off-by Yi Wang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/core/init.c | 2 --
 1 file changed, 2 deletions(-)

sound/core/init.c +0 -2

index 02e96c580cb7..59377e579adb 100644
@@ -406,10 +406,8 @@ int snd_card_disconnect(struct snd_card *card)
 		return 0;
 	}
 	card->shutdown = 1;
-	spin_unlock(&card->files_lock);
 
 	/* replace file->f_op with special dummy operations */
-	spin_lock(&card->files_lock);
 	list_for_each_entry(mfile, &card->files_list, list) {
 		/* it's critical part, use endless loop */
 		/* we have no room to fail */

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #145 lore raw

PATCH 145/240 powerpc/perf: Fix PMU constraint check for EBB events

In reply to Greg Kroah-Hartman

From: Athira Rajeev <[email protected]>

[ Upstream commit 10f8f96179ecc7f69c927f6d231f6d02736cea83 ]

The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same.

Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event.

  [35600.453346] cpu_event_pinne[41326]: illegal instruction (4)
  at 10004a18 nip 10004a18 lr 100049f8 code 1 in
  cpu_event_pinned_vs_ebb_test[10000000+10000]

Test results after the patch:

  $ ./pmu/ebb/cpu_event_pinned_vs_ebb_test
  test: cpu_event_pinned_vs_ebb
  tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty
  Binding to cpu 8
  EBB Handler is at 0x100050c8
  read error on event 0x7fffe6bd4040!
  PM_RUN_INST_CMPL: result 9872 running/enabled 37930432
  success: cpu_event_pinned_vs_ebb

This bug was hidden by other logic until commit 1908dc911792 (perf:
Tweak perf_event_attr::exclusive semantics).

Fixes 4df489991182 ("powerpc/perf: Add power8 EBB support")

Reported-by Thadeu Lima de Souza Cascardo <[email protected]>

Signed-off-by Athira Rajeev <[email protected]>

[mpe: Mention commit 1908dc911792]

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/perf/isa207-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/powerpc/perf/isa207-common.c +2 -2

index 7592a6491a9a..2d3557406424 100644
@@ -139,8 +139,8 @@ ebb_bhrb:
 	 * EBB events are pinned & exclusive, so this should never actually
 	 * hit, but we leave it as a fallback in case.
 	 */
-	mask  |= CNST_EBB_VAL(ebb);
-	value |= CNST_EBB_MASK;
+	mask  |= CNST_EBB_MASK;
+	value |= CNST_EBB_VAL(ebb);
 
 	*maskp = mask;
 	*valp = value;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #163 lore raw

PATCH 163/240 net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

[ Upstream commit 6d72e7c767acbbdd44ebc7d89c6690b405b32b57 ]

In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).

As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.

Fixes b9b17debc69d2 ("net: emac: emac gigabit ethernet controller driver")

Signed-off-by Lv Yunlong <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/qualcomm/emac/emac-mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/net/ethernet/qualcomm/emac/emac-mac.c +3 -1

index 9d223ff65071..882f2b7ec6d1 100644
@@ -1504,6 +1504,7 @@ int emac_mac_tx_buf_send(struct emac_adapter *adpt, struct emac_tx_queue *tx_q,
 {
 	struct emac_tpd tpd;
 	u32 prod_idx;
+	int len;
 
 	memset(&tpd, 0, sizeof(tpd));

@@ -1523,9 +1524,10 @@ int emac_mac_tx_buf_send(struct emac_adapter *adpt, struct emac_tx_queue *tx_q,
 	if (skb_network_offset(skb) != ETH_HLEN)
 		TPD_TYP_SET(&tpd, 1);
 
+	len = skb->len;
 	emac_tx_fill_tpd(adpt, tx_q, skb, &tpd);
 
-	netdev_sent_queue(adpt->netdev, skb->len);
+	netdev_sent_queue(adpt->netdev, len);
 
 	/* Make sure the are enough free descriptors to hold one
 	 * maximum-sized SKB.  We need one desc for each fragment,

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 10:59 UTC #164 lore raw

PATCH 164/240 net:nfc:digital: Fix a double free in digital_tg_recv_dep_req

In reply to Greg Kroah-Hartman

From: Lv Yunlong <[email protected]>

[ Upstream commit 75258586793efc521e5dd52a5bf6c7a4cf7002be ]

In digital_tg_recv_dep_req, it calls nfc_tm_data_received(..,resp). If nfc_tm_data_received() failed, the callee will free the resp via kfree_skb() and return error. But in the exit branch, the resp will be freed again.

My patch sets resp to NULL if nfc_tm_data_received() failed, to avoid the double free.

Fixes 1c7a4c24fbfd9 ("NFC Digital: Add target NFC-DEP support")

Signed-off-by Lv Yunlong <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/nfc/digital_dep.c | 2 ++
 1 file changed, 2 insertions(+)

net/nfc/digital_dep.c +2 -0

index f864ce19e13d..582f97d035ef 100644
@@ -1289,6 +1289,8 @@ static void digital_tg_recv_dep_req(struct nfc_digital_dev *ddev, void *arg,
 	}
 
 	rc = nfc_tm_data_received(ddev->nfc_dev, resp);
+	if (rc)
+		resp = NULL;
 
 exit:
 	kfree_skb(ddev->chaining_skb);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #165 lore raw

PATCH 165/240 kfifo: fix ternary sign extension bugs

In reply to Greg Kroah-Hartman

From: Dan Carpenter <[email protected]>

[ Upstream commit 926ee00ea24320052b46745ef4b00d91c05bd03d ]

The intent with this code was to return negative error codes but instead it returns positives.

The problem is how type promotion works with ternary operations. These functions return long, "ret" is an int and "copied" is a u32. The negative error code is first cast to u32 so it becomes a high positive and then cast to long where it's still a positive.

We could fix this by declaring "ret" as a ssize_t but let's just get rid of the ternaries instead.

Link https://lkml.kernel.org/r/YIE+/cK1tBzSuQPU@mwanda open here

Fixes 5bf2b19320ec ("kfifo: add example files to the kernel sample directory")

Signed-off-by Dan Carpenter <[email protected]>

Cc Stefani Seibold <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 samples/kfifo/bytestream-example.c | 8 ++++++--
 samples/kfifo/inttype-example.c    | 8 ++++++--
 samples/kfifo/record-example.c     | 8 ++++++--
 3 files changed, 18 insertions(+), 6 deletions(-)

samples/kfifo/bytestream-example.c +6 -2

index 2fca916d9edf..a7f5ee8b6edc 100644
@@ -124,8 +124,10 @@ static ssize_t fifo_write(struct file *file, const char __user *buf,
 	ret = kfifo_from_user(&test, buf, count, &copied);
 
 	mutex_unlock(&write_lock);
+	if (ret)
+		return ret;
 
-	return ret ? ret : copied;
+	return copied;
 }
 
 static ssize_t fifo_read(struct file *file, char __user *buf,

@@ -140,8 +142,10 @@ static ssize_t fifo_read(struct file *file, char __user *buf,
 	ret = kfifo_to_user(&test, buf, count, &copied);
 
 	mutex_unlock(&read_lock);
+	if (ret)
+		return ret;
 
-	return ret ? ret : copied;
+	return copied;
 }
 
 static const struct file_operations fifo_fops = {

samples/kfifo/inttype-example.c +6 -2

index 8dc3c2e7105a..a326a37e9163 100644
@@ -117,8 +117,10 @@ static ssize_t fifo_write(struct file *file, const char __user *buf,
 	ret = kfifo_from_user(&test, buf, count, &copied);
 
 	mutex_unlock(&write_lock);
+	if (ret)
+		return ret;
 
-	return ret ? ret : copied;
+	return copied;
 }
 
 static ssize_t fifo_read(struct file *file, char __user *buf,

@@ -133,8 +135,10 @@ static ssize_t fifo_read(struct file *file, char __user *buf,
 	ret = kfifo_to_user(&test, buf, count, &copied);
 
 	mutex_unlock(&read_lock);
+	if (ret)
+		return ret;
 
-	return ret ? ret : copied;
+	return copied;
 }
 
 static const struct file_operations fifo_fops = {

samples/kfifo/record-example.c +6 -2

index 2d7529eeb294..deb87a2e4e6b 100644
@@ -131,8 +131,10 @@ static ssize_t fifo_write(struct file *file, const char __user *buf,
 	ret = kfifo_from_user(&test, buf, count, &copied);
 
 	mutex_unlock(&write_lock);
+	if (ret)
+		return ret;
 
-	return ret ? ret : copied;
+	return copied;
 }
 
 static ssize_t fifo_read(struct file *file, char __user *buf,

@@ -147,8 +149,10 @@ static ssize_t fifo_read(struct file *file, char __user *buf,
 	ret = kfifo_to_user(&test, buf, count, &copied);
 
 	mutex_unlock(&read_lock);
+	if (ret)
+		return ret;
 
-	return ret ? ret : copied;
+	return copied;
 }
 
 static const struct file_operations fifo_fops = {

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #166 lore raw

PATCH 166/240 Revert "net/sctp: fix race condition in sctp_destroy_sock"

In reply to Greg Kroah-Hartman

From: Xin Long <[email protected]>

commit 01bfe5e8e428b475982a98a46cca5755726f3f7f upstream.

This reverts commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b.

This one has to be reverted as it introduced a dead lock, as syzbot reported:

       CPU0                    CPU1
       ----                    ----
  lock(&net->sctp.addr_wq_lock);
                               lock(slock-AF_INET6);
                               lock(&net->sctp.addr_wq_lock);

lock(slock-AF_INET6);

CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1 is that of sctp_close().

The original issue this commit fixed will be fixed in the next patch.

Reported-by [email protected]

Signed-off-by Xin Long <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/sctp/socket.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

net/sctp/socket.c +8 -5

@@ -1582,9 +1582,11 @@ static void sctp_close(struct sock *sk,
 
 	/* Supposedly, no process has access to the socket, but
 	 * the net layers still may.
+	 * Also, sctp_destroy_sock() needs to be called with addr_wq_lock
+	 * held and that should be grabbed before socket lock.
 	 */
-	local_bh_disable();
-	bh_lock_sock(sk);
+	spin_lock_bh(&net->sctp.addr_wq_lock);
+	bh_lock_sock_nested(sk);
 
 	/* Hold the sock, since sk_common_release() will put sock_put()
 	 * and we have just a little more cleanup.

@@ -1593,7 +1595,7 @@ static void sctp_close(struct sock *sk,
 	sk_common_release(sk);
 
 	bh_unlock_sock(sk);
-	local_bh_enable();
+	spin_unlock_bh(&net->sctp.addr_wq_lock);
 
 	sock_put(sk);

@@ -4260,6 +4262,9 @@ static int sctp_init_sock(struct sock *s
 	sk_sockets_allocated_inc(sk);
 	sock_prot_inuse_add(net, sk->sk_prot, 1);
 
+	/* Nothing can fail after this block, otherwise
+	 * sctp_destroy_sock() will be called without addr_wq_lock held
+	 */
 	if (net->sctp.default_auto_asconf) {
 		spin_lock(&sock_net(sk)->sctp.addr_wq_lock);
 		list_add_tail(&sp->auto_asconf_list,

@@ -4294,9 +4299,7 @@ static void sctp_destroy_sock(struct soc
 
 	if (sp->do_auto_asconf) {
 		sp->do_auto_asconf = 0;
-		spin_lock_bh(&sock_net(sk)->sctp.addr_wq_lock);
 		list_del(&sp->auto_asconf_list);
-		spin_unlock_bh(&sock_net(sk)->sctp.addr_wq_lock);
 	}
 	sctp_endpoint_free(sp->ep);
 	local_bh_disable();

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #167 lore raw

PATCH 167/240 sctp: delay auto_asconf init until binding the first addr

In reply to Greg Kroah-Hartman

From: Xin Long <[email protected]>

commit 34e5b01186858b36c4d7c87e1a025071e8e2401f upstream.

As Or Cohen described:

If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock held and sp->do_auto_asconf is true, then an element is removed from the auto_asconf_splist without any proper locking.

This can happen in the following functions:
1. In sctp_accept, if sctp_sock_migrate fails.
2. In inet_create or inet6_create, if there is a bpf program attached to BPF_CGROUP_INET_SOCK_CREATE which denies creation of the sctp socket.

This patch is to fix it by moving the auto_asconf init out of sctp_init_sock(), by which inet_create()/inet6_create() won't need to operate it in sctp_destroy_sock() when calling sk_common_release().

It also makes more sense to do auto_asconf init while binding the first addr, as auto_asconf actually requires an ANY addr bind, see it in sctp_addr_wq_timeout_handler().

This addresses CVE-2021-23133.

Fixes 610236587600 ("bpf: Add new cgroup attach type to enable sock modifications")

Reported-by Or Cohen <[email protected]>

Signed-off-by Xin Long <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/sctp/socket.c |   31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

net/sctp/socket.c +17 ~~-14~~

@@ -367,6 +367,18 @@ static struct sctp_af *sctp_sockaddr_af(
 	return af;
 }
 
+static void sctp_auto_asconf_init(struct sctp_sock *sp)
+{
+	struct net *net = sock_net(&sp->inet.sk);
+
+	if (net->sctp.default_auto_asconf) {
+		spin_lock(&net->sctp.addr_wq_lock);
+		list_add_tail(&sp->auto_asconf_list, &net->sctp.auto_asconf_splist);
+		spin_unlock(&net->sctp.addr_wq_lock);
+		sp->do_auto_asconf = 1;
+	}
+}
+
 /* Bind a local address either to an endpoint or to an association.  */
 static int sctp_do_bind(struct sock *sk, union sctp_addr *addr, int len)
 {

@@ -429,8 +441,10 @@ static int sctp_do_bind(struct sock *sk,
 	}
 
 	/* Refresh ephemeral port.  */
-	if (!bp->port)
+	if (!bp->port) {
 		bp->port = inet_sk(sk)->inet_num;
+		sctp_auto_asconf_init(sp);
+	}
 
 	/* Add the address to the bind address list.
 	 * Use GFP_ATOMIC since BHs will be disabled.

@@ -4262,19 +4276,6 @@ static int sctp_init_sock(struct sock *s
 	sk_sockets_allocated_inc(sk);
 	sock_prot_inuse_add(net, sk->sk_prot, 1);
 
-	/* Nothing can fail after this block, otherwise
-	 * sctp_destroy_sock() will be called without addr_wq_lock held
-	 */
-	if (net->sctp.default_auto_asconf) {
-		spin_lock(&sock_net(sk)->sctp.addr_wq_lock);
-		list_add_tail(&sp->auto_asconf_list,
-		    &net->sctp.auto_asconf_splist);
-		sp->do_auto_asconf = 1;
-		spin_unlock(&sock_net(sk)->sctp.addr_wq_lock);
-	} else {
-		sp->do_auto_asconf = 0;
-	}
-
 	local_bh_enable();
 
 	return 0;

@@ -7817,6 +7818,8 @@ static void sctp_sock_migrate(struct soc
 	sctp_bind_addr_dup(&newsp->ep->base.bind_addr,
 				&oldsp->ep->base.bind_addr, GFP_KERNEL);
 
+	sctp_auto_asconf_init(newsp);
+
 	/* Move any messages in the old socket's receive queue that are for the
 	 * peeled off association to the new socket's receive queue.
 	 */

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #169 lore raw

PATCH 169/240 Revert "fdt: Properly handle "no-map" field in the memory region"

In reply to Greg Kroah-Hartman

From: Quentin Perret <[email protected]>

This reverts commit 86ac82a7c708acf4738c396228be7b8fdaae4d99. It is not really a fix, and the backport misses dependencies, which breaks existing platforms.

Reported-by Alexandre TORGUE <[email protected]>

Signed-off-by Quentin Perret <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/of/fdt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/of/fdt.c +1 -1

@@ -1159,7 +1159,7 @@ int __init __weak early_init_dt_reserve_
 					phys_addr_t size, bool nomap)
 {
 	if (nomap)
-		return memblock_mark_nomap(base, size);
+		return memblock_remove(base, size);
 	return memblock_reserve(base, size);
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #168 lore raw

PATCH 168/240 Revert "of/fdt: Make sure no-map does not remove already reserved regions"

In reply to Greg Kroah-Hartman

From: Quentin Perret <[email protected]>

This reverts commit 666ae7c255f9eb7a8fd8e55641542f3624a78b43. It is not really a fix, and the backport misses dependencies, which breaks existing platforms.

Reported-by Alexandre TORGUE <[email protected]>

Signed-off-by Quentin Perret <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/of/fdt.c |   10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

drivers/of/fdt.c +1 -9

@@ -1158,16 +1158,8 @@ void __init __weak early_init_dt_add_mem
 int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
 					phys_addr_t size, bool nomap)
 {
-	if (nomap) {
-		/*
-		 * If the memory is already reserved (by another region), we
-		 * should not allow it to be marked nomap.
-		 */
-		if (memblock_is_region_reserved(base, size))
-			return -EBUSY;
-
+	if (nomap)
 		return memblock_mark_nomap(base, size);
-	}
 	return memblock_reserve(base, size);
 }

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #170 lore raw

PATCH 170/240 fs: dlm: fix debugfs dump

In reply to Greg Kroah-Hartman

From: Alexander Aring <[email protected]>

[ Upstream commit 92c48950b43f4a767388cf87709d8687151a641f ]

This patch fixes the following message which randomly pops up during glocktop call:

seq_file: buggy .next function table_seq_next did not update position index

The issue is that seq_read_iter() in fs/seq_file.c also needs an increment of the index in an non next record case as well which this patch fixes otherwise seq_read_iter() will print out the above message.

Signed-off-by Alexander Aring <[email protected]>

Signed-off-by David Teigland <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/dlm/debug_fs.c | 1 +
 1 file changed, 1 insertion(+)

fs/dlm/debug_fs.c +1 -0

index 466f7d60edc2..fabce23fdbac 100644
@@ -545,6 +545,7 @@ static void *table_seq_next(struct seq_file *seq, void *iter_ptr, loff_t *pos)
 
 		if (bucket >= ls->ls_rsbtbl_size) {
 			kfree(ri);
+			++*pos;
 			return NULL;
 		}
 		tree = toss ? &ls->ls_rsbtbl[bucket].toss : &ls->ls_rsbtbl[bucket].keep;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #171 lore raw

PATCH 171/240 tipc: convert dest nodes address to network order

In reply to Greg Kroah-Hartman

From: Hoang Le <[email protected]>

[ Upstream commit 1980d37565061ab44bdc2f9e4da477d3b9752e81 ]

(struct tipc_link_info)->dest is in network order (__be32), so we must convert the value to network order before assigning. The problem detected by sparse:

net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types)
net/tipc/netlink_compat.c:699:24: expected restricted __be32 [usertype] dest
net/tipc/netlink_compat.c:699:24: got int

Acked-by Jon Maloy <[email protected]>

Signed-off-by Hoang Le <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/tipc/netlink_compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/tipc/netlink_compat.c +1 -1

index 403be9bfd8d1..69151de9657c 100644
@@ -662,7 +662,7 @@ static int tipc_nl_compat_link_dump(struct tipc_nl_compat_msg *msg,
 	if (err)
 		return err;
 
-	link_info.dest = nla_get_flag(link[TIPC_NLA_LINK_DEST]);
+	link_info.dest = htonl(nla_get_flag(link[TIPC_NLA_LINK_DEST]));
 	link_info.up = htonl(nla_get_flag(link[TIPC_NLA_LINK_UP]));
 	nla_strlcpy(link_info.str, link[TIPC_NLA_LINK_NAME],
 		    TIPC_MAX_LINK_NAME);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #146 lore raw

PATCH 146/240 powerpc: iommu: fix build when neither PCI or IBMVIO is set

In reply to Greg Kroah-Hartman

From: Randy Dunlap <[email protected]>

[ Upstream commit b27dadecdf9102838331b9a0b41ffc1cfe288154 ]

When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a build error. The fault injection code is not useful in that kernel config, so make the FAIL_IOMMU option depend on PCI || IBMVIO.

Prevents this build error (warning escalated to error):
../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier' defined but not used [-Werror=unused-variable]
178 | static struct notifier_block fail_iommu_bus_notifier = {

Fixes d6b9a81b2a45 ("powerpc: IOMMU fault injection")

Reported-by kernel test robot <[email protected]>

Signed-off-by Randy Dunlap <[email protected]>

Acked-by Randy Dunlap <[email protected]> # build-tested

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/Kconfig.debug | 1 +
 1 file changed, 1 insertion(+)

arch/powerpc/Kconfig.debug +1 -0

index 63292f64b25a..f66326339bc8 100644
@@ -348,6 +348,7 @@ config PPC_EARLY_DEBUG_CPM_ADDR
 config FAIL_IOMMU
 	bool "Fault-injection capability for IOMMU"
 	depends on FAULT_INJECTION
+	depends on PCI || IBMVIO
 	help
 	  Provide fault-injection capability for IOMMU. Each device can
 	  be selectively enabled via the fail_iommu property.

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #172 lore raw

PATCH 172/240 net: stmmac: Set FIFO sizes for ipq806x

In reply to Greg Kroah-Hartman

From: Jonathan McDowell <[email protected]>

[ Upstream commit e127906b68b49ddb3ecba39ffa36a329c48197d3 ]

Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values") started using the TX FIFO size to verify what counts as a valid MTU request for the stmmac driver. This is unset for the ipq806x variant. Looking at older patches for this it seems the RX + TXs buffers can be up to 8k, so set appropriately.

(I sent this as an RFC patch in June last year, but received no replies. I've been running with this on my hardware (a MikroTik RB3011) since then with larger MTUs to support both the internal qca8k switch and VLANs with no problems. Without the patch it's impossible to set the larger MTU required to support this.)

Signed-off-by Jonathan McDowell <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c +2 -0

index 1924788d28da..f4ff43a1b5ba 100644
@@ -363,6 +363,8 @@ static int ipq806x_gmac_probe(struct platform_device *pdev)
 	plat_dat->bsp_priv = gmac;
 	plat_dat->fix_mac_speed = ipq806x_gmac_fix_mac_speed;
 	plat_dat->multicast_filter_bins = 0;
+	plat_dat->tx_fifo_size = 8192;
+	plat_dat->rx_fifo_size = 8192;
 
 	err = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
 	if (err)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #173 lore raw

PATCH 173/240 ALSA: hdsp: dont disable if not enabled

In reply to Greg Kroah-Hartman

From: Tong Zhang <[email protected]>

[ Upstream commit 507cdb9adba006a7798c358456426e1aea3d9c4f ]

hdsp wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable.

[    1.758292] snd_hdsp 0000:00:03.0: disabling already-disabled device
[    1.758327] WARNING: CPU: 0 PID: 180 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0
[    1.766985] Call Trace:
[    1.767121]  snd_hdsp_card_free+0x94/0xf0 [snd_hdsp]
[    1.767388]  release_card_device+0x4b/0x80 [snd]
[    1.767639]  device_release+0x3b/0xa0
[    1.767838]  kobject_put+0x94/0x1b0
[    1.768027]  put_device+0x13/0x20
[    1.768207]  snd_card_free+0x61/0x90 [snd]
[    1.768430]  snd_hdsp_probe+0x524/0x5e0 [snd_hdsp]

Signed-off-by Tong Zhang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/rme9652/hdsp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/pci/rme9652/hdsp.c +2 -1

index b044dea3c815..9843954698f4 100644
@@ -5314,7 +5314,8 @@ static int snd_hdsp_free(struct hdsp *hdsp)
 	if (hdsp->port)
 		pci_release_regions(hdsp->pci);
 
-	pci_disable_device(hdsp->pci);
+	if (pci_is_enabled(hdsp->pci))
+		pci_disable_device(hdsp->pci);
 	return 0;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #174 lore raw

PATCH 174/240 ALSA: hdspm: dont disable if not enabled

In reply to Greg Kroah-Hartman

From: Tong Zhang <[email protected]>

[ Upstream commit 790f5719b85e12e10c41753b864e74249585ed08 ]

hdspm wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable.

[    1.786391] snd_hdspm 0000:00:03.0: disabling already-disabled device
[    1.786400] WARNING: CPU: 0 PID: 182 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0
[    1.795181] Call Trace:
[    1.795320]  snd_hdspm_card_free+0x58/0xa0 [snd_hdspm]
[    1.795595]  release_card_device+0x4b/0x80 [snd]
[    1.795860]  device_release+0x3b/0xa0
[    1.796072]  kobject_put+0x94/0x1b0
[    1.796260]  put_device+0x13/0x20
[    1.796438]  snd_card_free+0x61/0x90 [snd]
[    1.796659]  snd_hdspm_probe+0x97b/0x1440 [snd_hdspm]

Signed-off-by Tong Zhang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/rme9652/hdspm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/pci/rme9652/hdspm.c +2 -1

index 9899ef4c7efa..a88a81fc638a 100644
@@ -6912,7 +6912,8 @@ static int snd_hdspm_free(struct hdspm * hdspm)
 	if (hdspm->port)
 		pci_release_regions(hdspm->pci);
 
-	pci_disable_device(hdspm->pci);
+	if (pci_is_enabled(hdspm->pci))
+		pci_disable_device(hdspm->pci);
 	return 0;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #175 lore raw

PATCH 175/240 ALSA: rme9652: dont disable if not enabled

In reply to Greg Kroah-Hartman

From: Tong Zhang <[email protected]>

[ Upstream commit f57a741874bb6995089020e97a1dcdf9b165dcbe ]

rme9652 wants to disable a not enabled pci device, which makes kernel throw a warning. Make sure the device is enabled before calling disable.

[    1.751595] snd_rme9652 0000:00:03.0: disabling already-disabled device
[    1.751605] WARNING: CPU: 0 PID: 174 at drivers/pci/pci.c:2146 pci_disable_device+0x91/0xb0
[    1.759968] Call Trace:
[    1.760145]  snd_rme9652_card_free+0x76/0xa0 [snd_rme9652]
[    1.760434]  release_card_device+0x4b/0x80 [snd]
[    1.760679]  device_release+0x3b/0xa0
[    1.760874]  kobject_put+0x94/0x1b0
[    1.761059]  put_device+0x13/0x20
[    1.761235]  snd_card_free+0x61/0x90 [snd]
[    1.761454]  snd_rme9652_probe+0x3be/0x700 [snd_rme9652]

Signed-off-by Tong Zhang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/rme9652/rme9652.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/pci/rme9652/rme9652.c +2 -1

index a76b1f147660..67bd75fbdc7e 100644
@@ -1761,7 +1761,8 @@ static int snd_rme9652_free(struct snd_rme9652 *rme9652)
 	if (rme9652->port)
 		pci_release_regions(rme9652->pci);
 
-	pci_disable_device(rme9652->pci);
+	if (pci_is_enabled(rme9652->pci))
+		pci_disable_device(rme9652->pci);
 	return 0;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:00 UTC #176 lore raw

PATCH 176/240 Bluetooth: Set CONF_NOT_COMPLETE as l2cap_chan default

In reply to Greg Kroah-Hartman

From: Archie Pusaka <[email protected]>

[ Upstream commit 3a9d54b1947ecea8eea9a902c0b7eb58a98add8a ]

Currently l2cap_chan_set_defaults() reset chan->conf_state to zero. However, there is a flag CONF_NOT_COMPLETE which is set when creating the l2cap_chan. It is suggested that the flag should be cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults() is called, l2cap_chan is not yet ready. Therefore, we must set this flag as the default.

Example crash call trace:

__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0xc4/0x118 lib/dump_stack.c:56
panic+0x1c6/0x38b kernel/panic.c:117
__warn+0x170/0x1b9 kernel/panic.c:471
warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494
debug_print_object+0x175/0x193 lib/debugobjects.c:260
debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614
debug_timer_assert_init kernel/time/timer.c:629 [inline]
debug_assert_init kernel/time/timer.c:677 [inline]
del_timer+0x7c/0x179 kernel/time/timer.c:1034
try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230
cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929
l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834
l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640
l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756
l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174
l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217
__sock_release+0xda/0x217 net/socket.c:580
sock_close+0x1b/0x1f net/socket.c:1039
__fput+0x322/0x55c fs/file_table.c:208
____fput+0x17/0x19 fs/file_table.c:244
task_work_run+0x19b/0x1d3 kernel/task_work.c:115
exit_task_work include/linux/task_work.h:21 [inline]
do_exit+0xe4c/0x204a kernel/exit.c:766
do_group_exit+0x291/0x291 kernel/exit.c:891
get_signal+0x749/0x1093 kernel/signal.c:2396
do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737
exit_to_usermode_loop arch/x86/entry/common.c:243 [inline]
prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277
syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348
int_ret_from_sys_call+0x25/0xa3

Signed-off-by Archie Pusaka <[email protected]>

Reported-by [email protected]

Reviewed-by Alain Michaud <[email protected]>

Reviewed-by Abhishek Pandit-Subedi <[email protected]>

Reviewed-by Guenter Roeck <[email protected]>

Signed-off-by Marcel Holtmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/bluetooth/l2cap_core.c | 2 ++
 1 file changed, 2 insertions(+)

net/bluetooth/l2cap_core.c +2 -0

index b96818cda12d..d586caaa3af4 100644
@@ -510,7 +510,9 @@ void l2cap_chan_set_defaults(struct l2cap_chan *chan)
 	chan->flush_to = L2CAP_DEFAULT_FLUSH_TO;
 	chan->retrans_timeout = L2CAP_DEFAULT_RETRANS_TO;
 	chan->monitor_timeout = L2CAP_DEFAULT_MONITOR_TO;
+
 	chan->conf_state = 0;
+	set_bit(CONF_NOT_COMPLETE, &chan->conf_state);
 
 	set_bit(FLAG_FORCE_ACTIVE, &chan->flags);
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #177 lore raw

PATCH 177/240 Bluetooth: initialize skb_queue_head at l2cap_chan_create()

In reply to Greg Kroah-Hartman

From: Tetsuo Handa <[email protected]>

[ Upstream commit be8597239379f0f53c9710dd6ab551bbf535bec6 ]

syzbot is hitting "INFO: trying to register non-static key." message [1], for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when l2cap_chan_del() is called due to e.g. timeout.

Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create() immediately after "struct l2cap_chan" is allocated using kzalloc(), let's as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there.

[1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842

Reported-and-tested-by syzbot <[email protected]>

Signed-off-by Tetsuo Handa <[email protected]>

Signed-off-by Marcel Holtmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/bluetooth/l2cap_core.c | 2 ++
 1 file changed, 2 insertions(+)

net/bluetooth/l2cap_core.c +2 -0

index d586caaa3af4..204b6ebd2a24 100644
@@ -445,6 +445,8 @@ struct l2cap_chan *l2cap_chan_create(void)
 	if (!chan)
 		return NULL;
 
+	skb_queue_head_init(&chan->tx_q);
+	skb_queue_head_init(&chan->srej_q);
 	mutex_init(&chan->lock);
 
 	/* Set default lock nesting level */

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #147 lore raw

PATCH 147/240 mac80211: bail out if cipher schemes are invalid

In reply to Greg Kroah-Hartman

From: Johannes Berg <[email protected]>

[ Upstream commit db878e27a98106a70315d264cc92230d84009e72 ]

If any of the cipher schemes specified by the driver are invalid, bail out and fail the registration rather than just warning. Otherwise, we might later crash when we try to use the invalid cipher scheme, e.g. if the hdr_len is (significantly) less than the pn_offs + pn_len, we'd have an out-of-bounds access in RX validation.

Fixes 2475b1cc0d52 ("mac80211: add generic cipher scheme support")

Link https://lore.kernel.org/r/20210408143149.38a3a13a1b19.I6b7f5790fa0958ed8049cf02ac2a535c61e9bc96@changeid open here

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mac80211/main.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

net/mac80211/main.c +5 -2

index f31fd21d59ba..5f8c6f9563b0 100644
@@ -1036,8 +1036,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	if (local->hw.wiphy->max_scan_ie_len)
 		local->hw.wiphy->max_scan_ie_len -= local->scan_ies_len;
 
-	WARN_ON(!ieee80211_cs_list_valid(local->hw.cipher_schemes,
-					 local->hw.n_cipher_schemes));
+	if (WARN_ON(!ieee80211_cs_list_valid(local->hw.cipher_schemes,
+					     local->hw.n_cipher_schemes))) {
+		result = -EINVAL;
+		goto fail_workqueue;
+	}
 
 	result = ieee80211_init_cipher_suites(local);
 	if (result < 0)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #178 lore raw

PATCH 178/240 ip6_vti: proper dev_{hold|put} in ndo_[un]init methods

In reply to Greg Kroah-Hartman

From: Eric Dumazet <[email protected]>

[ Upstream commit 40cb881b5aaa0b69a7d93dec8440d5c62dae299f ]

After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1]

Issue here is that:

- all dev_put() should be paired with a corresponding prior dev_hold().

- A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0.

Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon.

Therefore, we need to move dev_hold() call from
vti6_tnl_create2() to vti6_dev_init_gen()

[1]

WARNING: CPU: 0 PID: 15951 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 15951 Comm: syz-executor.3 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58
RSP: 0018:ffffc90001eaef28 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520003d5dd7
RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff88801bb1c568
R13: ffff88801f69e800 R14: 00000000ffffffff R15: ffff888050889d40
FS:  00007fc79314e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1c1ff47108 CR3: 0000000020fd5000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __refcount_dec include/linux/refcount.h:344 [inline]
 refcount_dec include/linux/refcount.h:359 [inline]
 dev_put include/linux/netdevice.h:4135 [inline]
 vti6_dev_uninit+0x31a/0x360 net/ipv6/ip6_vti.c:297
 register_netdevice+0xadf/0x1500 net/core/dev.c:10308
 vti6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_vti.c:190
 vti6_newlink+0x9d/0xd0 net/ipv6/ip6_vti.c:1020
 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443
 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491
 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
 sock_sendmsg_nosec net/socket.c:654 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:674
 ____sys_sendmsg+0x331/0x810 net/socket.c:2350
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
 __sys_sendmmsg+0x195/0x470 net/socket.c:2490
 __do_sys_sendmmsg net/socket.c:2519 [inline]
 __se_sys_sendmmsg net/socket.c:2516 [inline]
 __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2516

Signed-off-by Eric Dumazet <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv6/ip6_vti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/ipv6/ip6_vti.c +1 -1

index b9f5155a77ef..d20ea696ecaa 100644
@@ -196,7 +196,6 @@ static int vti6_tnl_create2(struct net_device *dev)
 
 	strcpy(t->parms.name, dev->name);
 
-	dev_hold(dev);
 	vti6_tnl_link(ip6n, t);
 
 	return 0;

@@ -914,6 +913,7 @@ static inline int vti6_dev_init_gen(struct net_device *dev)
 	dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
 	if (!dev->tstats)
 		return -ENOMEM;
+	dev_hold(dev);
 	return 0;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #148 lore raw

PATCH 148/240 mt7601u: fix always true expression

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 87fce88658ba047ae62e83497d3f3c5dc22fa6f9 ]

Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix.

Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration.

Addresses-Coverity: ("Logical vs. bitwise operator")

Fixes c869f77d6abb ("add mt7601u driver")

Signed-off-by Colin Ian King <[email protected]>

Acked-by Jakub Kicinski <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/mediatek/mt7601u/eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/mediatek/mt7601u/eeprom.c +1 -1

index da6faea092d6..80d0f64205f8 100644
@@ -106,7 +106,7 @@ mt7601u_has_tssi(struct mt7601u_dev *dev, u8 *eeprom)
 {
 	u16 nic_conf1 = get_unaligned_le16(eeprom + MT_EE_NIC_CONF_1);
 
-	return ~nic_conf1 && (nic_conf1 & MT_EE_NIC_CONF_1_TX_ALC_EN);
+	return (u16)~nic_conf1 && (nic_conf1 & MT_EE_NIC_CONF_1_TX_ALC_EN);
 }
 
 static void

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #149 lore raw

PATCH 149/240 net: thunderx: Fix unintentional sign extension issue

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit e701a25840360706fe4cf5de0015913ca19c274b ]

The shifting of the u8 integers rq->caching by 26 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that rq->caching is greater than 0x1f then all then all the upper 32 bits of the u64 end up as also being set because of the int sign-extension. Fix this by casting the u8 values to a u64 before the 26 bit left shift.

Addresses-Coverity: ("Unintended sign extension")

Fixes 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/cavium/thunder/nicvf_queues.c +1 -1

index 747ef0882976..8f3d544bec0c 100644
@@ -537,7 +537,7 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
 	mbx.rq.msg = NIC_MBOX_MSG_RQ_CFG;
 	mbx.rq.qs_num = qs->vnic_id;
 	mbx.rq.rq_num = qidx;
-	mbx.rq.cfg = (rq->caching << 26) | (rq->cq_qs << 19) |
+	mbx.rq.cfg = ((u64)rq->caching << 26) | (rq->cq_qs << 19) |
 			  (rq->cq_idx << 16) | (rq->cont_rbdr_qs << 9) |
 			  (rq->cont_qs_rbdr_idx << 8) |
 			  (rq->start_rbdr_qs << 1) | (rq->start_qs_rbdr_idx);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #150 lore raw

PATCH 150/240 i2c: cadence: add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit 5581c2c5d02bc63a0edb53e061c8e97cd490646e ]

Fixes df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-cadence.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/i2c/busses/i2c-cadence.c +4 -1

index 45d6771fac8c..23ee1a423654 100644
@@ -908,7 +908,10 @@ static int cdns_i2c_probe(struct platform_device *pdev)
 	if (IS_ERR(id->membase))
 		return PTR_ERR(id->membase);
 
-	id->irq = platform_get_irq(pdev, 0);
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		return ret;
+	id->irq = ret;
 
 	id->adap.owner = THIS_MODULE;
 	id->adap.dev.of_node = pdev->dev.of_node;

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #152 lore raw

PATCH 152/240 i2c: jz4780: add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit c5e5f7a8d931fb4beba245bdbc94734175fda9de ]

Fixes ba92222ed63a ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-jz4780.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/i2c/busses/i2c-jz4780.c +4 -1

index 41ca9ff7b5da..4dd800c0db14 100644
@@ -760,7 +760,10 @@ static int jz4780_i2c_probe(struct platform_device *pdev)
 
 	jz4780_i2c_writew(i2c, JZ4780_I2C_INTM, 0x0);
 
-	i2c->irq = platform_get_irq(pdev, 0);
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		goto err;
+	i2c->irq = ret;
 	ret = devm_request_irq(&pdev->dev, i2c->irq, jz4780_i2c_irq, 0,
 			       dev_name(&pdev->dev), i2c);
 	if (ret)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:01 UTC #151 lore raw

PATCH 151/240 i2c: emev2: add IRQ check

In reply to Greg Kroah-Hartman

From: Sergey Shtylyov <[email protected]>

[ Upstream commit bb6129c32867baa7988f7fd2066cf18ed662d240 ]

Fixes 5faf6e1f58b4 ("i2c: emev2: add driver")

Signed-off-by Sergey Shtylyov <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-emev2.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/i2c/busses/i2c-emev2.c +4 -1

index 0218ba6eb26a..ad33c1e3a30f 100644
@@ -398,7 +398,10 @@ static int em_i2c_probe(struct platform_device *pdev)
 
 	em_i2c_reset(&priv->adap);
 
-	priv->irq = platform_get_irq(pdev, 0);
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		goto err_clk;
+	priv->irq = ret;
 	ret = devm_request_irq(&pdev->dev, priv->irq, em_i2c_irq_handler, 0,
 				"em_i2c", priv);
 	if (ret)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:02 UTC #143 lore raw

PATCH 143/240 ALSA: usb-audio: Add error checks for usb_driver_claim_interface() calls

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

[ Upstream commit 5fb45414ae03421255593fd5556aa2d1d82303aa ]

There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks.

Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability.

Reported-by coverity-bot <[email protected]>

Addresses-Coverity-ID: 1475943 ("Error handling issues")
Addresses-Coverity-ID: 1475944 ("Error handling issues")
Addresses-Coverity-ID: 1475945 ("Error handling issues")

Fixes b1ce7ba619d9 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once")

Fixes e5779998bf8b ("ALSA: usb-audio: refactor code")

Link https://lore.kernel.org/r/202104051059.FB7F3016@keescook open here

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/usb/card.c     | 14 +++++++-------
 sound/usb/quirks.c   | 16 ++++++++++++----
 sound/usb/usbaudio.h |  2 ++
 3 files changed, 21 insertions(+), 11 deletions(-)

sound/usb/card.c +7 -7

index 023a36a4922b..6c5be4e3cb9d 100644
@@ -183,9 +183,8 @@ static int snd_usb_create_stream(struct snd_usb_audio *chip, int ctrlif, int int
 				ctrlif, interface);
 			return -EINVAL;
 		}
-		usb_driver_claim_interface(&usb_audio_driver, iface, (void *)-1L);
-
-		return 0;
+		return usb_driver_claim_interface(&usb_audio_driver, iface,
+						  USB_AUDIO_IFACE_UNUSED);
 	}
 
 	if ((altsd->bInterfaceClass != USB_CLASS_AUDIO &&

@@ -205,7 +204,8 @@ static int snd_usb_create_stream(struct snd_usb_audio *chip, int ctrlif, int int
 
 	if (! snd_usb_parse_audio_interface(chip, interface)) {
 		usb_set_interface(dev, interface, 0); /* reset the current interface */
-		usb_driver_claim_interface(&usb_audio_driver, iface, (void *)-1L);
+		return usb_driver_claim_interface(&usb_audio_driver, iface,
+						  USB_AUDIO_IFACE_UNUSED);
 	}
 
 	return 0;

@@ -665,7 +665,7 @@ static void usb_audio_disconnect(struct usb_interface *intf)
 	struct snd_card *card;
 	struct list_head *p;
 
-	if (chip == (void *)-1L)
+	if (chip == USB_AUDIO_IFACE_UNUSED)
 		return;
 
 	card = chip->card;

@@ -765,7 +765,7 @@ static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
 	struct usb_mixer_interface *mixer;
 	struct list_head *p;
 
-	if (chip == (void *)-1L)
+	if (chip == USB_AUDIO_IFACE_UNUSED)
 		return 0;
 
 	if (!chip->num_suspended_intf++) {

@@ -795,7 +795,7 @@ static int __usb_audio_resume(struct usb_interface *intf, bool reset_resume)
 	struct list_head *p;
 	int err = 0;
 
-	if (chip == (void *)-1L)
+	if (chip == USB_AUDIO_IFACE_UNUSED)
 		return 0;
 
 	atomic_inc(&chip->active); /* avoid autopm */

sound/usb/quirks.c +12 -4

index 6b9e6b57d58d..02b4d0638e00 100644
@@ -66,8 +66,12 @@ static int create_composite_quirk(struct snd_usb_audio *chip,
 		if (!iface)
 			continue;
 		if (quirk->ifnum != probed_ifnum &&
-		    !usb_interface_claimed(iface))
-			usb_driver_claim_interface(driver, iface, (void *)-1L);
+		    !usb_interface_claimed(iface)) {
+			err = usb_driver_claim_interface(driver, iface,
+							 USB_AUDIO_IFACE_UNUSED);
+			if (err < 0)
+				return err;
+		}
 	}
 
 	return 0;

@@ -399,8 +403,12 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip,
 			continue;
 
 		err = create_autodetect_quirk(chip, iface, driver);
-		if (err >= 0)
-			usb_driver_claim_interface(driver, iface, (void *)-1L);
+		if (err >= 0) {
+			err = usb_driver_claim_interface(driver, iface,
+							 USB_AUDIO_IFACE_UNUSED);
+			if (err < 0)
+				return err;
+		}
 	}
 
 	return 0;

sound/usb/usbaudio.h +2 -0

index f4ee83c8e0b2..62456a806bb4 100644
@@ -63,6 +63,8 @@ struct snd_usb_audio {
 	struct usb_host_interface *ctrl_intf;	/* the audio control interface */
 };
 
+#define USB_AUDIO_IFACE_UNUSED	((void *)-1L)
+
 #define usb_audio_err(chip, fmt, args...) \
 	dev_err(&(chip)->dev->dev, fmt, ##args)
 #define usb_audio_warn(chip, fmt, args...) \

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:02 UTC #180 lore raw

PATCH 180/240 cuse: prevent clone

In reply to Greg Kroah-Hartman

From: Miklos Szeredi <[email protected]>

[ Upstream commit 8217673d07256b22881127bf50dce874d0e51653 ]

For cloned connections cuse_channel_release() will be called more than once, resulting in use after free.

Prevent device cloning for CUSE, which does not make sense at this point, and highly unlikely to be used in real life.

Signed-off-by Miklos Szeredi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/fuse/cuse.c | 2 ++
 1 file changed, 2 insertions(+)

fs/fuse/cuse.c +2 -0

index d9aba9700726..b83367300f48 100644
@@ -616,6 +616,8 @@ static int __init cuse_init(void)
 	cuse_channel_fops.owner		= THIS_MODULE;
 	cuse_channel_fops.open		= cuse_channel_open;
 	cuse_channel_fops.release	= cuse_channel_release;
+	/* CUSE is not prepared for FUSE_DEV_IOC_CLONE */
+	cuse_channel_fops.unlocked_ioctl	= NULL;
 
 	cuse_class = class_create(THIS_MODULE, "cuse");
 	if (IS_ERR(cuse_class))

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:02 UTC #189 lore raw

PATCH 189/240 powerpc/iommu: Annotate nested lock for lockdep

In reply to Greg Kroah-Hartman

From: Alexey Kardashevskiy <[email protected]>

[ Upstream commit cc7130bf119add37f36238343a593b71ef6ecc1e ]

The IOMMU table is divided into pools for concurrent mappings and each pool has a separate spinlock. When taking the ownership of an IOMMU group to pass through a device to a VM, we lock these spinlocks which triggers a false negative warning in lockdep (below).

This fixes it by annotating the large pool's spinlock as a nest lock which makes lockdep not complaining when locking nested locks if the nest lock is locked already.

===
WARNING: possible recursive locking detected 5.11.0-le_syzkaller_a+fstn1 #100 Not tainted
--------------------------------------------
qemu-system-ppc/4129 is trying to acquire lock:
c0000000119bddb0 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0

but task is already holding lock:
c0000000119bdd30 (&(p->lock)/1){....}-{2:2}, at: iommu_take_ownership+0xac/0x1e0

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0
       ----

lock(&(p->lock)/1);
lock(&(p->lock)/1);
===

Signed-off-by Alexey Kardashevskiy <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/kernel/iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/powerpc/kernel/iommu.c +2 -2

index 9bfdd2510fd5..2cf900d16527 100644
@@ -1021,7 +1021,7 @@ int iommu_take_ownership(struct iommu_table *tbl)
 
 	spin_lock_irqsave(&tbl->large_pool.lock, flags);
 	for (i = 0; i < tbl->nr_pools; i++)
-		spin_lock(&tbl->pools[i].lock);
+		spin_lock_nest_lock(&tbl->pools[i].lock, &tbl->large_pool.lock);
 
 	if (tbl->it_offset == 0)
 		clear_bit(0, tbl->it_map);

@@ -1050,7 +1050,7 @@ void iommu_release_ownership(struct iommu_table *tbl)
 
 	spin_lock_irqsave(&tbl->large_pool.lock, flags);
 	for (i = 0; i < tbl->nr_pools; i++)
-		spin_lock(&tbl->pools[i].lock);
+		spin_lock_nest_lock(&tbl->pools[i].lock, &tbl->large_pool.lock);
 
 	memset(tbl->it_map, 0, sz);

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:02 UTC #190 lore raw

PATCH 190/240 net: ethernet: mtk_eth_soc: fix RX VLAN offload

In reply to Greg Kroah-Hartman

From: Felix Fietkau <[email protected]>

[ Upstream commit 3f57d8c40fea9b20543cab4da12f4680d2ef182c ]

The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is set. Fixes frames wrongly marked with VLAN tags.

Signed-off-by Felix Fietkau <[email protected]>

[Ilya: fix commit message]

Signed-off-by Ilya Lipnitskiy <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

drivers/net/ethernet/mediatek/mtk_eth_soc.c +1 -1

index d10c8a8156bc..5b072bf80783 100644
@@ -964,7 +964,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb->protocol = eth_type_trans(skb, netdev);
 
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
-		    RX_DMA_VID(trxd.rxd3))
+		    (trxd.rxd2 & RX_DMA_VTAG))
 			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
 					       RX_DMA_VID(trxd.rxd3));
 		napi_gro_receive(napi, skb);

drivers/net/ethernet/mediatek/mtk_eth_soc.h +1 -0

index 99b1c8e9f16f..2e7ccd8261c3 100644
@@ -272,6 +272,7 @@
 #define RX_DMA_DONE		BIT(31)
 #define RX_DMA_PLEN0(_x)	(((_x) & 0x3fff) << 16)
 #define RX_DMA_GET_PLEN0(_x)	(((_x) >> 16) & 0x3fff)
+#define RX_DMA_VTAG		BIT(15)
 
 /* QDMA descriptor rxd3 */
 #define RX_DMA_VID(_x)		((_x) & 0xfff)

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:02 UTC #191 lore raw

PATCH 191/240 ASoC: rt286: Make RT286_SET_GPIO_* readable and writable

In reply to Greg Kroah-Hartman

From: David Ward <[email protected]>

[ Upstream commit cd8499d5c03ba260e3191e90236d0e5f6b147563 ]

The GPIO configuration cannot be applied if the registers are inaccessible. This prevented the headset mic from working on the Dell XPS 13 9343.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=114171

Signed-off-by David Ward <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Pierre-Louis Bossart <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/soc/codecs/rt286.c | 3 +++
 1 file changed, 3 insertions(+)

sound/soc/codecs/rt286.c +3 -0

index 4a0ab620983d..a41dd9d1eb82 100644
@@ -174,6 +174,9 @@ static bool rt286_readable_register(struct device *dev, unsigned int reg)
 	case RT286_PROC_COEF:
 	case RT286_SET_AMP_GAIN_ADC_IN1:
 	case RT286_SET_AMP_GAIN_ADC_IN2:
+	case RT286_SET_GPIO_MASK:
+	case RT286_SET_GPIO_DIRECTION:
+	case RT286_SET_GPIO_DATA:
 	case RT286_SET_POWER(RT286_DAC_OUT1):
 	case RT286_SET_POWER(RT286_DAC_OUT2):
 	case RT286_SET_POWER(RT286_ADC_IN1):

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:03 UTC #192 lore raw

PATCH 192/240 f2fs: fix a redundant call to f2fs_balance_fs if an error occurs

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

[ Upstream commit 28e18ee636ba28532dbe425540af06245a0bbecb ]

The uninitialized variable dn.node_changed does not get set when a call to f2fs_get_node_page fails. This uninitialized value gets used in the call to f2fs_balance_fs() that may or not may not balances dirty node and dentry pages depending on the uninitialized state of the variable. Fix this by only calling f2fs_balance_fs if err is not set.

Thanks to Jaegeuk Kim for suggesting an appropriate fix.

Addresses-Coverity: ("Uninitialized scalar variable")

Fixes 2a3407607028 ("f2fs: call f2fs_balance_fs only when node was changed")

Signed-off-by Colin Ian King <[email protected]>

Reviewed-by Chao Yu <[email protected]>

Signed-off-by Jaegeuk Kim <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/f2fs/inline.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/f2fs/inline.c +2 -1

index 482888ee8942..481fae63f163 100644
@@ -196,7 +196,8 @@ out:
 
 	f2fs_put_page(page, 1);
 
-	f2fs_balance_fs(sbi, dn.node_changed);
+	if (!err)
+		f2fs_balance_fs(sbi, dn.node_changed);
 
 	return err;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:03 UTC #195 lore raw

PATCH 195/240 NFSv4.2: Always flush out writes in nfs42_proc_fallocate()

In reply to Greg Kroah-Hartman

From: Trond Myklebust <[email protected]>

[ Upstream commit 99f23783224355e7022ceea9b8d9f62c0fd01bd8 ]

Whether we're allocating or delallocating space, we should flush out the pending writes in order to avoid races with attribute updates.

Fixes 1e564d3dbd68 ("NFSv4.2: Fix a race in nfs42_proc_deallocate()")

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/nfs/nfs42proc.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

fs/nfs/nfs42proc.c +9 -7

index 5cda392028ce..7e9fb1119bcf 100644
@@ -56,7 +56,8 @@ static int _nfs42_proc_fallocate(struct rpc_message *msg, struct file *filep,
 static int nfs42_proc_fallocate(struct rpc_message *msg, struct file *filep,
 				loff_t offset, loff_t len)
 {
-	struct nfs_server *server = NFS_SERVER(file_inode(filep));
+	struct inode *inode = file_inode(filep);
+	struct nfs_server *server = NFS_SERVER(inode);
 	struct nfs4_exception exception = { };
 	struct nfs_lock_context *lock;
 	int err;

@@ -65,9 +66,13 @@ static int nfs42_proc_fallocate(struct rpc_message *msg, struct file *filep,
 	if (IS_ERR(lock))
 		return PTR_ERR(lock);
 
-	exception.inode = file_inode(filep);
+	exception.inode = inode;
 	exception.state = lock->open_context->state;
 
+	err = nfs_sync_inode(inode);
+	if (err)
+		goto out;
+
 	do {
 		err = _nfs42_proc_fallocate(msg, filep, lock, offset, len);
 		if (err == -ENOTSUPP) {

@@ -76,7 +81,7 @@ static int nfs42_proc_fallocate(struct rpc_message *msg, struct file *filep,
 		}
 		err = nfs4_handle_exception(server, err, &exception);
 	} while (exception.retry);
-
+out:
 	nfs_put_lock_context(lock);
 	return err;
 }

@@ -114,16 +119,13 @@ int nfs42_proc_deallocate(struct file *filep, loff_t offset, loff_t len)
 		return -EOPNOTSUPP;
 
 	inode_lock(inode);
-	err = nfs_sync_inode(inode);
-	if (err)
-		goto out_unlock;
 
 	err = nfs42_proc_fallocate(&msg, filep, offset, len);
 	if (err == 0)
 		truncate_pagecache_range(inode, offset, (offset + len) -1);
 	if (err == -EOPNOTSUPP)
 		NFS_SERVER(inode)->caps &= ~NFS_CAP_DEALLOCATE;
-out_unlock:
+
 	inode_unlock(inode);
 	return err;
 }

Signature · 1 line

2.30.2

Greg Kroah-Hartman

author maintainer

2021-05-20 11:03 UTC #193 lore raw

PATCH 193/240 PCI: Release OF node in pci_scan_device()s error path

In reply to Greg Kroah-Hartman

From: Dmitry Baryshkov <[email protected]>

[ Upstream commit c99e755a4a4c165cad6effb39faffd0f3377c02d ]

In pci_scan_device(), if pci_setup_device() fails for any reason, the code will not release device's of_node by calling pci_release_of_node(). Fix that by calling the release function.

Fixes 98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Dmitry Baryshkov <[email protected]>

Signed-off-by Bjorn Helgaas <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pci/probe.c | 1 +
 1 file changed, 1 insertion(+)

drivers/pci/probe.c +1 -0

index 19658873b4c1..ddf5ba63b195 100644
@@ -1694,6 +1694,7 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
 	pci_set_of_node(dev);
 
 	if (pci_setup_device(dev)) {
+		pci_release_of_node(dev);
 		pci_bus_put(dev->bus);
 		kfree(dev);
 		return NULL;

Signature · 1 line

2.30.2