3.8.4-201.fc18.gnu

14 files changed, 281 insertions, 853 deletions

diff --git a/freed-ora/current/f18/0001-KVM-Fix-bounds-checking-in-ioapic-indirect-register-.patch b/freed-ora/current/f18/0001-KVM-Fix-bounds-checking-in-ioapic-indirect-register-.patch
new file mode 100644
index 000000000..7583f74c2
--- /dev/null
+++ b/freed-ora/current/f18/0001-KVM-Fix-bounds-checking-in-ioapic-indirect-register-.patch
@@ -0,0 +1,44 @@
+From a2c118bfab8bc6b8bb213abfc35201e441693d55 Mon Sep 17 00:00:00 2001
+From: Andy Honig <ahonig@google.com>
+Date: Wed, 20 Feb 2013 14:49:16 -0800
+Subject: [PATCH] KVM: Fix bounds checking in ioapic indirect register reads
+ (CVE-2013-1798)
+
+If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows
+that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate
+that request.  ioapic_read_indirect contains an
+ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in
+non-debug builds.  In recent kernels this allows a guest to cause a kernel
+oops by reading invalid memory.  In older kernels (pre-3.3) this allows a
+guest to read from large ranges of host memory.
+
+Tested: tested against apic unit tests.
+
+Signed-off-by: Andrew Honig <ahonig@google.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+---
+ virt/kvm/ioapic.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
+index ce82b94..5ba005c 100644
+--- a/virt/kvm/ioapic.c
++++ b/virt/kvm/ioapic.c
+@@ -74,9 +74,12 @@ static unsigned long ioapic_read_indirect(struct kvm_ioapic *ioapic,
+ 			u32 redir_index = (ioapic->ioregsel - 0x10) >> 1;
+ 			u64 redir_content;
+ 
+-			ASSERT(redir_index < IOAPIC_NUM_PINS);
++			if (redir_index < IOAPIC_NUM_PINS)
++				redir_content =
++					ioapic->redirtbl[redir_index].bits;
++			else
++				redir_content = ~0ULL;
+ 
+-			redir_content = ioapic->redirtbl[redir_index].bits;
+ 			result = (ioapic->ioregsel & 0x1) ?
+ 			    (redir_content >> 32) & 0xffffffff :
+ 			    redir_content & 0xffffffff;
+-- 
+1.8.1.4
+
diff --git a/freed-ora/current/f18/0002-KVM-x86-fix-for-buffer-overflow-in-handling-of-MSR_K.patch b/freed-ora/current/f18/0002-KVM-x86-fix-for-buffer-overflow-in-handling-of-MSR_K.patch
new file mode 100644
index 000000000..a4516e43e
--- /dev/null
+++ b/freed-ora/current/f18/0002-KVM-x86-fix-for-buffer-overflow-in-handling-of-MSR_K.patch
@@ -0,0 +1,41 @@
+From c300aa64ddf57d9c5d9c898a64b36877345dd4a9 Mon Sep 17 00:00:00 2001
+From: Andy Honig <ahonig@google.com>
+Date: Mon, 11 Mar 2013 09:34:52 -0700
+Subject: [PATCH 2/3] KVM: x86: fix for buffer overflow in handling of
+ MSR_KVM_SYSTEM_TIME (CVE-2013-1796)
+
+If the guest sets the GPA of the time_page so that the request to update the
+time straddles a page then KVM will write onto an incorrect page.  The
+write is done byusing kmap atomic to get a pointer to the page for the time
+structure and then performing a memcpy to that page starting at an offset
+that the guest controls.  Well behaved guests always provide a 32-byte aligned
+address, however a malicious guest could use this to corrupt host kernel
+memory.
+
+Tested: Tested against kvmclock unit test.
+
+Signed-off-by: Andrew Honig <ahonig@google.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+---
+ arch/x86/kvm/x86.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
+index f7c850b..2ade60c 100644
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -1959,6 +1959,11 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ 		/* ...but clean it before doing the actual write */
+ 		vcpu->arch.time_offset = data & ~(PAGE_MASK | 1);
+ 
++		/* Check that the address is 32-byte aligned. */
++		if (vcpu->arch.time_offset &
++				(sizeof(struct pvclock_vcpu_time_info) - 1))
++			break;
++
+ 		vcpu->arch.time_page =
+ 				gfn_to_page(vcpu->kvm, data >> PAGE_SHIFT);
+ 
+-- 
+1.8.1.4
+
diff --git a/freed-ora/current/f18/0003-KVM-x86-Convert-MSR_KVM_SYSTEM_TIME-to-use-gfn_to_hv.patch b/freed-ora/current/f18/0003-KVM-x86-Convert-MSR_KVM_SYSTEM_TIME-to-use-gfn_to_hv.patch
new file mode 100644
index 000000000..7a2fe6547
--- /dev/null
+++ b/freed-ora/current/f18/0003-KVM-x86-Convert-MSR_KVM_SYSTEM_TIME-to-use-gfn_to_hv.patch
@@ -0,0 +1,163 @@
+From 0b79459b482e85cb7426aa7da683a9f2c97aeae1 Mon Sep 17 00:00:00 2001
+From: Andy Honig <ahonig@google.com>
+Date: Wed, 20 Feb 2013 14:48:10 -0800
+Subject: [PATCH 3/3] KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use
+ gfn_to_hva_cache functions (CVE-2013-1797)
+
+There is a potential use after free issue with the handling of
+MSR_KVM_SYSTEM_TIME.  If the guest specifies a GPA in a movable or removable
+memory such as frame buffers then KVM might continue to write to that
+address even after it's removed via KVM_SET_USER_MEMORY_REGION.  KVM pins
+the page in memory so it's unlikely to cause an issue, but if the user
+space component re-purposes the memory previously used for the guest, then
+the guest will be able to corrupt that memory.
+
+Tested: Tested against kvmclock unit test
+
+Signed-off-by: Andrew Honig <ahonig@google.com>
+Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
+---
+ arch/x86/include/asm/kvm_host.h |  4 ++--
+ arch/x86/kvm/x86.c              | 47 ++++++++++++++++++-----------------------
+ 2 files changed, 22 insertions(+), 29 deletions(-)
+
+diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
+index 635a74d..4979778 100644
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -414,8 +414,8 @@ struct kvm_vcpu_arch {
+ 	gpa_t time;
+ 	struct pvclock_vcpu_time_info hv_clock;
+ 	unsigned int hw_tsc_khz;
+-	unsigned int time_offset;
+-	struct page *time_page;
++	struct gfn_to_hva_cache pv_time;
++	bool pv_time_enabled;
+ 	/* set guest stopped flag in pvclock flags field */
+ 	bool pvclock_set_guest_stopped_request;
+ 
+diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
+index 2ade60c..f19ac0a 100644
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -1406,10 +1406,9 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
+ 	unsigned long flags, this_tsc_khz;
+ 	struct kvm_vcpu_arch *vcpu = &v->arch;
+ 	struct kvm_arch *ka = &v->kvm->arch;
+-	void *shared_kaddr;
+ 	s64 kernel_ns, max_kernel_ns;
+ 	u64 tsc_timestamp, host_tsc;
+-	struct pvclock_vcpu_time_info *guest_hv_clock;
++	struct pvclock_vcpu_time_info guest_hv_clock;
+ 	u8 pvclock_flags;
+ 	bool use_master_clock;
+ 
+@@ -1463,7 +1462,7 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
+ 
+ 	local_irq_restore(flags);
+ 
+-	if (!vcpu->time_page)
++	if (!vcpu->pv_time_enabled)
+ 		return 0;
+ 
+ 	/*
+@@ -1525,12 +1524,12 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
+ 	 */
+ 	vcpu->hv_clock.version += 2;
+ 
+-	shared_kaddr = kmap_atomic(vcpu->time_page);
+-
+-	guest_hv_clock = shared_kaddr + vcpu->time_offset;
++	if (unlikely(kvm_read_guest_cached(v->kvm, &vcpu->pv_time,
++		&guest_hv_clock, sizeof(guest_hv_clock))))
++		return 0;
+ 
+ 	/* retain PVCLOCK_GUEST_STOPPED if set in guest copy */
+-	pvclock_flags = (guest_hv_clock->flags & PVCLOCK_GUEST_STOPPED);
++	pvclock_flags = (guest_hv_clock.flags & PVCLOCK_GUEST_STOPPED);
+ 
+ 	if (vcpu->pvclock_set_guest_stopped_request) {
+ 		pvclock_flags |= PVCLOCK_GUEST_STOPPED;
+@@ -1543,12 +1542,9 @@ static int kvm_guest_time_update(struct kvm_vcpu *v)
+ 
+ 	vcpu->hv_clock.flags = pvclock_flags;
+ 
+-	memcpy(shared_kaddr + vcpu->time_offset, &vcpu->hv_clock,
+-	       sizeof(vcpu->hv_clock));
+-
+-	kunmap_atomic(shared_kaddr);
+-
+-	mark_page_dirty(v->kvm, vcpu->time >> PAGE_SHIFT);
++	kvm_write_guest_cached(v->kvm, &vcpu->pv_time,
++				&vcpu->hv_clock,
++				sizeof(vcpu->hv_clock));
+ 	return 0;
+ }
+ 
+@@ -1837,10 +1833,7 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
+ 
+ static void kvmclock_reset(struct kvm_vcpu *vcpu)
+ {
+-	if (vcpu->arch.time_page) {
+-		kvm_release_page_dirty(vcpu->arch.time_page);
+-		vcpu->arch.time_page = NULL;
+-	}
++	vcpu->arch.pv_time_enabled = false;
+ }
+ 
+ static void accumulate_steal_time(struct kvm_vcpu *vcpu)
+@@ -1947,6 +1940,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ 		break;
+ 	case MSR_KVM_SYSTEM_TIME_NEW:
+ 	case MSR_KVM_SYSTEM_TIME: {
++		u64 gpa_offset;
+ 		kvmclock_reset(vcpu);
+ 
+ 		vcpu->arch.time = data;
+@@ -1956,19 +1950,17 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
+ 		if (!(data & 1))
+ 			break;
+ 
+-		/* ...but clean it before doing the actual write */
+-		vcpu->arch.time_offset = data & ~(PAGE_MASK | 1);
++		gpa_offset = data & ~(PAGE_MASK | 1);
+ 
+ 		/* Check that the address is 32-byte aligned. */
+-		if (vcpu->arch.time_offset &
+-				(sizeof(struct pvclock_vcpu_time_info) - 1))
++		if (gpa_offset & (sizeof(struct pvclock_vcpu_time_info) - 1))
+ 			break;
+ 
+-		vcpu->arch.time_page =
+-				gfn_to_page(vcpu->kvm, data >> PAGE_SHIFT);
+-
+-		if (is_error_page(vcpu->arch.time_page))
+-			vcpu->arch.time_page = NULL;
++		if (kvm_gfn_to_hva_cache_init(vcpu->kvm,
++		     &vcpu->arch.pv_time, data & ~1ULL))
++			vcpu->arch.pv_time_enabled = false;
++		else
++			vcpu->arch.pv_time_enabled = true;
+ 
+ 		break;
+ 	}
+@@ -2972,7 +2964,7 @@ static int kvm_vcpu_ioctl_x86_set_xcrs(struct kvm_vcpu *vcpu,
+  */
+ static int kvm_set_guest_paused(struct kvm_vcpu *vcpu)
+ {
+-	if (!vcpu->arch.time_page)
++	if (!vcpu->arch.pv_time_enabled)
+ 		return -EINVAL;
+ 	vcpu->arch.pvclock_set_guest_stopped_request = true;
+ 	kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
+@@ -6723,6 +6715,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
+ 		goto fail_free_wbinvd_dirty_mask;
+ 
+ 	vcpu->arch.ia32_tsc_adjust_msr = 0x0;
++	vcpu->arch.pv_time_enabled = false;
+ 	kvm_async_pf_hash_reset(vcpu);
+ 	kvm_pmu_init(vcpu);
+ 
+-- 
+1.8.1.4
+
diff --git a/freed-ora/current/f18/TTY-do-not-reset-master-s-packet-mode.patch b/freed-ora/current/f18/TTY-do-not-reset-master-s-packet-mode.patch
deleted file mode 100644
index 633bfcf46..000000000
--- a/freed-ora/current/f18/TTY-do-not-reset-master-s-packet-mode.patch
+++ /dev/null
@@ -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
-
diff --git a/freed-ora/current/f18/USB-cdc-wdm-fix-buffer-overflow.patch b/freed-ora/current/f18/USB-cdc-wdm-fix-buffer-overflow.patch
deleted file mode 100644
index 2b1ed4254..000000000
--- a/freed-ora/current/f18/USB-cdc-wdm-fix-buffer-overflow.patch
+++ /dev/null
@@ -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
-
diff --git a/freed-ora/current/f18/drm-ilk-rc6-reverts.patch b/freed-ora/current/f18/drm-ilk-rc6-reverts.patch
deleted file mode 100644
index 211ffa81a..000000000
--- a/freed-ora/current/f18/drm-ilk-rc6-reverts.patch
+++ /dev/null
@@ -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);
diff --git a/freed-ora/current/f18/fix-destroy_conntrack-GPF.patch b/freed-ora/current/f18/fix-destroy_conntrack-GPF.patch
deleted file mode 100644
index 35ffa581d..000000000
--- a/freed-ora/current/f18/fix-destroy_conntrack-GPF.patch
+++ /dev/null
@@ -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);
- 
-
diff --git a/freed-ora/current/f18/kernel.spec b/freed-ora/current/f18/kernel.spec
index f585a43c0..8f1d4f02e 100644
--- a/freed-ora/current/f18/kernel.spec
+++ b/freed-ora/current/f18/kernel.spec
@@ -62,7 +62,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 203
+%global baserelease 201
 %global fedora_build %{baserelease}
 
 # base_sublevel is the kernel version we're starting with and patching
@@ -112,7 +112,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
@@ -726,7 +726,6 @@ Patch510: silence-noise.patch
 Patch520: quiet-apm.patch
 Patch530: silence-fbcon-logo.patch
 Patch540: silence-empty-ipi-mask-warning.patch
-Patch541: silence-tty-null.patch
 
 Patch800: crash-driver.patch
 
@@ -814,35 +813,17 @@ 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
 
-#rhbz 904182
-Patch24103: 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
 
@@ -853,17 +834,20 @@ 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
+
+#CVE-2013-1796 rhbz 917012 923966
+Patch25004: 0002-KVM-x86-fix-for-buffer-overflow-in-handling-of-MSR_K.patch
+
+#CVE-2013-1797 rhbz 917013 923967
+Patch25005: 0003-KVM-x86-Convert-MSR_KVM_SYSTEM_TIME-to-use-gfn_to_hv.patch
 
 # END OF PATCH DEFINITIONS
 
@@ -1551,7 +1535,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.
 
@@ -1635,12 +1618,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
 
@@ -1653,21 +1630,9 @@ ApplyPatch i7300_edac_single_mode_fixup.patch
 #Team Driver update
 ApplyPatch team-net-next-update-20130307.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
 
@@ -1678,11 +1643,14 @@ 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
+#CVE-2013-1798 rhbz 917017 923968
+ApplyPatch 0001-KVM-Fix-bounds-checking-in-ioapic-indirect-register-.patch
 
-#rhbz 922304
-ApplyPatch drm-ilk-rc6-reverts.patch -R
+#CVE-2013-1796 rhbz 917012 923966
+ApplyPatch 0002-KVM-x86-fix-for-buffer-overflow-in-handling-of-MSR_K.patch
+
+#CVE-2013-1797 rhbz 917013 923967
+ApplyPatch 0003-KVM-x86-Convert-MSR_KVM_SYSTEM_TIME-to-use-gfn_to_hv.patch
 
 # END OF PATCH APPLICATIONS
 
@@ -2552,6 +2520,21 @@ fi
 #                 ||----w |
 #                 ||     ||
 %changelog
+* Thu Mar 21 2013 Alexandre Oliva <lxoliva@fsfla.org> -libre
+- GNU Linux-libre 3.8.4-gnu.
+
+* Wed Mar 20 2013 Justin M. Forbes <jforbes@redhat.com> 3.8.4-201
+- 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)
+- CVE-2013-1797 kvm: after free issue with the handling of MSR_KVM_SYSTEM_TIME
+  (rhbz 917013 923967)
+- CVE-2013-1798 kvm: out-of-bounds access in ioapic indirect register reads
+  (rhbz 917017 923968)
+
 * Mon Mar 18 2013 Justin M. Forbes
 - Revert rc6 ilk changes from 3.8.3 stable (rhbz 922304)
 
diff --git a/freed-ora/current/f18/net-sctp-Validate-parameter-size-for-SCTP_GET_ASSOC_.patch b/freed-ora/current/f18/net-sctp-Validate-parameter-size-for-SCTP_GET_ASSOC_.patch
deleted file mode 100644
index bb976c593..000000000
--- a/freed-ora/current/f18/net-sctp-Validate-parameter-size-for-SCTP_GET_ASSOC_.patch
+++ /dev/null
@@ -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
-
diff --git a/freed-ora/current/f18/serial-8250-Keep-8250.-xxxx-module-options-functiona.patch b/freed-ora/current/f18/serial-8250-Keep-8250.-xxxx-module-options-functiona.patch
deleted file mode 100644
index b16be4417..000000000
--- a/freed-ora/current/f18/serial-8250-Keep-8250.-xxxx-module-options-functiona.patch
+++ /dev/null
@@ -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
-
diff --git a/freed-ora/current/f18/signal-always-clear-sa_restorer-on-execve.patch b/freed-ora/current/f18/signal-always-clear-sa_restorer-on-execve.patch
deleted file mode 100644
index 658f97a96..000000000
--- a/freed-ora/current/f18/signal-always-clear-sa_restorer-on-execve.patch
+++ /dev/null
@@ -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/
diff --git a/freed-ora/current/f18/silence-tty-null.patch b/freed-ora/current/f18/silence-tty-null.patch
deleted file mode 100644
index 00f64239b..000000000
--- a/freed-ora/current/f18/silence-tty-null.patch
+++ /dev/null
@@ -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);
diff --git a/freed-ora/current/f18/sources b/freed-ora/current/f18/sources
index ac9d5dd82..dbf2b5a21 100644
--- a/freed-ora/current/f18/sources
+++ b/freed-ora/current/f18/sources
@@ -1,2 +1,2 @@
 84c2a77910932ffc7d958744ac9cf2f5  linux-libre-3.8-gnu.tar.xz
-ba18b5d27ed303f5e5a9cda32a451031  patch-3.8.3.xz
+40ab82996ff4b49ad3f4e19cf729dcab  patch-3.8.4.xz
diff --git a/freed-ora/current/f18/w1-fix-oops-when-w1_search-is-called-from.patch b/freed-ora/current/f18/w1-fix-oops-when-w1_search-is-called-from.patch
deleted file mode 100644
index 0a54eff17..000000000
--- a/freed-ora/current/f18/w1-fix-oops-when-w1_search-is-called-from.patch
+++ /dev/null
@@ -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/