From: Greg Kroah-Hartman Date: Mon, 27 Nov 2017 17:08:32 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v3.18.85~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=adaf85597c2cca2b091e883676261447f63f8908;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch i40e-use-smp_rmb-rather-than-read_barrier_depends.patch i40evf-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 ixgbe-fix-skb-list-corruption-on-power-systems.patch ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch media-rc-check-for-integer-overflow.patch media-v4l2-ctrl-fix-flags-field-on-control-events.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 --- diff --git a/queue-4.4/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch b/queue-4.4/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch new file mode 100644 index 00000000000..884387e2ded --- /dev/null +++ b/queue-4.4/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch @@ -0,0 +1,36 @@ +From 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Thu, 21 Sep 2017 05:40:18 -0300 +Subject: [media] cx231xx-cards: fix NULL-deref on missing association descriptor + +From: Johan Hovold + +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 +Signed-off-by: Johan Hovold +Tested-by: Andrey Konovalov +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch b/queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch new file mode 100644 index 00000000000..2bc619b6ace --- /dev/null +++ b/queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch @@ -0,0 +1,36 @@ +From 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:48 -0600 +Subject: fm10k: Use smp_rmb rather than read_barrier_depends + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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)) diff --git a/queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch b/queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch new file mode 100644 index 00000000000..aa183182251 --- /dev/null +++ b/queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch @@ -0,0 +1,49 @@ +From 52c6912fde0133981ee50ba08808f257829c4c93 Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:44 -0600 +Subject: i40e: Use smp_rmb rather than read_barrier_depends + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Tested-by: Andrew Bowers +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch b/queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch new file mode 100644 index 00000000000..f3c92eae0c4 --- /dev/null +++ b/queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch @@ -0,0 +1,37 @@ +From f72271e2a0ae4277d53c4053f5eed8bb346ba38a Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:49 -0600 +Subject: i40evf: Use smp_rmb rather than read_barrier_depends + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Tested-by: Andrew Bowers +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch b/queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch new file mode 100644 index 00000000000..696d0780225 --- /dev/null +++ b/queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch @@ -0,0 +1,37 @@ +From c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:47 -0600 +Subject: igb: Use smp_rmb rather than read_barrier_depends + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Tested-by: Aaron Brown +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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))) diff --git a/queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch b/queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch new file mode 100644 index 00000000000..999d37f7ddc --- /dev/null +++ b/queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch @@ -0,0 +1,37 @@ +From 1e1f9ca546556e508d021545861f6b5fc75a95fe Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:46 -0600 +Subject: igbvf: Use smp_rmb rather than read_barrier_depends + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Tested-by: Aaron Brown +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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))) diff --git a/queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch b/queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch new file mode 100644 index 00000000000..e2d895b305b --- /dev/null +++ b/queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch @@ -0,0 +1,49 @@ +From 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:43 -0600 +Subject: ixgbe: Fix skb list corruption on Power systems + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Tested-by: Andrew Bowers +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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))) diff --git a/queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch b/queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch new file mode 100644 index 00000000000..044990e2d6a --- /dev/null +++ b/queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch @@ -0,0 +1,37 @@ +From ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b Mon Sep 17 00:00:00 2001 +From: Brian King +Date: Fri, 17 Nov 2017 11:05:45 -0600 +Subject: ixgbevf: Use smp_rmb rather than read_barrier_depends + +From: Brian King + +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 +Acked-by: Jesse Brandeburg +Tested-by: Andrew Bowers +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + 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))) diff --git a/queue-4.4/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch b/queue-4.4/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch new file mode 100644 index 00000000000..cb7b4dbec22 --- /dev/null +++ b/queue-4.4/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch @@ -0,0 +1,166 @@ +From b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 Mon Sep 17 00:00:00 2001 +From: Michele Baldessari +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 + +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 +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.4/media-rc-check-for-integer-overflow.patch b/queue-4.4/media-rc-check-for-integer-overflow.patch new file mode 100644 index 00000000000..4f704307d20 --- /dev/null +++ b/queue-4.4/media-rc-check-for-integer-overflow.patch @@ -0,0 +1,40 @@ +From 3e45067f94bbd61dec0619b1c32744eb0de480c8 Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Sun, 8 Oct 2017 14:18:52 -0400 +Subject: media: rc: check for integer overflow + +From: Sean Young + +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 +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/media-v4l2-ctrl-fix-flags-field-on-control-events.patch b/queue-4.4/media-v4l2-ctrl-fix-flags-field-on-control-events.patch new file mode 100644 index 00000000000..b0d1797e072 --- /dev/null +++ b/queue-4.4/media-v4l2-ctrl-fix-flags-field-on-control-events.patch @@ -0,0 +1,67 @@ +From 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f Mon Sep 17 00:00:00 2001 +From: Ricardo Ribalda +Date: Tue, 17 Oct 2017 11:48:50 -0400 +Subject: media: v4l2-ctrl: Fix flags field on Control events + +From: Ricardo Ribalda Delgado + +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 +Signed-off-by: Ricardo Ribalda Delgado +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch b/queue-4.4/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch new file mode 100644 index 00000000000..8a843823200 --- /dev/null +++ b/queue-4.4/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch @@ -0,0 +1,54 @@ +From 05f016d2ca7a4fab99d5d5472168506ddf95e74f Mon Sep 17 00:00:00 2001 +From: John David Anglin +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 + +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 +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.4/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch b/queue-4.4/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch new file mode 100644 index 00000000000..a11adf47aab --- /dev/null +++ b/queue-4.4/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch @@ -0,0 +1,46 @@ +From 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001 +From: "Naveen N. Rao" +Date: Thu, 31 Aug 2017 21:55:57 +0530 +Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal() + +From: Naveen N. Rao + +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 +Signed-off-by: Naveen N. Rao +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + 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(); + diff --git a/queue-4.4/series b/queue-4.4/series index 33d36e646e8..1ae1620969a 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -50,3 +50,16 @@ libnvdimm-namespace-make-resource-attribute-only-readable-by-root.patch 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