diff options
Diffstat (limited to 'debian/patches/bugfix')
5 files changed, 0 insertions, 242 deletions
diff --git a/debian/patches/bugfix/all/USB-usbip-fix-potential-out-of-bounds-write.patch b/debian/patches/bugfix/all/USB-usbip-fix-potential-out-of-bounds-write.patch deleted file mode 100644 index 2a2c4bdb4303..000000000000 --- a/debian/patches/bugfix/all/USB-usbip-fix-potential-out-of-bounds-write.patch +++ /dev/null @@ -1,45 +0,0 @@ -From: Ignat Korchagin <ignat.korchagin@gmail.com> -Date: Thu, 17 Mar 2016 18:00:29 +0000 -Subject: USB: usbip: fix potential out-of-bounds write -Origin: https://git.kernel.org/linus/b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb - -Fix potential out-of-bounds write to urb->transfer_buffer -usbip handles network communication directly in the kernel. When receiving a -packet from its peer, usbip code parses headers according to protocol. As -part of this parsing urb->actual_length is filled. Since the input for -urb->actual_length comes from the network, it should be treated as untrusted. -Any entity controlling the network may put any value in the input and the -preallocated urb->transfer_buffer may not be large enough to hold the data. -Thus, the malicious entity is able to write arbitrary data to kernel memory. - -Signed-off-by: Ignat Korchagin <ignat.korchagin@gmail.com> -Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> ---- - drivers/usb/usbip/usbip_common.c | 11 +++++++++++ - 1 file changed, 11 insertions(+) - -diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c -index facaaf0..e40da77 100644 ---- a/drivers/usb/usbip/usbip_common.c -+++ b/drivers/usb/usbip/usbip_common.c -@@ -741,6 +741,17 @@ int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb) - if (!(size > 0)) - return 0; - -+ if (size > urb->transfer_buffer_length) { -+ /* should not happen, probably malicious packet */ -+ if (ud->side == USBIP_STUB) { -+ usbip_event_add(ud, SDEV_EVENT_ERROR_TCP); -+ return 0; -+ } else { -+ usbip_event_add(ud, VDEV_EVENT_ERROR_TCP); -+ return -EPIPE; -+ } -+ } -+ - ret = usbip_recv(ud->tcp_socket, urb->transfer_buffer, size); - if (ret != size) { - dev_err(&urb->dev->dev, "recv xbuf, %d\n", ret); --- -2.1.4 - diff --git a/debian/patches/bugfix/all/input-gtco-fix-crash-on-detecting-device-without-end.patch b/debian/patches/bugfix/all/input-gtco-fix-crash-on-detecting-device-without-end.patch deleted file mode 100644 index 8908aff65f48..000000000000 --- a/debian/patches/bugfix/all/input-gtco-fix-crash-on-detecting-device-without-end.patch +++ /dev/null @@ -1,53 +0,0 @@ -From: Vladis Dronov <vdronov@redhat.com> -Date: Thu, 31 Mar 2016 10:53:42 -0700 -Subject: Input: gtco - fix crash on detecting device without endpoints -Origin: https://git.kernel.org/linus/162f98dea487206d9ab79fc12ed64700667a894d - -The gtco driver expects at least one valid endpoint. If given malicious -descriptors that specify 0 for the number of endpoints, it will crash in -the probe function. Ensure there is at least one endpoint on the interface -before using it. - -Also let's fix a minor coding style issue. - -The full correct report of this issue can be found in the public -Red Hat Bugzilla: - -https://bugzilla.redhat.com/show_bug.cgi?id=1283385 - -Reported-by: Ralf Spenneberg <ralf@spenneberg.net> -Signed-off-by: Vladis Dronov <vdronov@redhat.com> -Cc: stable@vger.kernel.org -Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> ---- - drivers/input/tablet/gtco.c | 10 +++++++++- - 1 file changed, 9 insertions(+), 1 deletion(-) - -diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c -index 3a7f3a4a4396..7c18249d6c8e 100644 ---- a/drivers/input/tablet/gtco.c -+++ b/drivers/input/tablet/gtco.c -@@ -858,6 +858,14 @@ static int gtco_probe(struct usb_interface *usbinterface, - goto err_free_buf; - } - -+ /* Sanity check that a device has an endpoint */ -+ if (usbinterface->altsetting[0].desc.bNumEndpoints < 1) { -+ dev_err(&usbinterface->dev, -+ "Invalid number of endpoints\n"); -+ error = -EINVAL; -+ goto err_free_urb; -+ } -+ - /* - * The endpoint is always altsetting 0, we know this since we know - * this device only has one interrupt endpoint -@@ -879,7 +887,7 @@ static int gtco_probe(struct usb_interface *usbinterface, - * HID report descriptor - */ - if (usb_get_extra_descriptor(usbinterface->cur_altsetting, -- HID_DEVICE_TYPE, &hid_desc) != 0){ -+ HID_DEVICE_TYPE, &hid_desc) != 0) { - dev_err(&usbinterface->dev, - "Can't retrieve exta USB descriptor to get hid report descriptor length\n"); - error = -EIO; diff --git a/debian/patches/bugfix/all/memcg-remove-lru_add_drain_all-invocation-from-mem_cgroup_move_charge.patch b/debian/patches/bugfix/all/memcg-remove-lru_add_drain_all-invocation-from-mem_cgroup_move_charge.patch deleted file mode 100644 index c0b89464559c..000000000000 --- a/debian/patches/bugfix/all/memcg-remove-lru_add_drain_all-invocation-from-mem_cgroup_move_charge.patch +++ /dev/null @@ -1,42 +0,0 @@ -From: Tejun Heo <tj@kernel.org> -Subject: memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge() -Date: Thu, 21 Apr 2016 11:56:52 -0400 -Origin: http://permalink.gmane.org/gmane.linux.kernel.cgroups/15918 -Bug-Debian: https://bugs.debian.org/822084 - -mem_cgroup_move_charge() invokes lru_add_drain_all() so that the pvec -pages can be moved too. lru_add_drain_all() schedules and flushes -work items on system_wq which depends on being able to create new -kworkers to make forward progress. Since 1ed1328792ff ("sched, -cgroup: replace signal_struct->group_rwsem with a global -percpu_rwsem"), a new task can't be created while in the cgroup -migration path and the described lru_add_drain_all() invocation can -easily lead to a deadlock. - -Charge moving is best-effort and whether the pvec pages are migrated -or not doesn't really matter. Don't call it during charge moving. -Eventually, we want to move the actual charge moving outside the -migration path. - -Signed-off-by: Tejun Heo <tj@kernel.org> -Debugged-and-tested-by: Petr Mladek <pmladek@suse.com> -Reported-by: Cyril Hrubis <chrubis@suse.cz> -Reported-by: Johannes Weiner <hannes@cmpxchg.org> -Suggested-by: Michal Hocko <mhocko@kernel.org> -Acked-by: Michal Hocko <mhocko@suse.com> -Fixes: 1ed1328792ff ("sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem") -Cc: stable@vger.kernel.org # v4.4+ ---- - mm/memcontrol.c | 1 - - 1 file changed, 1 deletion(-) - ---- a/mm/memcontrol.c -+++ b/mm/memcontrol.c -@@ -4922,7 +4922,6 @@ static void mem_cgroup_move_charge(struc - .mm = mm, - }; - -- lru_add_drain_all(); - /* - * Signal mem_cgroup_begin_page_stat() to take the memcg's - * move_lock while we're moving its pages to another memcg. diff --git a/debian/patches/bugfix/all/misc-bmp085-Enable-building-as-a-module.patch b/debian/patches/bugfix/all/misc-bmp085-Enable-building-as-a-module.patch deleted file mode 100644 index c3c5a629f4ba..000000000000 --- a/debian/patches/bugfix/all/misc-bmp085-Enable-building-as-a-module.patch +++ /dev/null @@ -1,29 +0,0 @@ -From: Ben Hutchings <ben@decadent.org.uk> -Date: Mon, 24 Jun 2013 05:28:00 +0100 -Subject: misc/bmp085: Enable building as a module -Forwarded: http://thread.gmane.org/gmane.linux.kernel/1514281 - -Commit 985087dbcb02 'misc: add support for bmp18x chips to the bmp085 -driver' changed the BMP085 config symbol to a boolean. I see no -reason why the shared code cannot be built as a module, so change it -back to tristate. - -Cc: Eric Andersson <eric.andersson@unixphere.com> -Signed-off-by: Ben Hutchings <ben@decadent.org.uk> ---- - drivers/misc/Kconfig | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig -index c002d86..7a68184 100644 ---- a/drivers/misc/Kconfig -+++ b/drivers/misc/Kconfig -@@ -451,7 +451,7 @@ config ARM_CHARLCD - still useful. - - config BMP085 -- bool -+ tristate - depends on SYSFS - - config BMP085_I2C diff --git a/debian/patches/bugfix/x86/x86-xen-suppress-hugetlbfs-in-PV-guests.patch b/debian/patches/bugfix/x86/x86-xen-suppress-hugetlbfs-in-PV-guests.patch deleted file mode 100644 index 4fe6018f486b..000000000000 --- a/debian/patches/bugfix/x86/x86-xen-suppress-hugetlbfs-in-PV-guests.patch +++ /dev/null @@ -1,73 +0,0 @@ -From: Jan Beulich <jbeulich@suse.com> -Date: Thu, 14 Apr 2016 20:38:30 +0200 -Subject: x86/xen: suppress hugetlbfs in PV guests -Origin: http://xenbits.xen.org/xsa/xsa174.patch - -Huge pages are not normally available to PV guests. Not suppressing -hugetlbfs use results in an endless loop of page faults when user mode -code tries to access a hugetlbfs mapped area (since the hypervisor -denies such PTEs to be created, but error indications can't be -propagated out of xen_set_pte_at(), just like for various of its -siblings), and - once killed in an oops like this: - -kernel BUG at .../fs/hugetlbfs/inode.c:428! -invalid opcode: 0000 [#1] SMP -Modules linked in: ... -Supported: Yes -CPU: 2 PID: 6088 Comm: hugetlbfs Tainted: G W 4.4.0-2016-01-20-pv #2 -Hardware name: ... -task: ffff8808059205c0 ti: ffff880803c84000 task.ti: ffff880803c84000 -RIP: e030:[<ffffffff811c333b>] [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320 -RSP: e02b:ffff880803c879a8 EFLAGS: 00010202 -RAX: 000000000077a4db RBX: ffffea001acff000 RCX: 0000000078417d38 -RDX: 0000000000000000 RSI: 000000007e154fa7 RDI: ffff880805d70960 -RBP: 0000000000000960 R08: 0000000000000000 R09: 0000000000000000 -R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 -R13: ffff880807486018 R14: 0000000000000000 R15: ffff880803c87af0 -FS: 00007f85fa8b8700(0000) GS:ffff88080b640000(0000) knlGS:0000000000000000 -CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b -CR2: 00007f85fa000000 CR3: 0000000001a0a000 CR4: 0000000000040660 -Stack: - ffff880000000fb0 ffff880803c87a18 ffff880803c87ae8 ffff8808059205c0 - ffff880803c87af0 ffff880803c87ae8 ffff880807486018 0000000000000000 - ffffffff81bf6e60 ffff880807486168 000003ffffffffff 0000000003c87758 -Call Trace: - [<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40 - [<ffffffff81167b3d>] evict+0xbd/0x1b0 - [<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0 - [<ffffffff81165b0e>] dput+0x1fe/0x220 - [<ffffffff81150535>] __fput+0x155/0x200 - [<ffffffff81079fc0>] task_work_run+0x60/0xa0 - [<ffffffff81063510>] do_exit+0x160/0x400 - [<ffffffff810637eb>] do_group_exit+0x3b/0xa0 - [<ffffffff8106e8bd>] get_signal+0x1ed/0x470 - [<ffffffff8100f854>] do_signal+0x14/0x110 - [<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0 - [<ffffffff814178a5>] retint_user+0x8/0x13 - -This is XSA-174. - -Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> -Signed-off-by: Jan Beulich <jbeulich@suse.com> -Cc: stable@vger.kernel.org ---- -v2: Make Xen-inspecific, by using cpu_has_pse. ---- - arch/x86/include/asm/hugetlb.h | 1 + - 1 file changed, 1 insertion(+) - -diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h -index f8a29d2..e6a8613 100644 ---- a/arch/x86/include/asm/hugetlb.h -+++ b/arch/x86/include/asm/hugetlb.h -@@ -4,6 +4,7 @@ - #include <asm/page.h> - #include <asm-generic/hugetlb.h> - -+#define hugepages_supported() cpu_has_pse - - static inline int is_hugepage_only_range(struct mm_struct *mm, - unsigned long addr, --- -2.8.0.rc3 - |