Merge remote-tracking branch 'origin/stabilization' into f23-user-thl-vanilla-stabilizationkernel-4.4.2-300.vanilla.knurd.1.fc23

9 files changed, 248 insertions, 229 deletions

diff --git a/HID-multitouch-fix-input-mode-switching-on-some-Elan.patch b/HID-multitouch-fix-input-mode-switching-on-some-Elan.patch
deleted file mode 100644
index c469460e5..000000000
--- a/HID-multitouch-fix-input-mode-switching-on-some-Elan.patch
+++ /dev/null
@@ -1,94 +0,0 @@
-From cd1e1e286bb3c4fa8714c1e571ae082e510efd5d Mon Sep 17 00:00:00 2001
-From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-Date: Tue, 1 Dec 2015 12:41:38 +0100
-Subject: [PATCH] HID: multitouch: fix input mode switching on some Elan panels
-
-as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481
-
-This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
-reports on demand for Win8 devices") as the origin of the problem but this
-commit actually masked 2 firmware bugs that are annihilating each other:
-
-The report descriptor declares two features in reports 3 and 5:
-
-0x05, 0x0d,                    // Usage Page (Digitizers)             318
-0x09, 0x0e,                    // Usage (Device Configuration)        320
-0xa1, 0x01,                    // Collection (Application)            322
-0x85, 0x03,                    //  Report ID (3)                      324
-0x09, 0x22,                    //  Usage (Finger)                     326
-0xa1, 0x00,                    //  Collection (Physical)              328
-0x09, 0x52,                    //   Usage (Inputmode)                 330
-0x15, 0x00,                    //   Logical Minimum (0)               332
-0x25, 0x0a,                    //   Logical Maximum (10)              334
-0x75, 0x08,                    //   Report Size (8)                   336
-0x95, 0x02,                    //   Report Count (2)                  338
-0xb1, 0x02,                    //   Feature (Data,Var,Abs)            340
-0xc0,                          //  End Collection                     342
-0x09, 0x22,                    //  Usage (Finger)                     343
-0xa1, 0x00,                    //  Collection (Physical)              345
-0x85, 0x05,                    //   Report ID (5)                     347
-0x09, 0x57,                    //   Usage (Surface Switch)            349
-0x09, 0x58,                    //   Usage (Button Switch)             351
-0x15, 0x00,                    //   Logical Minimum (0)               353
-0x75, 0x01,                    //   Report Size (1)                   355
-0x95, 0x02,                    //   Report Count (2)                  357
-0x25, 0x03,                    //   Logical Maximum (3)               359
-0xb1, 0x02,                    //   Feature (Data,Var,Abs)            361
-0x95, 0x0e,                    //   Report Count (14)                 363
-0xb1, 0x03,                    //   Feature (Cnst,Var,Abs)            365
-0xc0,                          //  End Collection                     367
-
-The report ID 3 presents 2 input mode features, while only the first one
-is handled by the device. Given that we did not checked if one was
-previously assigned, we were dealing with the ignored featured and we
-should never have been able to switch this panel into the multitouch mode.
-
-However, the firmware presents an other bugs which allowed 6d4f5440
-to counteract the faulty report descriptor. When we request the values
-of the feature 5, the firmware answers "03 03 00". The fields are correct
-but the report id is wrong. Before 6d4f5440, we retrieved all the features
-and injected them in the system. So when we called report 5, we injected
-in the system the report 3 with the values "03 00".
-Setting the second input mode to 03 in this report changed it to "03 03"
-and the touchpad switched to the mt mode. We could have set anything
-in the second field because the actual value (the first 03 in this report)
-was given by the query of report ID 5.
-
-To sum up: 2 bugs in the firmware were hiding that we were accessing the
-wrong feature.
-
-Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-Signed-off-by: Jiri Kosina <jkosina@suse.cz>
----
- drivers/hid/hid-multitouch.c | 15 +++++++++++++--
- 1 file changed, 13 insertions(+), 2 deletions(-)
-
-diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
-index ba94044cb859..d866720412cd 100644
---- a/drivers/hid/hid-multitouch.c
-+++ b/drivers/hid/hid-multitouch.c
-@@ -357,8 +357,19 @@ static void mt_feature_mapping(struct hid_device *hdev,
- 			break;
- 		}
- 
--		td->inputmode = field->report->id;
--		td->inputmode_index = usage->usage_index;
-+		if (td->inputmode < 0) {
-+			td->inputmode = field->report->id;
-+			td->inputmode_index = usage->usage_index;
-+		} else {
-+			/*
-+			 * Some elan panels wrongly declare 2 input mode
-+			 * features, and silently ignore when we set the
-+			 * value in the second field. Skip the second feature
-+			 * and hope for the best.
-+			 */
-+			dev_info(&hdev->dev,
-+				 "Ignoring the extra HID_DG_INPUTMODE\n");
-+		}
- 
- 		break;
- 	case HID_DG_CONTACTMAX:
--- 
-2.5.0
-
diff --git a/Input-elantech-mark-protocols-v2-and-v3-as-semi-mt.patch b/Input-elantech-mark-protocols-v2-and-v3-as-semi-mt.patch
new file mode 100644
index 000000000..c02a0f53b
--- /dev/null
+++ b/Input-elantech-mark-protocols-v2-and-v3-as-semi-mt.patch
@@ -0,0 +1,41 @@
+From 6544a1df11c48c8413071aac3316792e4678fbfb Mon Sep 17 00:00:00 2001
+From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Date: Mon, 11 Jan 2016 17:35:38 -0800
+Subject: [PATCH] Input: elantech - mark protocols v2 and v3 as semi-mt
+
+When using a protocol v2 or v3 hardware, elantech uses the function
+elantech_report_semi_mt_data() to report data. This devices are rather
+creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid
+touch is reported.
+
+Anyway, userspace (libinput) is now confused by these (0,0) touches,
+and detect them as palm, and rejects them.
+
+Commit 3c0213d17a09 ("Input: elantech - fix semi-mt protocol for v3 HW")
+was sufficient enough for xf86-input-synaptics and libinput before it has
+palm rejection. Now we need to actually tell libinput that this device is
+a semi-mt one and it should not rely on the actual values of the 2 touches.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+---
+ drivers/input/mouse/elantech.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
+index 537ebb0e193a..78f93cf68840 100644
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -1222,7 +1222,7 @@ static int elantech_set_input_params(struct psmouse *psmouse)
+ 			input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2,
+ 					     ETP_WMAX_V2, 0, 0);
+ 		}
+-		input_mt_init_slots(dev, 2, 0);
++		input_mt_init_slots(dev, 2, INPUT_MT_SEMI_MT);
+ 		input_set_abs_params(dev, ABS_MT_POSITION_X, x_min, x_max, 0, 0);
+ 		input_set_abs_params(dev, ABS_MT_POSITION_Y, y_min, y_max, 0, 0);
+ 		break;
+-- 
+2.5.0
+
diff --git a/bpf-fix-branch-offset-adjustment-on-backjumps-after-.patch b/bpf-fix-branch-offset-adjustment-on-backjumps-after-.patch
new file mode 100644
index 000000000..fc5a1a504
--- /dev/null
+++ b/bpf-fix-branch-offset-adjustment-on-backjumps-after-.patch
@@ -0,0 +1,92 @@
+From a1b14d27ed0965838350f1377ff97c93ee383492 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Wed, 10 Feb 2016 16:47:11 +0100
+Subject: [PATCH] bpf: fix branch offset adjustment on backjumps after patching
+ ctx expansion
+
+When ctx access is used, the kernel often needs to expand/rewrite
+instructions, so after that patching, branch offsets have to be
+adjusted for both forward and backward jumps in the new eBPF program,
+but for backward jumps it fails to account the delta. Meaning, for
+example, if the expansion happens exactly on the insn that sits at
+the jump target, it doesn't fix up the back jump offset.
+
+Analysis on what the check in adjust_branches() is currently doing:
+
+  /* adjust offset of jmps if necessary */
+  if (i < pos && i + insn->off + 1 > pos)
+    insn->off += delta;
+  else if (i > pos && i + insn->off + 1 < pos)
+    insn->off -= delta;
+
+First condition (forward jumps):
+
+  Before:                         After:
+
+  insns[0]                        insns[0]
+  insns[1] <--- i/insn            insns[1] <--- i/insn
+  insns[2] <--- pos               insns[P] <--- pos
+  insns[3]                        insns[P]  `------| delta
+  insns[4] <--- target_X          insns[P]   `-----|
+  insns[5]                        insns[3]
+                                  insns[4] <--- target_X
+                                  insns[5]
+
+First case is if we cross pos-boundary and the jump instruction was
+before pos. This is handeled correctly. I.e. if i == pos, then this
+would mean our jump that we currently check was the patchlet itself
+that we just injected. Since such patchlets are self-contained and
+have no awareness of any insns before or after the patched one, the
+delta is correctly not adjusted. Also, for the second condition in
+case of i + insn->off + 1 == pos, means we jump to that newly patched
+instruction, so no offset adjustment are needed. That part is correct.
+
+Second condition (backward jumps):
+
+  Before:                         After:
+
+  insns[0]                        insns[0]
+  insns[1] <--- target_X          insns[1] <--- target_X
+  insns[2] <--- pos <-- target_Y  insns[P] <--- pos <-- target_Y
+  insns[3]                        insns[P]  `------| delta
+  insns[4] <--- i/insn            insns[P]   `-----|
+  insns[5]                        insns[3]
+                                  insns[4] <--- i/insn
+                                  insns[5]
+
+Second interesting case is where we cross pos-boundary and the jump
+instruction was after pos. Backward jump with i == pos would be
+impossible and pose a bug somewhere in the patchlet, so the first
+condition checking i > pos is okay only by itself. However, i +
+insn->off + 1 < pos does not always work as intended to trigger the
+adjustment. It works when jump targets would be far off where the
+delta wouldn't matter. But, for example, where the fixed insn->off
+before pointed to pos (target_Y), it now points to pos + delta, so
+that additional room needs to be taken into account for the check.
+This means that i) both tests here need to be adjusted into pos + delta,
+and ii) for the second condition, the test needs to be <= as pos
+itself can be a target in the backjump, too.
+
+Fixes: 9bac3d6d548e ("bpf: allow extended BPF programs access skb fields")
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+---
+ kernel/bpf/verifier.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index d1d3e8f57de9..2e7f7ab739e4 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -2082,7 +2082,7 @@ static void adjust_branches(struct bpf_prog *prog, int pos, int delta)
+ 		/* adjust offset of jmps if necessary */
+ 		if (i < pos && i + insn->off + 1 > pos)
+ 			insn->off += delta;
+-		else if (i > pos && i + insn->off + 1 < pos)
++		else if (i > pos + delta && i + insn->off + 1 <= pos + delta)
+ 			insn->off -= delta;
+ 	}
+ }
+-- 
+2.5.0
+
diff --git a/config-x86-generic b/config-x86-generic
index a436377af..646378bb7 100644
--- a/config-x86-generic
+++ b/config-x86-generic
@@ -72,7 +72,8 @@ CONFIG_MMIOTRACE=y
 # CONFIG_MMIOTRACE_TEST is not set
 # CONFIG_DEBUG_PER_CPU_MAPS is not set
 CONFIG_DEBUG_RODATA=y
-CONFIG_DEBUG_WX=y
+# Generating too many warnings while waiting for fixes
+# CONFIG_DEBUG_WX is not set
 CONFIG_DEBUG_STACKOVERFLOW=y
 
 CONFIG_ACPI=y
diff --git a/fs-hugetlbfs-inode.c-fix-bugs-in-hugetlb_vmtruncate_.patch b/fs-hugetlbfs-inode.c-fix-bugs-in-hugetlb_vmtruncate_.patch
new file mode 100644
index 000000000..90bf05310
--- /dev/null
+++ b/fs-hugetlbfs-inode.c-fix-bugs-in-hugetlb_vmtruncate_.patch
@@ -0,0 +1,86 @@
+From 9aacdd354d197ad64685941b36d28ea20ab88757 Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Fri, 15 Jan 2016 16:57:37 -0800
+Subject: [PATCH] fs/hugetlbfs/inode.c: fix bugs in hugetlb_vmtruncate_list()
+
+Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine.  The
+argument end is of type pgoff_t.  It was being converted to a vaddr
+offset and passed to unmap_hugepage_range.  However, end was also being
+used as an argument to the vma_interval_tree_foreach controlling loop.
+In addition, the conversion of end to vaddr offset was incorrect.
+
+hugetlb_vmtruncate_list is called as part of a file truncate or
+fallocate hole punch operation.
+
+When truncating a hugetlbfs file, this bug could prevent some pages from
+being unmapped.  This is possible if there are multiple vmas mapping the
+file, and there is a sufficiently sized hole between the mappings.  The
+size of the hole between two vmas (A,B) must be such that the starting
+virtual address of B is greater than (ending virtual address of A <<
+PAGE_SHIFT).  In this case, the pages in B would not be unmapped.  If
+pages are not properly unmapped during truncate, the following BUG is
+hit:
+
+	kernel BUG at fs/hugetlbfs/inode.c:428!
+
+In the fallocate hole punch case, this bug could prevent pages from
+being unmapped as in the truncate case.  However, for hole punch the
+result is that unmapped pages will not be removed during the operation.
+For hole punch, it is also possible that more pages than desired will be
+unmapped.  This unnecessary unmapping will cause page faults to
+reestablish the mappings on subsequent page access.
+
+Fixes: 1bfad99ab (" hugetlbfs: hugetlb_vmtruncate_list() needs to take a range")Reported-by: Hillf Danton <hillf.zj@alibaba-inc.com>
+Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: <stable@vger.kernel.org>	[4.3]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ fs/hugetlbfs/inode.c | 19 +++++++++++--------
+ 1 file changed, 11 insertions(+), 8 deletions(-)
+
+diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
+index bbc333b01ca3..9c07d2d754c9 100644
+--- a/fs/hugetlbfs/inode.c
++++ b/fs/hugetlbfs/inode.c
+@@ -463,6 +463,7 @@ hugetlb_vmdelete_list(struct rb_root *root, pgoff_t start, pgoff_t end)
+ 	 */
+ 	vma_interval_tree_foreach(vma, root, start, end ? end : ULONG_MAX) {
+ 		unsigned long v_offset;
++		unsigned long v_end;
+ 
+ 		/*
+ 		 * Can the expression below overflow on 32-bit arches?
+@@ -475,15 +476,17 @@ hugetlb_vmdelete_list(struct rb_root *root, pgoff_t start, pgoff_t end)
+ 		else
+ 			v_offset = 0;
+ 
+-		if (end) {
+-			end = ((end - start) << PAGE_SHIFT) +
+-			       vma->vm_start + v_offset;
+-			if (end > vma->vm_end)
+-				end = vma->vm_end;
+-		} else
+-			end = vma->vm_end;
++		if (!end)
++			v_end = vma->vm_end;
++		else {
++			v_end = ((end - vma->vm_pgoff) << PAGE_SHIFT)
++							+ vma->vm_start;
++			if (v_end > vma->vm_end)
++				v_end = vma->vm_end;
++		}
+ 
+-		unmap_hugepage_range(vma, vma->vm_start + v_offset, end, NULL);
++		unmap_hugepage_range(vma, vma->vm_start + v_offset, v_end,
++									NULL);
+ 	}
+ }
+ 
+-- 
+2.5.0
+
diff --git a/kernel.spec b/kernel.spec
index 550618019..3ac36eef4 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -56,7 +56,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 1
+%define stable_update 2
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -607,15 +607,6 @@ Patch603: ptrace-being-capable-wrt-a-process-requires-mapped-u.patch
 
 Patch604: drm-i915-shut-up-gen8-SDE-irq-dmesg-noise-again.patch
 
-#rhbz 1296677
-Patch641: HID-multitouch-fix-input-mode-switching-on-some-Elan.patch
-
-#CVE-2016-0723 rhbz 1296253 1300224
-Patch637: tty-Fix-unsafe-ldisc-reference-via-ioctl-TIOCGETD.patch
-
-#rhbz 1279653
-Patch638: rtlwifi-rtl8821ae-Fix-5G-failure-when-EEPROM-is-inco.patch
-
 #rhbz 1083853
 Patch610: PNP-Add-Broadwell-to-Intel-MCH-size-workaround.patch
 
@@ -632,6 +623,15 @@ Patch645: cfg80211-wext-fix-message-ordering.patch
 #rhbz 1255325
 Patch646: HID-sony-do-not-bail-out-when-the-sixaxis-refuses-th.patch
 
+#CVE-2016-0617 rhbz 1305803 1305804
+Patch648: fs-hugetlbfs-inode.c-fix-bugs-in-hugetlb_vmtruncate_.patch
+
+#CVE-2016-2383 rhbz 1308452 1308453
+Patch650: bpf-fix-branch-offset-adjustment-on-backjumps-after-.patch
+
+#rhbz 1306987
+Patch651: Input-elantech-mark-protocols-v2-and-v3-as-semi-mt.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2075,6 +2075,22 @@ fi
 #
 # 
 %changelog
+* Wed Feb 17 2016 Laura Abbott <labbott@fedoraproject.org>
+- Linux v4.4.2
+
+* Tue Feb 16 2016 Josh Boyer <jwboyer@fedoraproject.org>
+- Backport fix for elantech touchpads (rhbz 1306987)
+
+* Mon Feb 15 2016 Josh Boyer <jwboyer@fedoraproject.org>
+- CVE-2016-2383 incorrect branch fixups for eBPG allow arbitrary reads (rhbz 1308452 1308453)
+- CVE-2016-2384 double free in usb-audio from invalid USB descriptor (rhbz 1308444 1308445)
+
+* Fri Feb 12 2016 Laura Abbott <labbott@fedoraproject.org>
+- Turn off W+X warnings (rhbz 1306885)
+
+* Tue Feb 09 2016 Josh Boyer <jwboyer@fedoraproject.org>
+- CVE-2016-0617 fix hugetlbfs inode.c issues (rhbz 1305803 1305804)
+
 * Mon Feb 01 2016 Laura Abbott <labbott@fedoraproject.org>
 - Linux v4.4.1
 
diff --git a/rtlwifi-rtl8821ae-Fix-5G-failure-when-EEPROM-is-inco.patch b/rtlwifi-rtl8821ae-Fix-5G-failure-when-EEPROM-is-inco.patch
deleted file mode 100644
index eb44e1e08..000000000
--- a/rtlwifi-rtl8821ae-Fix-5G-failure-when-EEPROM-is-inco.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From 933885ecca1a2b8fa03b5756ba1cbb9f094a5861 Mon Sep 17 00:00:00 2001
-From: Larry Finger <Larry.Finger@lwfinger.net>
-Date: Wed, 20 Jan 2016 21:26:18 -0600
-Subject: [PATCH] rtlwifi: rtl8821ae: Fix 5G failure when EEPROM is incorrectly
- encoded
-
-Recently, it has been reported that D-Link DWA-582 cards, which use an
-RTL8812AE chip are not able to scan for 5G networks. The problems started
-with kernel 4.2, which is the first version that had commit d10101a60372
-("rtlwifi: rtl8821ae: Fix problem with regulatory information"). With this
-patch, the driver went from setting a default channel plan to using
-the value derived from EEPROM.
-
-Bug reports at https://bugzilla.kernel.org/show_bug.cgi?id=111031 and
-https://bugzilla.redhat.com/show_bug.cgi?id=1279653 are examples of this
-problem.
-
-The problem was solved once I learned that the internal country code was
-resulting in a regulatory set with only 2.4 GHz channels. With the RTL8821AE
-chips available to me, the country code was such that both 2.4 and 5 GHz
-channels are allowed. The fix is to allow both bands even when the EEPROM
-is incorrectly encoded.
-
-Fixes: d10101a60372 ("rtlwifi: rtl8821ae: Fix problem with regulatory information")
-Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
-Cc: littlesmartguy@gmail.com
-Cc: gabe@codehaus.org
-Cc: Stable <stable@vger.kernel.org> [v4.2+]
----
- drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
-index a62bf0a65c32..5be34118e0af 100644
---- a/drivers/net/wireless/realtek/rtlwifi/regd.c
-+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
-@@ -351,7 +351,6 @@ static const struct ieee80211_regdomain *_rtl_regdomain_select(
- 	case COUNTRY_CODE_SPAIN:
- 	case COUNTRY_CODE_FRANCE:
- 	case COUNTRY_CODE_ISRAEL:
--	case COUNTRY_CODE_WORLD_WIDE_13:
- 		return &rtl_regdom_12_13;
- 	case COUNTRY_CODE_MKK:
- 	case COUNTRY_CODE_MKK1:
-@@ -360,6 +359,7 @@ static const struct ieee80211_regdomain *_rtl_regdomain_select(
- 		return &rtl_regdom_14_60_64;
- 	case COUNTRY_CODE_GLOBAL_DOMAIN:
- 		return &rtl_regdom_14;
-+	case COUNTRY_CODE_WORLD_WIDE_13:
- 	case COUNTRY_CODE_WORLD_WIDE_13_5G_ALL:
- 		return &rtl_regdom_12_13_5g_all;
- 	default:
--- 
-2.5.0
-
diff --git a/sources b/sources
index 21a3807be..e2256619c 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 9a78fa2eb6c68ca5a40ed5af08142599  linux-4.4.tar.xz
 dcbc8fe378a676d5d0dd208cf524e144  perf-man-4.4.tar.gz
-d9e951895c8c249f0bf52d85f3e63bce  patch-4.4.1.xz
+abdfe599a4ea827f9975cf0631148e70  patch-4.4.2.xz
diff --git a/tty-Fix-unsafe-ldisc-reference-via-ioctl-TIOCGETD.patch b/tty-Fix-unsafe-ldisc-reference-via-ioctl-TIOCGETD.patch
deleted file mode 100644
index d169105db..000000000
--- a/tty-Fix-unsafe-ldisc-reference-via-ioctl-TIOCGETD.patch
+++ /dev/null
@@ -1,68 +0,0 @@
-From 938f50fc744cb49892bd42c8f56bdfa63e82a27d Mon Sep 17 00:00:00 2001
-From: Peter Hurley <peter@hurleysoftware.com>
-Date: Sun, 10 Jan 2016 22:40:55 -0800
-Subject: [PATCH] tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)
-
-ioctl(TIOCGETD) retrieves the line discipline id directly from the
-ldisc because the line discipline id (c_line) in termios is untrustworthy;
-userspace may have set termios via ioctl(TCSETS*) without actually
-changing the line discipline via ioctl(TIOCSETD).
-
-However, directly accessing the current ldisc via tty->ldisc is
-unsafe; the ldisc ptr dereferenced may be stale if the line discipline
-is changing via ioctl(TIOCSETD) or hangup.
-
-Wait for the line discipline reference (just like read() or write())
-to retrieve the "current" line discipline id.
-
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
----
- drivers/tty/tty_io.c | 24 +++++++++++++++++++++++-
- 1 file changed, 23 insertions(+), 1 deletion(-)
-
-diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
-index f435977de740..bd4027e36910 100644
---- a/drivers/tty/tty_io.c
-+++ b/drivers/tty/tty_io.c
-@@ -2654,6 +2654,28 @@ static int tiocsetd(struct tty_struct *tty, int __user *p)
- }
- 
- /**
-+ *	tiocgetd	-	get line discipline
-+ *	@tty: tty device
-+ *	@p: pointer to user data
-+ *
-+ *	Retrieves the line discipline id directly from the ldisc.
-+ *
-+ *	Locking: waits for ldisc reference (in case the line discipline
-+ *		is changing or the tty is being hungup)
-+ */
-+
-+static int tiocgetd(struct tty_struct *tty, int __user *p)
-+{
-+	struct tty_ldisc *ld;
-+	int ret;
-+
-+	ld = tty_ldisc_ref_wait(tty);
-+	ret = put_user(ld->ops->num, p);
-+	tty_ldisc_deref(ld);
-+	return ret;
-+}
-+
-+/**
-  *	send_break	-	performed time break
-  *	@tty: device to break on
-  *	@duration: timeout in mS
-@@ -2879,7 +2901,7 @@ long tty_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
- 	case TIOCGSID:
- 		return tiocgsid(tty, real_tty, p);
- 	case TIOCGETD:
--		return put_user(tty->ldisc->ops->num, (int __user *)p);
-+		return tiocgetd(tty, p);
- 	case TIOCSETD:
- 		return tiocsetd(tty, p);
- 	case TIOCVHANGUP:
--- 
-2.5.0
-