Bugzilla – Bug 938706
VUL-0: CVE-2015-5157: kernel: NMI nesting run into IRET faults
Last modified: 2024-04-23 13:17:45 UTC
bugbot adjusting priority
Lemme take it to check the other kernel flavors.
Issue is public From: Andy Lutomirski x86 has a woefully poorly designed NMI mechanism. Linux uses it for profiling. The tricks that keep NMIs from nesting improperly are complicated, as are the tricks that try to handle things like NMI watchdogs and physical buttons without proper status registers. On x86_64 it's particularly bad due to a nasty interaction with SYSCALL. Perhaps unsurprisingly, the implementation was incorrect in a few corner cases. +++++ CVE-2015-5157 +++++ Petr Matousek and I discovered that an NMI that interrupts userspace and encounters an IRET fault is incorrectly handled. Symptoms range from an OOPS to possible corruption or privilege escalation. I haven't verified how much corruption is possible or on what kernel versions it occurs. Some form of crash is likely in principle since 3.3, and it can be triggered by the attached exploit on 3.13 or newer, I believe. On kernels that are patched for BadIRET and have a fixup_bad_iret function (which should be most kernels that are keeping up with low-level security issues), there are two cases. Case 1a (more up-to-date kernels where INTERRUPT_RETURN is "jmp irq_return"): fixup_bad_iret will be invoked and will attempt to recover. There's a narrow window in which a new NMI will cause corruption, in which case all bets are off. That could hang, crash, or possibly be exploited for privilege escalation. Case 1b (less up-to-date kernels where INTERRUPT_RETURN is "iretq"): The kernel will try to OOPS due to a bad kernel fault, except that the OOPS will be processed with the wrong gsbase. This is basically the BadIRET condition, and is probably exploitable using similar techniques to BadIRET. Case 2 (kernels that are not patched for BadIRET): I didn't analyze it. BadIRET is a much worse vulnerability and you should fix it. If you have just the minimal BadIRET fix but not fixup_bad_iret, the impact is probably similar to Case 1a except that the window for corruption is much larger. On some of these kernels, it can take quite a while for the exploit to do anything. Mitigations: Use seccomp to disable perf_event_open or modify_ldt or run with only a single CPU. To my knowledge, this cannot be exploited on single-processor systems or in single-threaded applications. Fixed by: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b6e6a8334d56354853f9c255d1395c2ba570e0a Alternatively worked around by: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/nmi&id=59ab8e572e5f65289822f3cedfcdf857f43f7c74 although the latter patch is incompatible with Xen.
37868fe113ff2ba814b3b4eb12df214df555f8dc (x86/ldt: Make modify_ldt synchronous) needs also: 136d9d83c07c5e30ac49fc83b27e8c4842f108fc 4809146b86c3d41ce588fdb767d021e2a80600dd
Oh, 37868fe113ff2ba814b3b4eb12df214df555f8dc contains: > Boris: > > Revert the part from the upstream change: > > typedef struct { > void *ldt; > int size; > ... > } mm_context_t; > > in order to keep the kABI checker quiet. This requires to do a compiler > barrier when fetching ->ldt and ->size to avoid inconsistent LDTs when > calling LLDT. Boris, never do modifications like this: 1) differences from upstream are bad and make our life harder. 2) when this patch gets into stable, this modification will be silently dropped. 3) kabi changes belong to patches.kabi. 4) kabi changes are dropped on the next SP release (mostly). This inline modification can not be dropped.
Furthermore, patches.arch/04-x86-nmi-enable-nested-do_nmi-handling-for-64-bit-kernels.patch seems to be broken (and again, different from upstream). update_debug_stack is now unused/unhandled. And also, I am not sure, what are patches.arch/01-x86-asm-entry-64-fold-the-test_in_nmi-macro-into-its-only-user.patch patches.arch/02-x86-asm-entry-64-remove-a-redundant-jump.patch patches.arch/03-x86-asm-entry-64-remove-pointless-jump-to-irq_return.patch good for in this series? I don't think they are needed, as no of the patches depend on them. Neither functionally, nor contextually. So?
(In reply to Jiri Slaby from comment #36) > Furthermore, > patches.arch/04-x86-nmi-enable-nested-do_nmi-handling-for-64-bit-kernels. > patch > seems to be broken (and again, different from upstream). update_debug_stack > is now unused/unhandled. ... and do_nmi lost its "no kprobes please" aka __kprobes annotation.
(In reply to Borislav Petkov from comment #39) > In this and in the previous comment, are you talking about what went into > SLE12? Yes.
(In reply to Borislav Petkov from comment #38) > (In reply to Jiri Slaby from comment #35) > > Boris, never do modifications like this: > > 1) differences from upstream are bad and make our life harder. > > Oh really?! Don't you think I know that by now?! Staring at the patches for a couple hours, I must admit, the answer is no. > > 2) when this patch gets into stable, this modification will be silently > > dropped. > > And the kABI checker will fire. And I will have to go and fix the kabi second time. I.e. extract the changes from the patch by precise surgery. Oh, please, no. > > 3) kabi changes belong to patches.kabi. > > 4) kabi changes are dropped on the next SP release (mostly). This inline > > modification can not be dropped. > > So jikos did help with the backport and he was fine with it. I suggest > you guys sit down and decide what is the right way to backport a patch > like that *and* make the kabi checker happy, at the same time. Upstream patch + kabi patch. The rule was always the same. Kabi breakage may break bisection. But it won't, since when bisecting, kabi checker will be off anyway. > But regardless, this patch is not going to be in the final release - > jikos has the correct version from Jürgen which takes care of all that. Ok, I see.
(In reply to Jiri Slaby from comment #41) > Staring at the patches for a couple hours, I must admit, the answer is no. Ok, next time I'll make sure to ask you when I get a kabi breakage what the right fix is. > And I will have to go and fix the kabi second time. I.e. extract the > changes from the patch by precise surgery. Oh, please, no. Don't do anything - jikos knows how to fix it properly.
(In reply to Borislav Petkov from comment #42) > (In reply to Jiri Slaby from comment #41) > > Staring at the patches for a couple hours, I must admit, the answer is no. > > Ok, next time I'll make sure to ask you when I get a kabi breakage what > the right fix is. s/you/kernel@suse/ like others.
Created attachment 644274 [details] diff of backport vs upstream I am afraid, I don't follow. The stable backports are 98% the same as upstream. For reference, I am attaching a diff of "stable 3.12 backport" and 37868fe113ff2ba. 9d05041679904b differs in three context lines. What am I missing?
(In reply to Jiri Slaby from comment #36) > patches.arch/03-x86-asm-entry-64-remove-pointless-jump-to-irq_return.patch > good for in this series? I don't think they are needed, as no of the patches > depend on them. Neither functionally, nor contextually. So? So they're needed as preparatory for patches.arch/06-x86-nmi-64-switch-stacks-on-userspace-nmi-entry.patch which fixes CVE-2015-3290, in addition. I know, References: should say that, it will be fixed.
(In reply to Borislav Petkov from comment #47) > (In reply to Jiri Slaby from comment #36) > > patches.arch/03-x86-asm-entry-64-remove-pointless-jump-to-irq_return.patch > > good for in this series? I don't think they are needed, as no of the patches > > depend on them. Neither functionally, nor contextually. So? > > So they're needed as preparatory for > > patches.arch/06-x86-nmi-64-switch-stacks-on-userspace-nmi-entry.patch > > which fixes CVE-2015-3290, in addition. I know, References: should say > that, it will be fixed. No, it's not about References. I fail to see, why they are needed as preparation -- what do they prepare for 06? 06 applies and works even without them IMO. That's why I wrote: "as no of the patches depend on them. Neither functionally, nor contextually." Hence, could you elaborate more on that, please? BTW, what about the dwarf unwinder and the added push/pop's -- is it OK (ENOTENOUGHKNOWLEDGE here) or don't we care at all?
(In reply to Jiri Slaby from comment #48) > No, it's not about References. I fail to see, why they are needed as > preparation -- what do they prepare for 06? They prepare the asm in entry_64.S to be as close to the upstream version as possible. So no, it is not a direct code dependency but it is more a "get-asm-close-to-upstream" because backporting changes in the asm bits are especially painful. Even more so if our code base diverges even more from upstream. And so next time we have to touch it, we won't have to backport the world and more. So this is the backport that went into Debian and that Andy et al doublechecked so I decided to use it instead of doing my own mistakes. > BTW, what about the dwarf unwinder and the added push/pop's -- is it OK > (ENOTENOUGHKNOWLEDGE here) or don't we care at all? Same here.
(In reply to Borislav Petkov from comment #49) > So this is the backport that went into Debian and that Andy et al > doublechecked so I decided to use it instead of doing my own mistakes. Ok, I still think it is useless and unneeded, but whatever. > > BTW, what about the dwarf unwinder and the added push/pop's -- is it OK > > (ENOTENOUGHKNOWLEDGE here) or don't we care at all? > > Same here. We (suse) are different here, as we drag and use unwinder heavily :(.
(In reply to Jiri Slaby from comment #50) > Ok, I still think it is useless and unneeded, but whatever. Why do you even care? They're trivial but help a great deal with later backports, as I've come to realize recently when backporting an asm fix for SLE10-something. >> Same here. > > We (suse) are different here, as we drag and use unwinder heavily :(. With "Same here." I meant I also ENOTENOUGHKNOWLEDGE here.
(In reply to Borislav Petkov from comment #51) > (In reply to Jiri Slaby from comment #50) > > Ok, I still think it is useless and unneeded, but whatever. > > Why do you even care? stable-3.12 -- they don't fit the stable rules. > They're trivial but help a great deal with later backports, as I've come > to realize recently when backporting an asm fix for SLE10-something. When they are needed, sure. But they aren't, so I cannot take them to stable-3.12.
(In reply to Jiri Slaby from comment #52) > When they are needed, sure. But they aren't, so I cannot take them to > stable-3.12. So? SLE12 and stable-3.12 kernels differ in other places already, no? I don't see why those 3 trivial patches are a problem. But if they bother you so much, feel free to zap them and retest with the reproducer.
(In reply to Borislav Petkov from comment #53) > (In reply to Jiri Slaby from comment #52) > > When they are needed, sure. But they aren't, so I cannot take them to > > stable-3.12. > > So? SLE12 and stable-3.12 kernels differ in other places already, no? I > don't see why those 3 trivial patches are a problem. Ok, so I finally understand how and why you managed to add them. The patches are a prerequisite for 810bc075f78ff2c221536eb3008eac6a492dba2d (x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection), a fix for CVE-2015-3291, which we decided *not* to apply -- see bug 937970. So only now I have full understanding of what is going on here. My point is we don't take random patches just because. > So this is the backport that went into Debian and that Andy et al > doublechecked so I decided to use it instead of doing my own mistakes. Actually, no, they never tested what we have in SLE12. In particular, they have fixes for both CVE-2015-5157 and CVE-2015-3291. We chose to fix only CVE-2015-5157 and applied three cleanup patches for CVE-2015-3291. Not the rest, which they tested, apparently. > But if they bother you so much, feel free to zap them and retest with > the reproducer. Once this all settles down and the patches get into stable as a transitive closure. Namely, I am waiting for the Juergen xen fixes which are not upstream yet. This CVE-2015-3291 and its fix is a mess. Then I will remove them as those 3 would be left in series.conf alone.
(In reply to Jiri Slaby from comment #54) > My point is we don't take random patches just because. I explained to you already why they're not random.
(In reply to Jiri Slaby from comment #46) > Created attachment 644274 [details] > diff of backport vs upstream > > I am afraid, I don't follow. The stable backports are 98% the same as > upstream. For reference, I am attaching a diff of "stable 3.12 backport" and > 37868fe113ff2ba. 9d05041679904b differs in three context lines. 9d05041679904b is the wrong commit id. > What am I missing? If the backport has this - which it must be, judging by your attached interdiff: --- a/arch/x86/include/asm/mmu.h +++ b/arch/x86/include/asm/mmu.h @@ -9,8 +9,7 @@ * we put the segment information here. */ typedef struct { - void *ldt; - int size; + struct ldt_struct *ldt; #ifdef CONFIG_X86_64 /* True if mm supports a task running in 32 bit compatibility mode. */ --- there is your kABI breakage. Which brings us back full circle to the beginning. :-\
(In reply to Borislav Petkov from comment #55) > (In reply to Jiri Slaby from comment #54) > > My point is we don't take random patches just because. > > I explained to you already why they're not random. No, sorry, if it were really the reason, you would take especially 0b22930ebad563ae97ff3f8d7b9f12060b4c6e6b (a part of CVE-2015-3291) which increases applicability to entry_64.S of whatever a lot. As it stands, this makes your "to be as close to the upstream version as possible" false.
(In reply to Borislav Petkov from comment #56) > (In reply to Jiri Slaby from comment #46) > > Created attachment 644274 [details] > > diff of backport vs upstream > > > > I am afraid, I don't follow. The stable backports are 98% the same as > > upstream. For reference, I am attaching a diff of "stable 3.12 backport" and > > 37868fe113ff2ba. 9d05041679904b differs in three context lines. > > 9d05041679904b is the wrong commit id. 9d05041679904b is another example of upstream commit which can be applied easily (3 lines diff) If you mean a bad ID, you have a wrong tree: $ git describe --exact-match --contains 9d05041679904b v4.2-rc3~6^2~10 > > What am I missing? > > If the backport has this - which it must be, judging by your attached > interdiff: Not at all. Jikos wrote: " And as the original code had to be changed non-trivially anyway due to backporting, I think it makes sense to keep all the changes together, so that the patch is self-contained. It would be substantially different from the upstream version anyway. " We agreed, that the antecedent does not hold. Hence the patch can be almost the same as in upstream. And a kabi fix in a separate file. With the next SP, we can get rid of the kabi file. Especially in this case, when the kabi fix is a hack with barriers.
(In reply to Jiri Slaby from comment #57) > No, sorry, if it were really the reason, you would take especially > 0b22930ebad563ae97ff3f8d7b9f12060b4c6e6b (a part of CVE-2015-3291) which > increases applicability to entry_64.S of whatever a lot. As it stands, this > makes your "to be as close to the upstream version as possible" false. From a previous comment: "They're trivial but help a great deal with later backports, as I've come to realize recently when backporting an asm fix for SLE10-something." The emphasis being on *later*. At the time I was doing the backport, *nothing* was sure, what needs to go where.
(In reply to Jiri Slaby from comment #34) > 37868fe113ff2ba814b3b4eb12df214df555f8dc (x86/ldt: Make modify_ldt > synchronous) needs also: > 136d9d83c07c5e30ac49fc83b27e8c4842f108fc > 4809146b86c3d41ce588fdb767d021e2a80600dd and this: 12e244f4b550498bbaf654a52f93633f7dde2dc7
(In reply to Jiri Slaby from comment #58) > 9d05041679904b is another example of upstream commit which can be applied > easily (3 lines diff) Not really - it had 2 non-trivially resolvable hunk conflicts and the __kprobes thing can be missed. > If you mean a bad ID, you have a wrong tree: > $ git describe --exact-match --contains 9d05041679904b > v4.2-rc3~6^2~10 You said "attaching a diff of "stable 3.12 backport" and 37868fe113ff2ba. 9d05041679904b differs in three context lines." Now 37868fe113ff2ba and 9d05041679904b are two different upstream commits. What did you mean by the 9d05041679904b sentence at the end and what does that have to do with 37868fe113ff2ba?! > Hence the patch can be almost the same as in upstream. And a kabi fix > in a separate file. With the next SP, we can get rid of the kabi file. > Especially in this case, when the kabi fix is a hack with barriers. No, it isn't but you can't know because you're not on CC. Jürgen has done it correctly and jikos will apply it and then you'll see. Now, if you want the upstream backport and a kABI diff ontop adding Jürgen's changes, feel free to discuss that with jikos.
The xen part is in as aa1acff356bbedfd03b544051f5b371746735d89
Never ending story. 9b6e6a8334d56354853f9c255d1395c2ba570e0a needs: 83c133cf11fb0e68a51681447e372489f052d40e (x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code) and perhaps this: fc57a7c68020dcf954428869eafd934c0ab1536f (x86/paravirt: Replace the paravirt nop with a bona fide empty function) stable-3.12 will get them both automatically as they are marked stable.
SUSE-SU-2015:1727-1: An update that solves 7 vulnerabilities and has 44 fixes is now available. Category: security (important) Bug References: 856382,886785,898159,907973,908950,912183,914818,916543,920016,922071,924722,929092,929871,930813,932285,932350,934430,934942,934962,936556,936773,937609,937612,937613,937616,938550,938706,938891,938892,938893,939145,939266,939716,939834,939994,940398,940545,940679,940776,940912,940925,940965,941098,941305,941908,941951,942160,942204,942307,942367,948536 CVE References: CVE-2015-5156,CVE-2015-5157,CVE-2015-5283,CVE-2015-5697,CVE-2015-6252,CVE-2015-6937,CVE-2015-7613 Sources used: SUSE Linux Enterprise Workstation Extension 12 (src): kernel-default-3.12.48-52.27.1 SUSE Linux Enterprise Software Development Kit 12 (src): kernel-docs-3.12.48-52.27.2, kernel-obs-build-3.12.48-52.27.1 SUSE Linux Enterprise Server 12 (src): kernel-default-3.12.48-52.27.1, kernel-source-3.12.48-52.27.1, kernel-syms-3.12.48-52.27.1, kernel-xen-3.12.48-52.27.2 SUSE Linux Enterprise Module for Public Cloud 12 (src): kernel-ec2-3.12.48-52.27.1 SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_8-1-2.6 SUSE Linux Enterprise Desktop 12 (src): kernel-default-3.12.48-52.27.1, kernel-source-3.12.48-52.27.1, kernel-syms-3.12.48-52.27.1, kernel-xen-3.12.48-52.27.2
Ok, stuff has been backported to SLE12*, SLE11*, oS13.1, oS13.2. Leap has it from stable@ so I can *finally* bounce this back to the sec team. This bug was hmm... interesting, to say the least.
SUSE-SU-2015:2108-1: An update that solves 8 vulnerabilities and has 51 fixes is now available. Category: security (important) Bug References: 777565,814440,900610,904348,904965,920016,923002,926007,926709,926774,930145,930788,932350,932805,933721,935053,935757,936118,938706,939826,939926,939955,940017,940925,941202,942204,942305,942367,942605,942688,942938,943786,944296,944831,944837,944989,944993,945691,945825,945827,946078,946309,947957,948330,948347,948521,949100,949298,949502,949706,949744,949981,951440,952084,952384,952579,953527,953980,954404 CVE References: CVE-2015-0272,CVE-2015-5157,CVE-2015-5307,CVE-2015-6252,CVE-2015-6937,CVE-2015-7872,CVE-2015-7990,CVE-2015-8104 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP3 (src): kernel-docs-3.0.101-0.47.71.3 SUSE Linux Enterprise Server for VMWare 11-SP3 (src): kernel-bigsmp-3.0.101-0.47.71.1, kernel-default-3.0.101-0.47.71.1, kernel-pae-3.0.101-0.47.71.1, kernel-source-3.0.101-0.47.71.1, kernel-syms-3.0.101-0.47.71.1, kernel-trace-3.0.101-0.47.71.1, kernel-xen-3.0.101-0.47.71.1 SUSE Linux Enterprise Server 11-SP3 (src): kernel-bigsmp-3.0.101-0.47.71.1, kernel-default-3.0.101-0.47.71.1, kernel-ec2-3.0.101-0.47.71.1, kernel-pae-3.0.101-0.47.71.1, kernel-ppc64-3.0.101-0.47.71.1, kernel-source-3.0.101-0.47.71.1, kernel-syms-3.0.101-0.47.71.1, kernel-trace-3.0.101-0.47.71.1, kernel-xen-3.0.101-0.47.71.1 SUSE Linux Enterprise Server 11-EXTRA (src): kernel-bigsmp-3.0.101-0.47.71.1, kernel-default-3.0.101-0.47.71.1, kernel-pae-3.0.101-0.47.71.1, kernel-ppc64-3.0.101-0.47.71.1, kernel-trace-3.0.101-0.47.71.1, kernel-xen-3.0.101-0.47.71.1 SUSE Linux Enterprise Desktop 11-SP3 (src): kernel-bigsmp-3.0.101-0.47.71.1, kernel-default-3.0.101-0.47.71.1, kernel-pae-3.0.101-0.47.71.1, kernel-source-3.0.101-0.47.71.1, kernel-syms-3.0.101-0.47.71.1, kernel-trace-3.0.101-0.47.71.1, kernel-xen-3.0.101-0.47.71.1 SUSE Linux Enterprise Debuginfo 11-SP3 (src): kernel-bigsmp-3.0.101-0.47.71.1, kernel-default-3.0.101-0.47.71.1, kernel-ec2-3.0.101-0.47.71.1, kernel-pae-3.0.101-0.47.71.1, kernel-ppc64-3.0.101-0.47.71.1, kernel-trace-3.0.101-0.47.71.1, kernel-xen-3.0.101-0.47.71.1
SUSE-SU-2015:2339-1: An update that solves 10 vulnerabilities and has 57 fixes is now available. Category: security (important) Bug References: 814440,879378,879381,900610,904348,904965,921081,926774,930145,930770,930788,930835,932805,935123,935757,937256,937444,938706,939826,939926,939955,940017,940913,940946,941202,942938,943786,944296,944677,944831,944837,944989,944993,945691,945825,945827,946078,946214,946309,947957,948330,948347,948521,949100,949298,949502,949706,949744,949936,949981,950298,950750,950998,951440,952084,952384,952579,952976,953527,953799,953980,954404,954628,954950,954984,955673,956709 CVE References: CVE-2015-0272,CVE-2015-5157,CVE-2015-5307,CVE-2015-6937,CVE-2015-7509,CVE-2015-7799,CVE-2015-7872,CVE-2015-7990,CVE-2015-8104,CVE-2015-8215 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): kernel-docs-3.0.101-68.2 SUSE Linux Enterprise Server 11-SP4 (src): kernel-default-3.0.101-68.1, kernel-ec2-3.0.101-68.1, kernel-pae-3.0.101-68.1, kernel-ppc64-3.0.101-68.1, kernel-source-3.0.101-68.1, kernel-syms-3.0.101-68.1, kernel-trace-3.0.101-68.1, kernel-xen-3.0.101-68.1 SUSE Linux Enterprise Server 11-EXTRA (src): kernel-default-3.0.101-68.1, kernel-pae-3.0.101-68.1, kernel-ppc64-3.0.101-68.1, kernel-trace-3.0.101-68.1, kernel-xen-3.0.101-68.1 SUSE Linux Enterprise Desktop 11-SP4 (src): kernel-default-3.0.101-68.1, kernel-pae-3.0.101-68.1, kernel-source-3.0.101-68.1, kernel-syms-3.0.101-68.1, kernel-trace-3.0.101-68.1, kernel-xen-3.0.101-68.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): kernel-default-3.0.101-68.1, kernel-ec2-3.0.101-68.1, kernel-pae-3.0.101-68.1, kernel-ppc64-3.0.101-68.1, kernel-trace-3.0.101-68.1, kernel-xen-3.0.101-68.1
SUSE-SU-2015:2350-1: An update that solves 10 vulnerabilities and has 62 fixes is now available. Category: security (important) Bug References: 814440,879378,879381,900610,904348,904965,921081,926709,926774,930145,930770,930788,930835,932805,935053,935123,935757,937256,937444,937969,937970,938706,939207,939826,939926,939955,940017,940913,940946,941202,942938,943786,944677,944831,944837,944989,944993,945691,945825,945827,946078,946214,946309,947957,948330,948347,948521,949100,949298,949502,949706,949744,949936,949981,950298,950750,950998,951440,952084,952384,952579,952976,953527,953799,953980,954404,954628,954950,954984,955354,955673,956709 CVE References: CVE-2015-0272,CVE-2015-5157,CVE-2015-5307,CVE-2015-6937,CVE-2015-7509,CVE-2015-7799,CVE-2015-7872,CVE-2015-7990,CVE-2015-8104,CVE-2015-8215 Sources used: SUSE Linux Enterprise Real Time Extension 11-SP4 (src): kernel-rt-3.0.101.rt130-48.1, kernel-rt_trace-3.0.101.rt130-48.1, kernel-source-rt-3.0.101.rt130-48.1, kernel-syms-rt-3.0.101.rt130-48.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): kernel-rt-3.0.101.rt130-48.1, kernel-rt_debug-3.0.101.rt130-48.1, kernel-rt_trace-3.0.101.rt130-48.1
i guess we are through
openSUSE-SU-2016:0301-1: An update that solves 57 vulnerabilities and has 21 fixes is now available. Category: security (important) Bug References: 814440,851610,869564,873385,906545,907818,909077,909477,911326,912202,915517,915577,917830,918333,919007,919018,919463,919596,921313,921949,922583,922936,922944,926238,926240,927780,927786,928130,929525,930399,931988,932348,933896,933904,933907,933934,935542,935705,936502,936831,937032,937033,937969,938706,940338,944296,945825,947155,949936,950998,951194,951440,951627,952384,952579,952976,953052,953527,954138,954404,955224,955354,955422,956708,956934,957988,957990,958504,958510,958886,958951,959190,959399,959568,960839,961509,961739,962075 CVE References: CVE-2014-2568,CVE-2014-8133,CVE-2014-8989,CVE-2014-9090,CVE-2014-9419,CVE-2014-9529,CVE-2014-9683,CVE-2014-9715,CVE-2014-9728,CVE-2014-9729,CVE-2014-9730,CVE-2014-9731,CVE-2015-0272,CVE-2015-0777,CVE-2015-1420,CVE-2015-1421,CVE-2015-2041,CVE-2015-2042,CVE-2015-2150,CVE-2015-2666,CVE-2015-2830,CVE-2015-2922,CVE-2015-2925,CVE-2015-3212,CVE-2015-3339,CVE-2015-3636,CVE-2015-4001,CVE-2015-4002,CVE-2015-4003,CVE-2015-4004,CVE-2015-4036,CVE-2015-4167,CVE-2015-4692,CVE-2015-4700,CVE-2015-5157,CVE-2015-5283,CVE-2015-5307,CVE-2015-5364,CVE-2015-5366,CVE-2015-5707,CVE-2015-6937,CVE-2015-7550,CVE-2015-7799,CVE-2015-7833,CVE-2015-7872,CVE-2015-7885,CVE-2015-7990,CVE-2015-8104,CVE-2015-8215,CVE-2015-8543,CVE-2015-8550,CVE-2015-8551,CVE-2015-8552,CVE-2015-8569,CVE-2015-8575,CVE-2015-8767,CVE-2016-0728 Sources used: openSUSE 13.1 (src): cloop-2.639-11.22.2, crash-7.0.2-2.22.2, hdjmod-1.28-16.22.2, ipset-6.21.1-2.26.2, iscsitarget-1.4.20.3-13.22.2, kernel-debug-3.11.10-32.1, kernel-default-3.11.10-32.1, kernel-desktop-3.11.10-32.1, kernel-docs-3.11.10-32.3, kernel-ec2-3.11.10-32.1, kernel-pae-3.11.10-32.1, kernel-source-3.11.10-32.1, kernel-syms-3.11.10-32.1, kernel-trace-3.11.10-32.1, kernel-vanilla-3.11.10-32.1, kernel-xen-3.11.10-32.1, ndiswrapper-1.58-22.1, pcfclock-0.44-258.22.1, vhba-kmp-20130607-2.23.1, virtualbox-4.2.36-2.55.1, xen-4.3.4_10-56.1, xtables-addons-2.3-2.22.1
openSUSE-SU-2016:0318-1: An update that solves 19 vulnerabilities and has 18 fixes is now available. Category: security (important) Bug References: 814440,906545,912202,921949,937969,937970,938706,944296,945825,949936,950998,951627,951638,952384,952579,952976,953527,954138,954404,955224,955354,955422,956708,956934,957988,957990,958504,958510,958886,958951,959190,959399,959568,960839,961509,961739,962075 CVE References: CVE-2014-8989,CVE-2014-9529,CVE-2015-5157,CVE-2015-5307,CVE-2015-6937,CVE-2015-7550,CVE-2015-7799,CVE-2015-7885,CVE-2015-7990,CVE-2015-8104,CVE-2015-8215,CVE-2015-8543,CVE-2015-8550,CVE-2015-8551,CVE-2015-8552,CVE-2015-8569,CVE-2015-8575,CVE-2015-8767,CVE-2016-0728 Sources used: openSUSE 13.2 (src): bbswitch-0.8-3.15.1, cloop-2.639-14.15.1, crash-7.0.8-15.1, hdjmod-1.28-18.16.1, ipset-6.23-15.1, kernel-debug-3.16.7-32.1, kernel-default-3.16.7-32.1, kernel-desktop-3.16.7-32.1, kernel-docs-3.16.7-32.2, kernel-ec2-3.16.7-32.1, kernel-obs-build-3.16.7-32.2, kernel-obs-qa-3.16.7-32.1, kernel-obs-qa-xen-3.16.7-32.1, kernel-pae-3.16.7-32.1, kernel-source-3.16.7-32.1, kernel-syms-3.16.7-32.1, kernel-vanilla-3.16.7-32.1, kernel-xen-3.16.7-32.1, pcfclock-0.44-260.15.1, vhba-kmp-20140629-2.15.1, virtualbox-4.3.34-37.1, xen-4.4.3_08-38.1, xtables-addons-2.6-15.1
SUSE-SU-2016:0354-1: An update that solves 9 vulnerabilities and has 54 fixes is now available. Category: security (important) Bug References: 777565,814440,900610,904348,904965,920016,923002,926007,926709,926774,930145,930788,932350,932805,933721,935053,935757,936118,937969,937970,938706,939207,939826,939926,939955,940017,940925,941202,942204,942305,942367,942605,942688,942938,943786,944296,944831,944837,944989,944993,945691,945825,945827,946078,946309,947957,948330,948347,948521,949100,949298,949502,949706,949744,949981,951440,952084,952384,952579,953527,953980,954404,955354 CVE References: CVE-2015-0272,CVE-2015-5157,CVE-2015-5307,CVE-2015-6252,CVE-2015-6937,CVE-2015-7872,CVE-2015-7990,CVE-2015-8104,CVE-2015-8215 Sources used: SUSE Linux Enterprise Real Time Extension 11-SP3 (src): kernel-rt-3.0.101.rt130-0.33.44.2, kernel-rt_trace-3.0.101.rt130-0.33.44.2, kernel-source-rt-3.0.101.rt130-0.33.44.2, kernel-syms-rt-3.0.101.rt130-0.33.44.1 SUSE Linux Enterprise Debuginfo 11-SP3 (src): kernel-rt-3.0.101.rt130-0.33.44.2, kernel-rt_trace-3.0.101.rt130-0.33.44.2
Statement from our kernel team regarding older products: With an absense of the perf infrastructure we are not aware of any user triggerable source of NMIs that could cause NMI nesting and a such consider 2.6.16 based kernels unaffected.