Linux v3.8.4

- CVE-2013-1873 information leaks via netlink interface (rhbz 923652 923662)
This commit is contained in:
Josh Boyer 2013-03-20 16:39:02 -04:00
parent 8d496427eb
commit eed7f51b23
11 changed files with 7 additions and 856 deletions

View File

@ -1,63 +0,0 @@
From b81273a132177edd806476b953f6afeb17b786d5 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Tue, 15 Jan 2013 23:26:22 +0100
Subject: [PATCH] TTY: do not reset master's packet mode
Now that login from util-linux is forced to drop all references to a
TTY which it wants to hangup (to reach reference count 1) we are
seeing issues with telnet. When login closes its last reference to the
slave PTY, it also resets packet mode on the *master* side. And we
have a race here.
What telnet does is fork+exec of `login'. Then there are two
scenarios:
* `login' closes the slave TTY and resets thus master's packet mode,
but even now telnet properly sets the mode, or
* `telnetd' sets packet mode on the master, `login' closes the slave
TTY and resets master's packet mode.
The former case is OK. However the latter happens in much more cases,
by the order of magnitude to be precise. So when one tries to login to
such a messed telnet setup, they see the following:
inux login:
ogin incorrect
Note the missing first letters -- telnet thinks it is still in the
packet mode, so when it receives "linux login" from `login', it
considers "l" as the type of the packet and strips it.
SuS does not mention how the implementation should behave. Both BSDs I
checked (Free and Net) do not reset the flag upon the last close.
By this I am resurrecting an old bug, see References. We are hitting
it regularly now, i.e. with updated util-linux, ergo login.
Here, I am changing a behavior introduced back in 2.1 times. It would
better have a long time testing before goes upstream.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Bryan Mason <bmason@redhat.com>
References: https://lkml.org/lkml/2009/11/11/223
References: https://bugzilla.redhat.com/show_bug.cgi?id=504703
References: https://bugzilla.novell.com/show_bug.cgi?id=797042
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/pty.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 4ec11f3..40ff2bf 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -47,7 +47,6 @@ static void pty_close(struct tty_struct *tty, struct file *filp)
/* Review - krefs on tty_link ?? */
if (!tty->link)
return;
- tty->link->packet = 0;
set_bit(TTY_OTHER_CLOSED, &tty->link->flags);
wake_up_interruptible(&tty->link->read_wait);
wake_up_interruptible(&tty->link->write_wait);
--
1.8.1.2

View File

@ -1,88 +0,0 @@
From c0f5ecee4e741667b2493c742b60b6218d40b3aa Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.de>
Date: Tue, 12 Mar 2013 14:52:42 +0100
Subject: [PATCH] USB: cdc-wdm: fix buffer overflow
The buffer for responses must not overflow.
If this would happen, set a flag, drop the data and return
an error after user space has read all remaining data.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
CC: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/class/cdc-wdm.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 5f0cb41..122d056 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -56,6 +56,7 @@ MODULE_DEVICE_TABLE (usb, wdm_ids);
#define WDM_RESPONDING 7
#define WDM_SUSPENDING 8
#define WDM_RESETTING 9
+#define WDM_OVERFLOW 10
#define WDM_MAX 16
@@ -155,6 +156,7 @@ static void wdm_in_callback(struct urb *urb)
{
struct wdm_device *desc = urb->context;
int status = urb->status;
+ int length = urb->actual_length;
spin_lock(&desc->iuspin);
clear_bit(WDM_RESPONDING, &desc->flags);
@@ -185,9 +187,17 @@ static void wdm_in_callback(struct urb *urb)
}
desc->rerr = status;
- desc->reslength = urb->actual_length;
- memmove(desc->ubuf + desc->length, desc->inbuf, desc->reslength);
- desc->length += desc->reslength;
+ if (length + desc->length > desc->wMaxCommand) {
+ /* The buffer would overflow */
+ set_bit(WDM_OVERFLOW, &desc->flags);
+ } else {
+ /* we may already be in overflow */
+ if (!test_bit(WDM_OVERFLOW, &desc->flags)) {
+ memmove(desc->ubuf + desc->length, desc->inbuf, length);
+ desc->length += length;
+ desc->reslength = length;
+ }
+ }
skip_error:
wake_up(&desc->wait);
@@ -435,6 +445,11 @@ retry:
rv = -ENODEV;
goto err;
}
+ if (test_bit(WDM_OVERFLOW, &desc->flags)) {
+ clear_bit(WDM_OVERFLOW, &desc->flags);
+ rv = -ENOBUFS;
+ goto err;
+ }
i++;
if (file->f_flags & O_NONBLOCK) {
if (!test_bit(WDM_READ, &desc->flags)) {
@@ -478,6 +493,7 @@ retry:
spin_unlock_irq(&desc->iuspin);
goto retry;
}
+
if (!desc->reslength) { /* zero length read */
dev_dbg(&desc->intf->dev, "%s: zero length - clearing WDM_READ\n", __func__);
clear_bit(WDM_READ, &desc->flags);
@@ -1004,6 +1020,7 @@ static int wdm_post_reset(struct usb_interface *intf)
struct wdm_device *desc = wdm_find_device(intf);
int rv;
+ clear_bit(WDM_OVERFLOW, &desc->flags);
clear_bit(WDM_RESETTING, &desc->flags);
rv = recover_from_urb_loss(desc);
mutex_unlock(&desc->wlock);
--
1.8.1.2

View File

@ -1,206 +0,0 @@
From 52d7ecedac3f96fb562cb482c139015372728638 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat, 1 Dec 2012 21:03:22 +0100
Subject: drm/i915: reorder setup sequence to have irqs for output setup
From: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).
v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.
v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.
v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.
v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.
v6: Fixup cleanup sequence, too.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_dma.c | 23 ++++++++++++++---------
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 4 ++++
3 files changed, 19 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1297,19 +1297,21 @@ static int i915_load_modeset_init(struct
if (ret)
goto cleanup_vga_switcheroo;
+ ret = drm_irq_install(dev);
+ if (ret)
+ goto cleanup_gem_stolen;
+
+ /* Important: The output setup functions called by modeset_init need
+ * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
ret = i915_gem_init(dev);
if (ret)
- goto cleanup_gem_stolen;
-
- intel_modeset_gem_init(dev);
+ goto cleanup_irq;
INIT_WORK(&dev_priv->console_resume_work, intel_console_resume);
- ret = drm_irq_install(dev);
- if (ret)
- goto cleanup_gem;
+ intel_modeset_gem_init(dev);
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */
@@ -1317,7 +1319,10 @@ static int i915_load_modeset_init(struct
ret = intel_fbdev_init(dev);
if (ret)
- goto cleanup_irq;
+ goto cleanup_gem;
+
+ /* Only enable hotplug handling once the fbdev is fully set up. */
+ dev_priv->enable_hotplug_processing = true;
drm_kms_helper_poll_init(dev);
@@ -1326,13 +1331,13 @@ static int i915_load_modeset_init(struct
return 0;
-cleanup_irq:
- drm_irq_uninstall(dev);
cleanup_gem:
mutex_lock(&dev->struct_mutex);
i915_gem_cleanup_ringbuffer(dev);
mutex_unlock(&dev->struct_mutex);
i915_gem_cleanup_aliasing_ppgtt(dev);
+cleanup_irq:
+ drm_irq_uninstall(dev);
cleanup_gem_stolen:
i915_gem_cleanup_stolen(dev);
cleanup_vga_switcheroo:
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,6 +672,7 @@ typedef struct drm_i915_private {
u32 hotplug_supported_mask;
struct work_struct hotplug_work;
+ bool enable_hotplug_processing;
int num_pipe;
int num_pch_pll;
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -287,6 +287,10 @@ static void i915_hotplug_work_func(struc
struct drm_mode_config *mode_config = &dev->mode_config;
struct intel_encoder *encoder;
+ /* HPD irq before everything is fully set up. */
+ if (!dev_priv->enable_hotplug_processing)
+ return;
+
mutex_lock(&mode_config->mutex);
DRM_DEBUG_KMS("running encoder hotplug functions\n");
From 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue, 5 Mar 2013 09:50:58 +0100
Subject: drm/i915: enable irqs earlier when resuming
From: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 upstream.
We need it to restore the ilk rc6 context, since the gpu wait no
requires interrupts. But in general having interrupts around should
help in code sanity, since more and more stuff is interrupt driven.
This regression has been introduced in
commit 3e9605018ab3e333d51cc90fccfde2031886763b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 27 16:22:54 2012 +0000
drm/i915: Rearrange code to only have a single method for waiting upon the ring
Like in the driver load code we need to make sure that hotplug
interrupts don't cause havoc with our modeset state, hence block them
with the existing infrastructure. Again we ignore races where we might
loose hotplug interrupts ...
Note that the driver load part of the regression has already been
fixed in
commit 52d7ecedac3f96fb562cb482c139015372728638
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Dec 1 21:03:22 2012 +0100
drm/i915: reorder setup sequence to have irqs for output setup
v2: Add a note to the commit message about which patch fixed the
driver load part of the regression. Stable kernels need to backport
both patches.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-and-Tested-by: Ilya Tumaykin <itumaykin@gmail.com>
Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -486,6 +486,7 @@ static int i915_drm_freeze(struct drm_de
intel_modeset_disable(dev);
drm_irq_uninstall(dev);
+ dev_priv->enable_hotplug_processing = false;
}
i915_save_state(dev);
@@ -562,9 +563,19 @@ static int __i915_drm_thaw(struct drm_de
error = i915_gem_init_hw(dev);
mutex_unlock(&dev->struct_mutex);
+ /* We need working interrupts for modeset enabling ... */
+ drm_irq_install(dev);
+
intel_modeset_init_hw(dev);
intel_modeset_setup_hw_state(dev, false);
- drm_irq_install(dev);
+
+ /*
+ * ... but also need to make sure that hotplug processing
+ * doesn't cause havoc. Like in the driver load code we don't
+ * bother with the tiny race here where we might loose hotplug
+ * notifications.
+ * */
+ dev_priv->enable_hotplug_processing = true;
}
intel_opregion_init(dev);

View File

@ -1,92 +0,0 @@
On Wed, 2013-03-06 at 10:59 -0500, Dave Jones wrote:
> I know 3.7.9 is EOL, but this code doesn't look like it's changed in current.
> (unless the cause/fix was in code unrelated to these paths)
>
> A user reported the following GPF..
>
> general protection fault: 0000 [#1] SMP
> Modules linked in: ipheth fuse ebtable_nat xt_CHECKSUM bridge stp llc ip6t_REJECT iptable_mangle nf_conntrack(-) ebtable_filter ebtables snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc hp_wmi snd_timer coretemp iTCO_wdt tg3 snd sparse_keymap rfkill soundcore iTCO_vendor_support lpc_ich i7core_edac edac_core serio_raw microcode mfd_core vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc uinput nouveau mxm_wmi crc32c_intel video i2c_algo_bit drm_kms_helper ttm firewire_ohci firewire_core drm crc_itu_t i2c_core wmi [last unloaded: xt_conntrack]
> CPU 2
> Pid: 25407, comm: qemu-kvm Not tainted 3.7.9-205.fc18.x86_64 #1 Hewlett-Packard HP Z400 Workstation/0B4Ch
> RIP: 0010:[<ffffffffa0399bd5>] [<ffffffffa0399bd5>] destroy_conntrack+0x35/0x120 [nf_conntrack]
> RSP: 0018:ffff880276913d78 EFLAGS: 00010206
> RAX: 50626b6b7876376c RBX: ffff88026e530d68 RCX: ffff88028d158e00
> RDX: ffff88026d0d5470 RSI: 0000000000000011 RDI: 0000000000000002
> RBP: ffff880276913d88 R08: 0000000000000000 R09: ffff880295002900
> R10: 0000000000000000 R11: 0000000000000003 R12: ffffffff81ca3b40
> R13: ffffffff8151a8e0 R14: ffff880270875000 R15: 0000000000000002
> FS: 00007ff3bce38a00(0000) GS:ffff88029fc40000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007fd1430bd000 CR3: 000000027042b000 CR4: 00000000000027e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process qemu-kvm (pid: 25407, threadinfo ffff880276912000, task ffff88028c369720)
> Stack:
> ffff880156f59100 ffff880156f59100 ffff880276913d98 ffffffff815534f7
> ffff880276913db8 ffffffff8151a74b ffff880270875000 ffff880156f59100
> ffff880276913dd8 ffffffff8151a5a6 ffff880276913dd8 ffff88026d0d5470
> Call Trace:
> [<ffffffff815534f7>] nf_conntrack_destroy+0x17/0x20
> [<ffffffff8151a74b>] skb_release_head_state+0x7b/0x100
> [<ffffffff8151a5a6>] __kfree_skb+0x16/0xa0
> [<ffffffff8151a666>] kfree_skb+0x36/0xa0
> [<ffffffff8151a8e0>] skb_queue_purge+0x20/0x40
> [<ffffffffa02205f7>] __tun_detach+0x117/0x140 [tun]
> [<ffffffffa022184c>] tun_chr_close+0x3c/0xd0 [tun]
> [<ffffffff8119669c>] __fput+0xec/0x240
> [<ffffffff811967fe>] ____fput+0xe/0x10
> [<ffffffff8107eb27>] task_work_run+0xa7/0xe0
> [<ffffffff810149e1>] do_notify_resume+0x71/0xb0
> [<ffffffff81640152>] int_signal+0x12/0x17
> Code: 00 00 04 48 89 e5 41 54 53 48 89 fb 4c 8b a7 e8 00 00 00 0f 85 de 00 00 00 0f b6 73 3e 0f b7 7b 2a e8 10 40 00 00 48 85 c0 74 0e <48> 8b 40 28 48 85 c0 74 05 48 89 df ff d0 48 c7 c7 08 6a 3a a0
> RIP [<ffffffffa0399bd5>] destroy_conntrack+0x35/0x120 [nf_conntrack]
> RSP <ffff880276913d78>
>
>
>
> /* To make sure we don't get any weird locking issues here:
> * destroy_conntrack() MUST NOT be called with a write lock
> * to nf_conntrack_lock!!! -HW */
> rcu_read_lock();
> l4proto = __nf_ct_l4proto_find(nf_ct_l3num(ct), nf_ct_protonum(ct));
> 1378: 0f b6 b3 86 00 00 00 movzbl 0x86(%rbx),%esi
> 137f: 0f b7 7b 72 movzwl 0x72(%rbx),%edi
> 1383: e8 00 00 00 00 callq 1388 <destroy_conntrack+0x78>
> if (l4proto && l4proto->destroy)
> 1388: 48 85 c0 test %rax,%rax
> 138b: 74 0e je 139b <destroy_conntrack+0x8b>
> 138d: 48 8b 40 28 mov 0x28(%rax),%rax <----- HERE
> 1391: 48 85 c0 test %rax,%rax
> 1394: 74 05 je 139b <destroy_conntrack+0x8b>
> l4proto->destroy(ct);
> 1396: 48 89 df mov %rbx,%rdi
> 1399: ff d0 callq *%rax
>
>
> l4proto (%rax) is garbage (0x50626b6b7876376c) which looks a little like ascii,
> but P>kkxv7l doesn't mean much to me.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=917792 is the original report, but
> there aren't any further details yet.
>
> Dave
>
tun driver lacks a nf_reset(skb) call
I would try :
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2c6a22e..b7c457a 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -747,6 +747,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
goto drop;
skb_orphan(skb);
+ nf_reset(skb);
+
/* Enqueue packet */
skb_queue_tail(&tfile->socket.sk->sk_receive_queue, skb);

View File

@ -54,7 +54,7 @@ Summary: The Linux kernel
# For non-released -rc kernels, this will be appended after the rcX and
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
#
%global baserelease 104
%global baserelease 101
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@ -66,7 +66,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 3
%define stable_update 4
# Is it a -stable RC?
%define stable_rc 0
# Set rpm version accordingly
@ -645,7 +645,6 @@ Patch520: quite-apm.patch
Patch530: silence-fbcon-logo.patch
Patch540: silence-empty-ipi-mask-warning.patch
Patch541: silence-tty-null.patch
Patch800: crash-driver.patch
@ -734,37 +733,19 @@ Patch22262: x86-mm-Fix-vmalloc_fault-oops-during-lazy-MMU-updates.patch
#rhbz 916544
Patch22263: 0001-drivers-crypto-nx-fix-init-race-alignmasks-and-GCM-b.patch
#CVE-2013-1828 rhbz 919315 919316
Patch22269: net-sctp-Validate-parameter-size-for-SCTP_GET_ASSOC_.patch
#rhbz 812111
Patch24000: alps.patch
Patch24100: userns-avoid-recursion-in-put_user_ns.patch
#rhbz 859346
Patch24101: fix-destroy_conntrack-GPF.patch
#rhbz 917353
Patch24102: backlight_revert.patch
Patch24103: turbostat-makefile.diff
#rhbz 904182
Patch24104: TTY-do-not-reset-master-s-packet-mode.patch
#rhbz 857954
Patch24105: w1-fix-oops-when-w1_search-is-called-from.patch
#rhbz 911771
Patch24106: serial-8250-Keep-8250.-xxxx-module-options-functiona.patch
#rhbz 879462
Patch24107: uvcvideo-suspend-fix.patch
#CVE-2013-0914 rhbz 920499 920510
Patch24108: signal-always-clear-sa_restorer-on-execve.patch
#CVE-2013-0913 rhbz 920471 920529
Patch24109: drm-i915-bounds-check-execbuffer-relocation-count.patch
@ -775,18 +756,12 @@ Patch24112: mac80211_fixes_for_ieee80211_do_stop_while_suspend_v3.8.patch
#rhbz 859282
Patch24113: VMX-x86-handle-host-TSC-calibration-failure.patch
#CVE-2013-1860 rhbz 921970 922004
Patch24114: USB-cdc-wdm-fix-buffer-overflow.patch
#rhbz 920586
Patch25000: amd64_edac_fix_rank_count.patch
#rhbz 921500
Patch25001: i7300_edac_single_mode_fixup.patch
#rhbz 922304
Patch25002: drm-ilk-rc6-reverts.patch
#CVE-2013-1798 rhbz 917017 923968
Patch25003: 0001-KVM-Fix-bounds-checking-in-ioapic-indirect-register-.patch
@ -1409,7 +1384,6 @@ ApplyPatch silence-fbcon-logo.patch
# No-one cares about these warnings
ApplyPatch silence-empty-ipi-mask-warning.patch
ApplyPatch silence-tty-null.patch
# Changes to upstream defaults.
@ -1493,12 +1467,6 @@ ApplyPatch 0001-drivers-crypto-nx-fix-init-race-alignmasks-and-GCM-b.patch
ApplyPatch userns-avoid-recursion-in-put_user_ns.patch
#rhbz 859346
ApplyPatch fix-destroy_conntrack-GPF.patch
#CVE-2013-1828 rhbz 919315 919316
ApplyPatch net-sctp-Validate-parameter-size-for-SCTP_GET_ASSOC_.patch
#rhbz 917353
ApplyPatch backlight_revert.patch -R
@ -1510,21 +1478,9 @@ ApplyPatch amd64_edac_fix_rank_count.patch
#rhbz 921500
ApplyPatch i7300_edac_single_mode_fixup.patch
#rhbz 904182
ApplyPatch TTY-do-not-reset-master-s-packet-mode.patch
#rhbz 857954
ApplyPatch w1-fix-oops-when-w1_search-is-called-from.patch
#rhbz 911771
ApplyPatch serial-8250-Keep-8250.-xxxx-module-options-functiona.patch
#rhbz 879462
ApplyPatch uvcvideo-suspend-fix.patch
#CVE-2013-0914 rhbz 920499 920510
ApplyPatch signal-always-clear-sa_restorer-on-execve.patch
#CVE-2013-0913 rhbz 920471 920529
ApplyPatch drm-i915-bounds-check-execbuffer-relocation-count.patch
@ -1535,12 +1491,6 @@ ApplyPatch mac80211_fixes_for_ieee80211_do_stop_while_suspend_v3.8.patch
#rhbz 859282
ApplyPatch VMX-x86-handle-host-TSC-calibration-failure.patch
#CVE-2013-1860 rhbz 921970 922004
ApplyPatch USB-cdc-wdm-fix-buffer-overflow.patch
#rhbz 922304
ApplyPatch drm-ilk-rc6-reverts.patch -R
#CVE-2013-1798 rhbz 917017 923968
ApplyPatch 0001-KVM-Fix-bounds-checking-in-ioapic-indirect-register-.patch
@ -2406,6 +2356,10 @@ fi
# '-' | |
# '-'
%changelog
* Wed Mar 20 2013 Josh Boyer <jwboyer@redhat.com> - 3.8.4-101
- Linux v3.8.4
- CVE-2013-1873 information leaks via netlink interface (rhbz 923652 923662)
* Wed Mar 20 2013 Josh Boyer <jwboyer@redhat.com>
- CVE-2013-1796 kvm: buffer overflow in handling of MSR_KVM_SYSTEM_TIME
(rhbz 917012 923966)

View File

@ -1,54 +0,0 @@
From 726bc6b092da4c093eb74d13c07184b18c1af0f1 Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux@roeck-us.net>
Date: Wed, 27 Feb 2013 10:57:31 +0000
Subject: [PATCH] net/sctp: Validate parameter size for SCTP_GET_ASSOC_STATS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Building sctp may fail with:
In function copy_from_user,
inlined from sctp_getsockopt_assoc_stats at
net/sctp/socket.c:5656:20:
arch/x86/include/asm/uaccess_32.h:211:26: error: call to
copy_from_user_overflow declared with attribute error: copy_from_user()
buffer size is not provably correct
if built with W=1 due to a missing parameter size validation
before the call to copy_from_user.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sctp/socket.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index cedd9bf..9ef5c73 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5653,6 +5653,9 @@ static int sctp_getsockopt_assoc_stats(struct sock *sk, int len,
if (len < sizeof(sctp_assoc_t))
return -EINVAL;
+ /* Allow the struct to grow and fill in as much as possible */
+ len = min_t(size_t, len, sizeof(sas));
+
if (copy_from_user(&sas, optval, len))
return -EFAULT;
@@ -5686,9 +5689,6 @@ static int sctp_getsockopt_assoc_stats(struct sock *sk, int len,
/* Mark beginning of a new observation period */
asoc->stats.max_obs_rto = asoc->rto_min;
- /* Allow the struct to grow and fill in as much as possible */
- len = min_t(size_t, len, sizeof(sas));
-
if (put_user(len, optlen))
return -EFAULT;
--
1.8.1.2

View File

@ -1,63 +0,0 @@
From e94256528a988231ccc7a2a0b6b206a1131cb358 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 8 Mar 2013 21:13:52 -0500
Subject: [PATCH] serial: 8250: Keep 8250.<xxxx> module options functional
after driver rename
With commit 835d844d1 (8250_pnp: do pnp probe before legacy probe), the
8250 driver was renamed to 8250_core. This means any existing usage of
the 8259.<xxxx> module parameters or as a kernel command line switch is
now broken, as the 8250_core driver doesn't parse options belonging to
something called "8250".
To solve this, we redefine the module options in a dummy function using
a redefined MODULE_PARAM_PREFX when built into the kernel. In the case
where we're building as a module, we provide an alias to the old 8250
name. The dummy function prevents compiler errors due to global variable
redefinitions that happen as part of the module_param_ macro expansions.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
---
drivers/tty/serial/8250/8250.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 0efc815..f982633 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -3396,3 +3396,32 @@ module_param_array(probe_rsa, ulong, &probe_rsa_count, 0444);
MODULE_PARM_DESC(probe_rsa, "Probe I/O ports for RSA");
#endif
MODULE_ALIAS_CHARDEV_MAJOR(TTY_MAJOR);
+
+#ifndef MODULE
+/* This module was renamed to 8250_core in 3.7. Keep the old "8250" name
+ * working as well for the module options so we don't break people. We
+ * need to keep the names identical and the convenient macros will happily
+ * refuse to let us do that by failing the build with redefinition errors
+ * of global variables. So we stick them inside a dummy function to avoid
+ * those conflicts. The options still get parsed, and the redefined
+ * MODULE_PARAM_PREFIX lets us keep the "8250." syntax alive.
+ *
+ * This is hacky. I'm sorry.
+ */
+static void __used s8250_options(void)
+{
+#undef MODULE_PARAM_PREFIX
+#define MODULE_PARAM_PREFIX "8250."
+
+ module_param_cb(share_irqs, &param_ops_uint, &share_irqs, 0644);
+ module_param_cb(nr_uarts, &param_ops_uint, &nr_uarts, 0644);
+ module_param_cb(skip_txen_test, &param_ops_uint, &skip_txen_test, 0644);
+#ifdef CONFIG_SERIAL_8250_RSA
+ __module_param_call(MODULE_PARAM_PREFIX, probe_rsa,
+ &param_array_ops, .arr = &__param_arr_probe_rsa,
+ 0444, -1);
+#endif
+}
+#else
+MODULE_ALIAS("8250");
+#endif
--
1.8.1.2

View File

@ -1,113 +0,0 @@
Delivered-To: jwboyer@gmail.com
Received: by 10.76.169.233 with SMTP id ah9csp99159oac;
Mon, 11 Mar 2013 13:14:17 -0700 (PDT)
X-Received: by 10.68.179.1 with SMTP id dc1mr24297029pbc.128.1363032856671;
Mon, 11 Mar 2013 13:14:16 -0700 (PDT)
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
by mx.google.com with ESMTP id tx10si24737165pbc.272.2013.03.11.13.14.10;
Mon, 11 Mar 2013 13:14:16 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mail=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1754069Ab3CKUN4 (ORCPT <rfc822;cpulmkl@gmail.com> + 99 others);
Mon, 11 Mar 2013 16:13:56 -0400
Received: from smtp.outflux.net ([198.145.64.163]:59839 "EHLO smtp.outflux.net"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1753913Ab3CKUN4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
Mon, 11 Mar 2013 16:13:56 -0400
Received: from www.outflux.net (serenity-end.outflux.net [10.2.0.2])
by vinyl.outflux.net (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id r2BKDgjn022201;
Mon, 11 Mar 2013 13:13:43 -0700
Date: Mon, 11 Mar 2013 13:13:42 -0700
From: Kees Cook <keescook@chromium.org>
To: linux-kernel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>, Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Emese Revfy <re.emese@gmail.com>,
PaX Team <pageexec@freemail.hu>, jln@google.com
Subject: [PATCH v2] signal: always clear sa_restorer on execve
Message-ID: <20130311201342.GA19824@www.outflux.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-MIMEDefang-Filter: outflux$Revision: 1.316 $
X-HELO: www.outflux.net
X-Scanned-By: MIMEDefang 2.71 on 10.2.0.1
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
When the new signal handlers are set up, the location of sa_restorer
is not cleared, leaking a parent process's address space location to
children. This allows for a potential bypass of the parent's ASLR by
examining the sa_restorer value returned when calling sigaction().
Based on what should be considered "secret" about addresses, it only
matters across the exec not the fork (since the VMAs haven't changed
until the exec). But since exec sets SIG_DFL and keeps sa_restorer,
this is where it should be fixed.
Given the few uses of sa_restorer, a "set" function was not written
since this would be the only use. Instead, we use __ARCH_HAS_SA_RESTORER,
as already done in other places.
Example of the leak before applying this patch:
$ cat /proc/$$/maps
...
7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
...
$ ./leak
...
7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
...
1 0 (nil) 0x7fb9f30b94a0
2 4000000 (nil) 0x7f278bcaa4a0
3 4000000 (nil) 0x7f278bcaa4a0
4 0 (nil) 0x7fb9f30b94a0
...
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Emese Revfy <re.emese@gmail.com>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: stable@vger.kernel.org
---
v2:
- clarify commit, explain use of #ifdef.
---
kernel/signal.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 2ec870a..8c8e3ca 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -485,6 +485,9 @@ flush_signal_handlers(struct task_struct *t, int force_default)
if (force_default || ka->sa.sa_handler != SIG_IGN)
ka->sa.sa_handler = SIG_DFL;
ka->sa.sa_flags = 0;
+#ifdef SA_RESTORER
+ ka->sa.sa_restorer = NULL;
+#endif
sigemptyset(&ka->sa.sa_mask);
ka++;
}
--
1.7.9.5
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

View File

@ -1,13 +0,0 @@
This should be fixed in 3.9, but is unlikely to be backported.
--- linux-3.8.1-201.fc18.x86_64/drivers/tty/tty_buffer.c~ 2013-03-01 11:07:37.498291384 -0500
+++ linux-3.8.1-201.fc18.x86_64/drivers/tty/tty_buffer.c 2013-03-01 11:08:11.088250537 -0500
@@ -473,7 +473,7 @@ static void flush_to_ldisc(struct work_s
struct tty_ldisc *disc;
tty = port->itty;
- if (WARN_RATELIMIT(tty == NULL, "tty is NULL\n"))
+ if (tty == NULL)
return;
disc = tty_ldisc_ref(tty);

View File

@ -1,2 +1,2 @@
1c738edfc54e7c65faeb90c436104e2f linux-3.8.tar.xz
ba18b5d27ed303f5e5a9cda32a451031 patch-3.8.3.xz
40ab82996ff4b49ad3f4e19cf729dcab patch-3.8.4.xz

View File

@ -1,111 +0,0 @@
Delivered-To: jwboyer@gmail.com
Received: by 10.101.212.35 with SMTP id o35csp6769anq;
Sat, 2 Mar 2013 05:50:51 -0800 (PST)
X-Received: by 10.68.137.42 with SMTP id qf10mr19122124pbb.80.1362232251119;
Sat, 02 Mar 2013 05:50:51 -0800 (PST)
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
by mx.google.com with ESMTP id pu7si8560937pbc.232.2013.03.02.05.50.50;
Sat, 02 Mar 2013 05:50:51 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mail=linux-kernel-owner@vger.kernel.org;
dkim=neutral (body hash did not verify) header.i=@gmail.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1752198Ab3CBNuU (ORCPT <rfc822;bloodsquadron@gmail.com>
+ 99 others); Sat, 2 Mar 2013 08:50:20 -0500
Received: from mail-ee0-f48.google.com ([74.125.83.48]:46431 "EHLO
mail-ee0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1752038Ab3CBNuT (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Sat, 2 Mar 2013 08:50:19 -0500
Received: by mail-ee0-f48.google.com with SMTP id t10so2921534eei.7
for <linux-kernel@vger.kernel.org>; Sat, 02 Mar 2013 05:50:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent;
bh=8ABPYEMGQsyhtGtpdGpnD1kQchBrqYm9rJ3sEUcIQOc=;
b=hx/4GjbvaME9C3c+WOrfUkkwnJ5jJXefsOhCKmPCE8kmswk3Tvm11198r4+y1jM/Bl
1wtIYby6sFgA08JUldm09fPpsKfbdeDnFAI5WmUAGJjahFXXRrQPocI6E0+s2BcM+t3H
Ii8g8ZvYJ+YMgbbSmp7mwMv98aa0+qdY6TIF4P/wNwAWrsjFh5TBgc/QyB0MzyQQ2tMp
LfA7n/2sH11vofS6FLSaWhtwGIIexPZ+oxWpvwBcCIYX+gTrSHPZqnLQkvhQ5oZDx7WF
6QlNEqlmL+usW1ApRCAwcL4jOaORDAC2MytGH4jdZNic0PqdzonfbJTRE6YmZ45FHtNG
l+6w==
X-Received: by 10.15.101.204 with SMTP id bp52mr38431150eeb.31.1362232218031;
Sat, 02 Mar 2013 05:50:18 -0800 (PST)
Received: from gmail.com (aek101.neoplus.adsl.tpnet.pl. [83.25.114.101])
by mx.google.com with ESMTPS id o3sm22363368eem.15.2013.03.02.05.50.16
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 02 Mar 2013 05:50:17 -0800 (PST)
Date: Sat, 2 Mar 2013 14:50:15 +0100
From: Marcin Jurkowski <marcin1j@gmail.com>
To: Sven Geggus <lists@fuchsschwanzdomain.de>
Cc: Evgeniy Polyakov <zbr@ioremap.net>, linux-kernel@vger.kernel.org
Subject: [PATCH 1/1] w1: fix oops when w1_search is called from netlink
connector
Message-ID: <20130302135015.GA21448@gmail.com>
References: <20130116141627.GA23638@ioremap.net>
<20130302001103.GB18026@gmail.com>
<20130302094510.GA4695@geggus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130302094510.GA4695@geggus.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
On Sat, Mar 02, 2013 at 10:45:10AM +0100, Sven Geggus wrote:
> This is the bad commit I found doing git bisect:
> 04f482faf50535229a5a5c8d629cf963899f857c is the first bad commit
> commit 04f482faf50535229a5a5c8d629cf963899f857c
> Author: Patrick McHardy <kaber@trash.net>
> Date: Mon Mar 28 08:39:36 2011 +0000
Good job. I was too lazy to bisect for bad commit;)
Reading the code I found problematic kthread_should_stop call from netlink
connector which causes the oops. After applying a patch, I've been testing
owfs+w1 setup for nearly two days and it seems to work very reliable (no
hangs, no memleaks etc).
More detailed description and possible fix is given below:
Function w1_search can be called from either kthread or netlink callback.
While the former works fine, the latter causes oops due to kthread_should_stop
invocation.
This patch adds a check if w1_search is serving netlink command, skipping
kthread_should_stop invocation if so.
Signed-off-by: Marcin Jurkowski <marcin1j@gmail.com>
---
drivers/w1/w1.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 7994d933..7e2220d 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -924,7 +924,8 @@ void w1_search(struct w1_master *dev, u8 search_type, w1_slave_found_callback cb
tmp64 = (triplet_ret >> 2);
rn |= (tmp64 << i);
- if (kthread_should_stop()) {
+ /* ensure we're called from kthread and not by netlink callback */
+ if (!dev->priv && kthread_should_stop()) {
mutex_unlock(&dev->bus_mutex);
dev_dbg(&dev->dev, "Abort w1_search\n");
return;
--
1.7.12.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/