This is a note to let you know that I've just added the patch titled
KVM: x86: fix singlestepping over syscall
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-x86-fix-singlestepping-over-syscall.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Wed, 7 Jun 2017 15:13:14 +0200
Subject: KVM: x86: fix singlestepping over syscall
From: Paolo Bonzini <pbonzini(a)redhat.com>
commit c8401dda2f0a00cd25c0af6a95ed50e478d25de4 upstream.
TF is handled a bit differently for syscall and sysret, compared
to the other instructions: TF is checked after the instruction completes,
so that the OS can disable #DB at a syscall by adding TF to FMASK.
When the sysret is executed the #DB is taken "as if" the syscall insn
just completed.
KVM emulates syscall so that it can trap 32-bit syscall on Intel processors.
Fix the behavior, otherwise you could get #DB on a user stack which is not
nice. This does not affect Linux guests, as they use an IST or task gate
for #DB.
This fixes CVE-2017-7518.
Reported-by: Andy Lutomirski <luto(a)kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
[bwh: Backported to 4.4:
- kvm_vcpu_check_singlestep() sets some flags differently
- Drop changes to kvm_skip_emulated_instruction()]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/kvm_emulate.h | 1
arch/x86/kvm/emulate.c | 1
arch/x86/kvm/x86.c | 52 +++++++++++++++----------------------
3 files changed, 24 insertions(+), 30 deletions(-)
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -296,6 +296,7 @@ struct x86_emulate_ctxt {
bool perm_ok; /* do not check permissions if true */
bool ud; /* inject an #UD if host doesn't support insn */
+ bool tf; /* TF value before instruction (after for syscall/sysret) */
bool have_exception;
struct x86_exception exception;
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2726,6 +2726,7 @@ static int em_syscall(struct x86_emulate
ctxt->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF);
}
+ ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0;
return X86EMUL_CONTINUE;
}
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5095,6 +5095,8 @@ static void init_emulate_ctxt(struct kvm
kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
ctxt->eflags = kvm_get_rflags(vcpu);
+ ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0;
+
ctxt->eip = kvm_rip_read(vcpu);
ctxt->mode = (!is_protmode(vcpu)) ? X86EMUL_MODE_REAL :
(ctxt->eflags & X86_EFLAGS_VM) ? X86EMUL_MODE_VM86 :
@@ -5315,37 +5317,26 @@ static int kvm_vcpu_check_hw_bp(unsigned
return dr6;
}
-static void kvm_vcpu_check_singlestep(struct kvm_vcpu *vcpu, unsigned long rflags, int *r)
+static void kvm_vcpu_do_singlestep(struct kvm_vcpu *vcpu, int *r)
{
struct kvm_run *kvm_run = vcpu->run;
- /*
- * rflags is the old, "raw" value of the flags. The new value has
- * not been saved yet.
- *
- * This is correct even for TF set by the guest, because "the
- * processor will not generate this exception after the instruction
- * that sets the TF flag".
- */
- if (unlikely(rflags & X86_EFLAGS_TF)) {
- if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
- kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 |
- DR6_RTM;
- kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
- kvm_run->debug.arch.exception = DB_VECTOR;
- kvm_run->exit_reason = KVM_EXIT_DEBUG;
- *r = EMULATE_USER_EXIT;
- } else {
- vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF;
- /*
- * "Certain debug exceptions may clear bit 0-3. The
- * remaining contents of the DR6 register are never
- * cleared by the processor".
- */
- vcpu->arch.dr6 &= ~15;
- vcpu->arch.dr6 |= DR6_BS | DR6_RTM;
- kvm_queue_exception(vcpu, DB_VECTOR);
- }
+ if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
+ kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 | DR6_RTM;
+ kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip;
+ kvm_run->debug.arch.exception = DB_VECTOR;
+ kvm_run->exit_reason = KVM_EXIT_DEBUG;
+ *r = EMULATE_USER_EXIT;
+ } else {
+ vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF;
+ /*
+ * "Certain debug exceptions may clear bit 0-3. The
+ * remaining contents of the DR6 register are never
+ * cleared by the processor".
+ */
+ vcpu->arch.dr6 &= ~15;
+ vcpu->arch.dr6 |= DR6_BS | DR6_RTM;
+ kvm_queue_exception(vcpu, DB_VECTOR);
}
}
@@ -5500,8 +5491,9 @@ restart:
toggle_interruptibility(vcpu, ctxt->interruptibility);
vcpu->arch.emulate_regs_need_sync_to_vcpu = false;
kvm_rip_write(vcpu, ctxt->eip);
- if (r == EMULATE_DONE)
- kvm_vcpu_check_singlestep(vcpu, rflags, &r);
+ if (r == EMULATE_DONE &&
+ (ctxt->tf || (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)))
+ kvm_vcpu_do_singlestep(vcpu, &r);
if (!ctxt->have_exception ||
exception_type(ctxt->exception.vector) == EXCPT_TRAP)
__kvm_set_rflags(vcpu, ctxt->eflags);
Patches currently in stable-queue which might be from pbonzini(a)redhat.com are
queue-4.4/kvm-x86-fix-singlestepping-over-syscall.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2419,6 +2419,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.4/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
ext4: fix data exposure after a crash
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-data-exposure-after-a-crash.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Sun, 24 Apr 2016 00:56:03 -0400
Subject: ext4: fix data exposure after a crash
From: Jan Kara <jack(a)suse.cz>
commit 06bd3c36a733ac27962fea7d6f47168841376824 upstream.
Huang has reported that in his powerfail testing he is seeing stale
block contents in some of recently allocated blocks although he mounts
ext4 in data=ordered mode. After some investigation I have found out
that indeed when delayed allocation is used, we don't add inode to
transaction's list of inodes needing flushing before commit. Originally
we were doing that but commit f3b59291a69d removed the logic with a
flawed argument that it is not needed.
The problem is that although for delayed allocated blocks we write their
contents immediately after allocating them, there is no guarantee that
the IO scheduler or device doesn't reorder things and thus transaction
allocating blocks and attaching them to inode can reach stable storage
before actual block contents. Actually whenever we attach freshly
allocated blocks to inode using a written extent, we should add inode to
transaction's ordered inode list to make sure we properly wait for block
contents to be written before committing the transaction. So that is
what we do in this patch. This also handles other cases where stale data
exposure was possible - like filling hole via mmap in
data=ordered,nodelalloc mode.
The only exception to the above rule are extending direct IO writes where
blkdev_direct_IO() waits for IO to complete before increasing i_size and
thus stale data exposure is not possible. For now we don't complicate
the code with optimizing this special case since the overhead is pretty
low. In case this is observed to be a performance problem we can always
handle it using a special flag to ext4_map_blocks().
Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d
Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang(a)cn.bosch.com>
Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang(a)cn.bosch.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
[bwh: Backported to 4.4:
- Drop check for EXT4_GET_BLOCKS_ZERO flag
- Adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/inode.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -658,6 +658,20 @@ has_zeroout:
ret = check_block_validity(inode, map);
if (ret != 0)
return ret;
+
+ /*
+ * Inodes with freshly allocated blocks where contents will be
+ * visible after transaction commit must be on transaction's
+ * ordered data list.
+ */
+ if (map->m_flags & EXT4_MAP_NEW &&
+ !(map->m_flags & EXT4_MAP_UNWRITTEN) &&
+ !IS_NOQUOTA(inode) &&
+ ext4_should_order_data(inode)) {
+ ret = ext4_jbd2_file_inode(handle, inode);
+ if (ret)
+ return ret;
+ }
}
return retval;
}
@@ -1152,15 +1166,6 @@ static int ext4_write_end(struct file *f
int i_size_changed = 0;
trace_ext4_write_end(inode, pos, len, copied);
- if (ext4_test_inode_state(inode, EXT4_STATE_ORDERED_MODE)) {
- ret = ext4_jbd2_file_inode(handle, inode);
- if (ret) {
- unlock_page(page);
- page_cache_release(page);
- goto errout;
- }
- }
-
if (ext4_has_inline_data(inode)) {
ret = ext4_write_inline_data_end(inode, pos, len,
copied, page);
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.4/ext4-fix-data-exposure-after-a-crash.patch
This is a note to let you know that I've just added the patch titled
bpf: don't let ldimm64 leak map addresses on unprivileged
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bpf-don-t-let-ldimm64-leak-map-addresses-on-unprivileged.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 11:12:05 CET 2017
From: Daniel Borkmann <daniel(a)iogearbox.net>
Date: Mon, 8 May 2017 00:04:09 +0200
Subject: bpf: don't let ldimm64 leak map addresses on unprivileged
From: Daniel Borkmann <daniel(a)iogearbox.net>
commit 0d0e57697f162da4aa218b5feafe614fb666db07 upstream.
The patch fixes two things at once:
1) It checks the env->allow_ptr_leaks and only prints the map address to
the log if we have the privileges to do so, otherwise it just dumps 0
as we would when kptr_restrict is enabled on %pK. Given the latter is
off by default and not every distro sets it, I don't want to rely on
this, hence the 0 by default for unprivileged.
2) Printing of ldimm64 in the verifier log is currently broken in that
we don't print the full immediate, but only the 32 bit part of the
first insn part for ldimm64. Thus, fix this up as well; it's okay to
access, since we verified all ldimm64 earlier already (including just
constants) through replace_map_fd_with_map_ptr().
Fixes: 1be7f75d1668 ("bpf: enable non-root eBPF programs")
Fixes: cbd357008604 ("bpf: verifier (add ability to receive verification log)")
Reported-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Acked-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
[bwh: Backported to 4.4: s/bpf_verifier_env/verifier_env/]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/bpf/verifier.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -313,7 +313,8 @@ static const char *const bpf_jmp_string[
[BPF_EXIT >> 4] = "exit",
};
-static void print_bpf_insn(struct bpf_insn *insn)
+static void print_bpf_insn(const struct verifier_env *env,
+ const struct bpf_insn *insn)
{
u8 class = BPF_CLASS(insn->code);
@@ -377,9 +378,19 @@ static void print_bpf_insn(struct bpf_in
insn->code,
bpf_ldst_string[BPF_SIZE(insn->code) >> 3],
insn->src_reg, insn->imm);
- } else if (BPF_MODE(insn->code) == BPF_IMM) {
- verbose("(%02x) r%d = 0x%x\n",
- insn->code, insn->dst_reg, insn->imm);
+ } else if (BPF_MODE(insn->code) == BPF_IMM &&
+ BPF_SIZE(insn->code) == BPF_DW) {
+ /* At this point, we already made sure that the second
+ * part of the ldimm64 insn is accessible.
+ */
+ u64 imm = ((u64)(insn + 1)->imm << 32) | (u32)insn->imm;
+ bool map_ptr = insn->src_reg == BPF_PSEUDO_MAP_FD;
+
+ if (map_ptr && !env->allow_ptr_leaks)
+ imm = 0;
+
+ verbose("(%02x) r%d = 0x%llx\n", insn->code,
+ insn->dst_reg, (unsigned long long)imm);
} else {
verbose("BUG_ld_%02x\n", insn->code);
return;
@@ -1764,7 +1775,7 @@ static int do_check(struct verifier_env
if (log_level) {
verbose("%d: ", insn_idx);
- print_bpf_insn(insn);
+ print_bpf_insn(env, insn);
}
if (class == BPF_ALU || class == BPF_ALU64) {
Patches currently in stable-queue which might be from daniel(a)iogearbox.net are
queue-4.4/bpf-don-t-let-ldimm64-leak-map-addresses-on-unprivileged.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2516,6 +2516,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.13/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2412,6 +2412,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/media-imon-fix-null-ptr-deref-in-imon_probe.patch
This is a note to let you know that I've just added the patch titled
media: imon: Fix null-ptr-deref in imon_probe
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-imon-fix-null-ptr-deref-in-imon_probe.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 58fd55e838276a0c13d1dc7c387f90f25063cbf3 Mon Sep 17 00:00:00 2001
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 9 Oct 2017 20:14:48 +0200
Subject: media: imon: Fix null-ptr-deref in imon_probe
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2419,6 +2419,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-3.18/media-imon-fix-null-ptr-deref-in-imon_probe.patch