--- /dev/null
+From 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 21 Sep 2017 05:40:18 -0300
+Subject: [media] cx231xx-cards: fix NULL-deref on missing association descriptor
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 upstream.
+
+Make sure to check that we actually have an Interface Association
+Descriptor before dereferencing it during probe to avoid dereferencing a
+NULL-pointer.
+
+Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
+Reported-by: Andrey Konovalov <andreyknvl@google.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Tested-by: Andrey Konovalov <andreyknvl@google.com>
+Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/cx231xx/cx231xx-cards.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
++++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
+@@ -1672,7 +1672,7 @@ static int cx231xx_usb_probe(struct usb_
+ nr = dev->devno;
+
+ assoc_desc = udev->actconfig->intf_assoc[0];
+- if (assoc_desc->bFirstInterface != ifnum) {
++ if (!assoc_desc || assoc_desc->bFirstInterface != ifnum) {
+ dev_err(d, "Not found matching IAD interface\n");
+ retval = -ENODEV;
+ goto err_if;
--- /dev/null
+From 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:48 -0600
+Subject: fm10k: Use smp_rmb rather than read_barrier_depends
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 upstream.
+
+The original issue being fixed in this patch was seen with the ixgbe
+driver, but the same issue exists with fm10k as well, as the code is
+very similar. read_barrier_depends is not sufficient to ensure
+loads following it are not speculatively loaded out of order
+by the CPU, which can result in stale data being loaded, causing
+potential system crashes.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c
++++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c
+@@ -1226,7 +1226,7 @@ static bool fm10k_clean_tx_irq(struct fm
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* if DD is not set pending work has not been completed */
+ if (!(eop_desc->flags & FM10K_TXD_FLAG_DONE))
--- /dev/null
+From 52c6912fde0133981ee50ba08808f257829c4c93 Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:44 -0600
+Subject: i40e: Use smp_rmb rather than read_barrier_depends
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit 52c6912fde0133981ee50ba08808f257829c4c93 upstream.
+
+The original issue being fixed in this patch was seen with the ixgbe
+driver, but the same issue exists with i40e as well, as the code is
+very similar. read_barrier_depends is not sufficient to ensure
+loads following it are not speculatively loaded out of order
+by the CPU, which can result in stale data being loaded, causing
+potential system crashes.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
+ drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
+@@ -3595,7 +3595,7 @@ static bool i40e_clean_fdir_tx_irq(struc
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* if the descriptor isn't done, no work yet to do */
+ if (!(eop_desc->cmd_type_offset_bsz &
+--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+@@ -663,7 +663,7 @@ static bool i40e_clean_tx_irq(struct i40
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* we have caught up to head, no work left to do */
+ if (tx_head == tx_desc)
--- /dev/null
+From f72271e2a0ae4277d53c4053f5eed8bb346ba38a Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:49 -0600
+Subject: i40evf: Use smp_rmb rather than read_barrier_depends
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit f72271e2a0ae4277d53c4053f5eed8bb346ba38a upstream.
+
+The original issue being fixed in this patch was seen with the ixgbe
+driver, but the same issue exists with i40evf as well, as the code is
+very similar. read_barrier_depends is not sufficient to ensure
+loads following it are not speculatively loaded out of order
+by the CPU, which can result in stale data being loaded, causing
+potential system crashes.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
++++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+@@ -172,7 +172,7 @@ static bool i40e_clean_tx_irq(struct i40
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* we have caught up to head, no work left to do */
+ if (tx_head == tx_desc)
--- /dev/null
+From c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:47 -0600
+Subject: igb: Use smp_rmb rather than read_barrier_depends
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 upstream.
+
+The original issue being fixed in this patch was seen with the ixgbe
+driver, but the same issue exists with igb as well, as the code is
+very similar. read_barrier_depends is not sufficient to ensure
+loads following it are not speculatively loaded out of order
+by the CPU, which can result in stale data being loaded, causing
+potential system crashes.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/igb/igb_main.c
++++ b/drivers/net/ethernet/intel/igb/igb_main.c
+@@ -6433,7 +6433,7 @@ static bool igb_clean_tx_irq(struct igb_
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* if DD is not set pending work has not been completed */
+ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD)))
--- /dev/null
+From 1e1f9ca546556e508d021545861f6b5fc75a95fe Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:46 -0600
+Subject: igbvf: Use smp_rmb rather than read_barrier_depends
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit 1e1f9ca546556e508d021545861f6b5fc75a95fe upstream.
+
+The original issue being fixed in this patch was seen with the ixgbe
+driver, but the same issue exists with igbvf as well, as the code is
+very similar. read_barrier_depends is not sufficient to ensure
+loads following it are not speculatively loaded out of order
+by the CPU, which can result in stale data being loaded, causing
+potential system crashes.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/igbvf/netdev.c
++++ b/drivers/net/ethernet/intel/igbvf/netdev.c
+@@ -809,7 +809,7 @@ static bool igbvf_clean_tx_irq(struct ig
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* if DD is not set pending work has not been completed */
+ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD)))
--- /dev/null
+From 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:43 -0600
+Subject: ixgbe: Fix skb list corruption on Power systems
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 upstream.
+
+This patch fixes an issue seen on Power systems with ixgbe which results
+in skb list corruption and an eventual kernel oops. The following is what
+was observed:
+
+CPU 1 CPU2
+============================ ============================
+1: ixgbe_xmit_frame_ring ixgbe_clean_tx_irq
+2: first->skb = skb eop_desc = tx_buffer->next_to_watch
+3: ixgbe_tx_map read_barrier_depends()
+4: wmb check adapter written status bit
+5: first->next_to_watch = tx_desc napi_consume_skb(tx_buffer->skb ..);
+6: writel(i, tx_ring->tail);
+
+The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not
+get loaded prior to tx_buffer->next_to_watch, which then results in loading
+a stale skb pointer. This patch replaces the read_barrier_depends with
+smp_rmb to ensure loads are ordered with respect to the load of
+tx_buffer->next_to_watch.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
++++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+@@ -1114,7 +1114,7 @@ static bool ixgbe_clean_tx_irq(struct ix
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* if DD is not set pending work has not been completed */
+ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD)))
--- /dev/null
+From ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b Mon Sep 17 00:00:00 2001
+From: Brian King <brking@linux.vnet.ibm.com>
+Date: Fri, 17 Nov 2017 11:05:45 -0600
+Subject: ixgbevf: Use smp_rmb rather than read_barrier_depends
+
+From: Brian King <brking@linux.vnet.ibm.com>
+
+commit ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b upstream.
+
+The original issue being fixed in this patch was seen with the ixgbe
+driver, but the same issue exists with ixgbevf as well, as the code is
+very similar. read_barrier_depends is not sufficient to ensure
+loads following it are not speculatively loaded out of order
+by the CPU, which can result in stale data being loaded, causing
+potential system crashes.
+
+Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
+Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
++++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+@@ -312,7 +312,7 @@ static bool ixgbevf_clean_tx_irq(struct
+ break;
+
+ /* prevent any other reads prior to eop_desc */
+- read_barrier_depends();
++ smp_rmb();
+
+ /* if DD is not set pending work has not been completed */
+ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD)))
--- /dev/null
+From b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 Mon Sep 17 00:00:00 2001
+From: Michele Baldessari <michele@acksyn.org>
+Date: Mon, 6 Nov 2017 08:50:22 -0500
+Subject: media: Don't do DMA on stack for firmware upload in the AS102 driver
+
+From: Michele Baldessari <michele@acksyn.org>
+
+commit b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 upstream.
+
+Firmware load on AS102 is using the stack which is not allowed any
+longer. We currently fail with:
+
+kernel: transfer buffer not dma capable
+kernel: ------------[ cut here ]------------
+kernel: WARNING: CPU: 0 PID: 598 at drivers/usb/core/hcd.c:1595 usb_hcd_map_urb_for_dma+0x41d/0x620
+kernel: Modules linked in: amd64_edac_mod(-) edac_mce_amd as102_fe dvb_as102(+) kvm_amd kvm snd_hda_codec_realtek dvb_core snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul crc32_pclmul snd_hda_core snd_hwdep snd_seq ghash_clmulni_intel sp5100_tco fam15h_power wmi k10temp i2c_piix4 snd_seq_device snd_pcm snd_timer parport_pc parport tpm_infineon snd tpm_tis soundcore tpm_tis_core tpm shpchp acpi_cpufreq xfs libcrc32c amdgpu amdkfd amd_iommu_v2 radeon hid_logitech_hidpp i2c_algo_bit drm_kms_helper crc32c_intel ttm drm r8169 mii hid_logitech_dj
+kernel: CPU: 0 PID: 598 Comm: systemd-udevd Not tainted 4.13.10-200.fc26.x86_64 #1
+kernel: Hardware name: ASUS All Series/AM1I-A, BIOS 0505 03/13/2014
+kernel: task: ffff979933b24c80 task.stack: ffffaf83413a4000
+kernel: RIP: 0010:usb_hcd_map_urb_for_dma+0x41d/0x620
+systemd-fsck[659]: /dev/sda2: clean, 49/128016 files, 268609/512000 blocks
+kernel: RSP: 0018:ffffaf83413a7728 EFLAGS: 00010282
+systemd-udevd[604]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
+kernel: RAX: 000000000000001f RBX: ffff979930bce780 RCX: 0000000000000000
+kernel: RDX: 0000000000000000 RSI: ffff97993ec0e118 RDI: ffff97993ec0e118
+kernel: RBP: ffffaf83413a7768 R08: 000000000000039a R09: 0000000000000000
+kernel: R10: 0000000000000001 R11: 00000000ffffffff R12: 00000000fffffff5
+kernel: R13: 0000000001400000 R14: 0000000000000001 R15: ffff979930806800
+kernel: FS: 00007effaca5c8c0(0000) GS:ffff97993ec00000(0000) knlGS:0000000000000000
+kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+kernel: CR2: 00007effa9fca962 CR3: 0000000233089000 CR4: 00000000000406f0
+kernel: Call Trace:
+kernel: usb_hcd_submit_urb+0x493/0xb40
+kernel: ? page_cache_tree_insert+0x100/0x100
+kernel: ? xfs_iunlock+0xd5/0x100 [xfs]
+kernel: ? xfs_file_buffered_aio_read+0x57/0xc0 [xfs]
+kernel: usb_submit_urb+0x22d/0x560
+kernel: usb_start_wait_urb+0x6e/0x180
+kernel: usb_bulk_msg+0xb8/0x160
+kernel: as102_send_ep1+0x49/0xe0 [dvb_as102]
+kernel: ? devres_add+0x3f/0x50
+kernel: as102_firmware_upload.isra.0+0x1dc/0x210 [dvb_as102]
+kernel: as102_fw_upload+0xb6/0x1f0 [dvb_as102]
+kernel: as102_dvb_register+0x2af/0x2d0 [dvb_as102]
+kernel: as102_usb_probe+0x1f3/0x260 [dvb_as102]
+kernel: usb_probe_interface+0x124/0x300
+kernel: driver_probe_device+0x2ff/0x450
+kernel: __driver_attach+0xa4/0xe0
+kernel: ? driver_probe_device+0x450/0x450
+kernel: bus_for_each_dev+0x6e/0xb0
+kernel: driver_attach+0x1e/0x20
+kernel: bus_add_driver+0x1c7/0x270
+kernel: driver_register+0x60/0xe0
+kernel: usb_register_driver+0x81/0x150
+kernel: ? 0xffffffffc0807000
+kernel: as102_usb_driver_init+0x1e/0x1000 [dvb_as102]
+kernel: do_one_initcall+0x50/0x190
+kernel: ? __vunmap+0x81/0xb0
+kernel: ? kfree+0x154/0x170
+kernel: ? kmem_cache_alloc_trace+0x15f/0x1c0
+kernel: ? do_init_module+0x27/0x1e9
+kernel: do_init_module+0x5f/0x1e9
+kernel: load_module+0x2602/0x2c30
+kernel: SYSC_init_module+0x170/0x1a0
+kernel: ? SYSC_init_module+0x170/0x1a0
+kernel: SyS_init_module+0xe/0x10
+kernel: do_syscall_64+0x67/0x140
+kernel: entry_SYSCALL64_slow_path+0x25/0x25
+kernel: RIP: 0033:0x7effab6cf3ea
+kernel: RSP: 002b:00007fff5cfcbbc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
+kernel: RAX: ffffffffffffffda RBX: 00005569e0b83760 RCX: 00007effab6cf3ea
+kernel: RDX: 00007effac2099c5 RSI: 0000000000009a13 RDI: 00005569e0b98c50
+kernel: RBP: 00007effac2099c5 R08: 00005569e0b83ed0 R09: 0000000000001d80
+kernel: R10: 00007effab98db00 R11: 0000000000000246 R12: 00005569e0b98c50
+kernel: R13: 00005569e0b81c60 R14: 0000000000020000 R15: 00005569dfadfdf7
+kernel: Code: 48 39 c8 73 30 80 3d 59 60 9d 00 00 41 bc f5 ff ff ff 0f 85 26 ff ff ff 48 c7 c7 b8 6b d0 92 c6 05 3f 60 9d 00 01 e8 24 3d ad ff <0f> ff 8b 53 64 e9 09 ff ff ff 65 48 8b 0c 25 00 d3 00 00 48 8b
+kernel: ---[ end trace c4cae366180e70ec ]---
+kernel: as10x_usb: error during firmware upload part1
+
+Let's allocate the the structure dynamically so we can get the firmware
+loaded correctly:
+[ 14.243057] as10x_usb: firmware: as102_data1_st.hex loaded with success
+[ 14.500777] as10x_usb: firmware: as102_data2_st.hex loaded with success
+
+Signed-off-by: Michele Baldessari <michele@acksyn.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/as102/as102_fw.c | 28 +++++++++++++++++-----------
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/drivers/media/usb/as102/as102_fw.c
++++ b/drivers/media/usb/as102/as102_fw.c
+@@ -101,18 +101,23 @@ static int as102_firmware_upload(struct
+ unsigned char *cmd,
+ const struct firmware *firmware) {
+
+- struct as10x_fw_pkt_t fw_pkt;
++ struct as10x_fw_pkt_t *fw_pkt;
+ int total_read_bytes = 0, errno = 0;
+ unsigned char addr_has_changed = 0;
+
++ fw_pkt = kmalloc(sizeof(*fw_pkt), GFP_KERNEL);
++ if (!fw_pkt)
++ return -ENOMEM;
++
++
+ for (total_read_bytes = 0; total_read_bytes < firmware->size; ) {
+ int read_bytes = 0, data_len = 0;
+
+ /* parse intel hex line */
+ read_bytes = parse_hex_line(
+ (u8 *) (firmware->data + total_read_bytes),
+- fw_pkt.raw.address,
+- fw_pkt.raw.data,
++ fw_pkt->raw.address,
++ fw_pkt->raw.data,
+ &data_len,
+ &addr_has_changed);
+
+@@ -122,28 +127,28 @@ static int as102_firmware_upload(struct
+ /* detect the end of file */
+ total_read_bytes += read_bytes;
+ if (total_read_bytes == firmware->size) {
+- fw_pkt.u.request[0] = 0x00;
+- fw_pkt.u.request[1] = 0x03;
++ fw_pkt->u.request[0] = 0x00;
++ fw_pkt->u.request[1] = 0x03;
+
+ /* send EOF command */
+ errno = bus_adap->ops->upload_fw_pkt(bus_adap,
+ (uint8_t *)
+- &fw_pkt, 2, 0);
++ fw_pkt, 2, 0);
+ if (errno < 0)
+ goto error;
+ } else {
+ if (!addr_has_changed) {
+ /* prepare command to send */
+- fw_pkt.u.request[0] = 0x00;
+- fw_pkt.u.request[1] = 0x01;
++ fw_pkt->u.request[0] = 0x00;
++ fw_pkt->u.request[1] = 0x01;
+
+- data_len += sizeof(fw_pkt.u.request);
+- data_len += sizeof(fw_pkt.raw.address);
++ data_len += sizeof(fw_pkt->u.request);
++ data_len += sizeof(fw_pkt->raw.address);
+
+ /* send cmd to device */
+ errno = bus_adap->ops->upload_fw_pkt(bus_adap,
+ (uint8_t *)
+- &fw_pkt,
++ fw_pkt,
+ data_len,
+ 0);
+ if (errno < 0)
+@@ -152,6 +157,7 @@ static int as102_firmware_upload(struct
+ }
+ }
+ error:
++ kfree(fw_pkt);
+ return (errno == 0) ? total_read_bytes : errno;
+ }
+
--- /dev/null
+From 3e45067f94bbd61dec0619b1c32744eb0de480c8 Mon Sep 17 00:00:00 2001
+From: Sean Young <sean@mess.org>
+Date: Sun, 8 Oct 2017 14:18:52 -0400
+Subject: media: rc: check for integer overflow
+
+From: Sean Young <sean@mess.org>
+
+commit 3e45067f94bbd61dec0619b1c32744eb0de480c8 upstream.
+
+The ioctl LIRC_SET_REC_TIMEOUT would set a timeout of 704ns if called
+with a timeout of 4294968us.
+
+Signed-off-by: Sean Young <sean@mess.org>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/rc/ir-lirc-codec.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/media/rc/ir-lirc-codec.c
++++ b/drivers/media/rc/ir-lirc-codec.c
+@@ -286,11 +286,14 @@ static long ir_lirc_ioctl(struct file *f
+ if (!dev->max_timeout)
+ return -ENOSYS;
+
++ /* Check for multiply overflow */
++ if (val > U32_MAX / 1000)
++ return -EINVAL;
++
+ tmp = val * 1000;
+
+- if (tmp < dev->min_timeout ||
+- tmp > dev->max_timeout)
+- return -EINVAL;
++ if (tmp < dev->min_timeout || tmp > dev->max_timeout)
++ return -EINVAL;
+
+ dev->timeout = tmp;
+ break;
--- /dev/null
+From 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ricardo.ribalda@gmail.com>
+Date: Tue, 17 Oct 2017 11:48:50 -0400
+Subject: media: v4l2-ctrl: Fix flags field on Control events
+
+From: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
+
+commit 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f upstream.
+
+VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for
+the control flags field.
+
+This patch creates a new function user_flags(), that calculates the user
+exported flags value (which is different than the kernel internal flags
+structure). This function is then used by all the code that exports the
+internal flags to userspace.
+
+Reported-by: Dimitrios Katsaros <patcherwork@gmail.com>
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
+Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/v4l2-ctrls.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/v4l2-core/v4l2-ctrls.c
++++ b/drivers/media/v4l2-core/v4l2-ctrls.c
+@@ -1200,6 +1200,16 @@ void v4l2_ctrl_fill(u32 id, const char *
+ }
+ EXPORT_SYMBOL(v4l2_ctrl_fill);
+
++static u32 user_flags(const struct v4l2_ctrl *ctrl)
++{
++ u32 flags = ctrl->flags;
++
++ if (ctrl->is_ptr)
++ flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD;
++
++ return flags;
++}
++
+ static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 changes)
+ {
+ memset(ev->reserved, 0, sizeof(ev->reserved));
+@@ -1207,7 +1217,7 @@ static void fill_event(struct v4l2_event
+ ev->id = ctrl->id;
+ ev->u.ctrl.changes = changes;
+ ev->u.ctrl.type = ctrl->type;
+- ev->u.ctrl.flags = ctrl->flags;
++ ev->u.ctrl.flags = user_flags(ctrl);
+ if (ctrl->is_ptr)
+ ev->u.ctrl.value64 = 0;
+ else
+@@ -2536,10 +2546,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl
+ else
+ qc->id = ctrl->id;
+ strlcpy(qc->name, ctrl->name, sizeof(qc->name));
+- qc->flags = ctrl->flags;
++ qc->flags = user_flags(ctrl);
+ qc->type = ctrl->type;
+- if (ctrl->is_ptr)
+- qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD;
+ qc->elem_size = ctrl->elem_size;
+ qc->elems = ctrl->elems;
+ qc->nr_of_dims = ctrl->nr_of_dims;
--- /dev/null
+From 05f016d2ca7a4fab99d5d5472168506ddf95e74f Mon Sep 17 00:00:00 2001
+From: John David Anglin <dave.anglin@bell.net>
+Date: Sat, 11 Nov 2017 17:11:16 -0500
+Subject: parisc: Fix validity check of pointer size argument in new CAS implementation
+
+From: John David Anglin <dave.anglin@bell.net>
+
+commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f upstream.
+
+As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS
+implementation causes a kernel crash. The attached patch corrects the
+off by one error in the argument validity check.
+
+In reviewing the code, I noticed that we only perform word operations
+with the pointer size argument. The subi instruction intentionally uses
+a word condition on 64-bit kernels. Nullification was used instead of a
+cmpib instruction as the branch should never be taken. The shlw
+pseudo-operation generates a depw,z instruction and it clears the target
+before doing a shift left word deposit. Thus, we don't need to clip the
+upper 32 bits of this argument on 64-bit kernels.
+
+Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic
+code in libgcc is the only direct user of the new CAS implementation
+that I am aware of.
+
+Signed-off-by: John David Anglin <dave.anglin@bell.net>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/kernel/syscall.S | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/parisc/kernel/syscall.S
++++ b/arch/parisc/kernel/syscall.S
+@@ -688,15 +688,15 @@ cas_action:
+ /* ELF32 Process entry path */
+ lws_compare_and_swap_2:
+ #ifdef CONFIG_64BIT
+- /* Clip the input registers */
++ /* Clip the input registers. We don't need to clip %r23 as we
++ only use it for word operations */
+ depdi 0, 31, 32, %r26
+ depdi 0, 31, 32, %r25
+ depdi 0, 31, 32, %r24
+- depdi 0, 31, 32, %r23
+ #endif
+
+ /* Check the validity of the size pointer */
+- subi,>>= 4, %r23, %r0
++ subi,>>= 3, %r23, %r0
+ b,n lws_exit_nosys
+
+ /* Jump to the functions which will load the old and new values into
--- /dev/null
+From 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Thu, 31 Aug 2017 21:55:57 +0530
+Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal()
+
+From: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+
+commit 46725b17f1c6c815a41429259b3f070c01e71bc1 upstream.
+
+When a uprobe is installed on an instruction that we currently do not
+emulate, we copy the instruction into a xol buffer and single step
+that instruction. If that instruction generates a fault, we abort the
+single stepping before invoking the signal handler. Once the signal
+handler is done, the uprobe trap is hit again since the instruction is
+retried and the process repeats.
+
+We use uprobe_deny_signal() to detect if the xol instruction triggered
+a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the
+signal is not handled until after the single stepping is aborted. In
+this case, uprobe_deny_signal() returns true and get_signal() ends up
+returning 0. However, in do_signal(), we are not looking at the return
+value, but depending on ksig.sig for further action, all with an
+uninitialized ksig that is not touched in this scenario. Fix the same
+by initializing ksig.sig to 0.
+
+Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()")
+Reported-by: Anton Blanchard <anton@samba.org>
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/signal.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/signal.c
++++ b/arch/powerpc/kernel/signal.c
+@@ -102,7 +102,7 @@ static void check_syscall_restart(struct
+ static void do_signal(struct pt_regs *regs)
+ {
+ sigset_t *oldset = sigmask_to_save();
+- struct ksignal ksig;
++ struct ksignal ksig = { .sig = 0 };
+ int ret;
+ int is32 = is_32bit_task();
+
ib-srpt-do-not-accept-invalid-initiator-port-names.patch
ib-srp-avoid-that-a-cable-pull-can-trigger-a-kernel-crash.patch
nfc-fix-device-allocation-error-return.patch
+i40e-use-smp_rmb-rather-than-read_barrier_depends.patch
+igb-use-smp_rmb-rather-than-read_barrier_depends.patch
+igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch
+ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch
+i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch
+fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch
+ixgbe-fix-skb-list-corruption-on-power-systems.patch
+parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch
+powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch
+media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch
+media-rc-check-for-integer-overflow.patch
+cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch
+media-v4l2-ctrl-fix-flags-field-on-control-events.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
