Bug 959709

From: Jann Horn <jann@thejh.net>

On Thu, Dec 17, 2015 at 02:39:58PM -0800, John Johansen wrote:
> I haven't seen CVE request for this one yet so,
> 
> Jann Horn reported a privilege escalation in user namespaces to the
> lkml mailing list
> 
> https://lkml.org/lkml/2015/12/12/259
> 
> if a root-owned process wants to enter a user
> namespace for some reason without knowing who owns it and
> therefore can't change to the namespace owner's uid and gid
> before entering, as soon as it has entered the namespace,
> the namespace owner can attach to it via ptrace and thereby
> gain access to its uid and gid.

I'm not sure whether this is CVE-worthy - the user_namespaces
manpage says "the process has full privileges for operations
inside the user namespace, but is unprivileged for operations
outside the namespace". ptrace()ing a process in the
namespace can reasonably be considered an "operation inside
the user namespace", and therefore the manpage kinda implies
the old behavior. (Yes, more detailed documentation would be
nicer, I might submit man-pages patches once my patches are
in a kernel release.)

In my opinion, this patch is somewhere between hardening and
a security feature, but I wouldn't really call it a vuln fix.

From: Serge Hallyn <serge.hallyn@ubuntu.com>

Except by creating a file in the host namespace, you were, as
root in the container, able to escape your namespace, right?

From Solar Designer

On Thu, Dec 17, 2015 at 02:39:58PM -0800, John Johansen wrote:
> Jann Horn reported a privilege escalation in user namespaces to the
> lkml mailing list
> 
> https://lkml.org/lkml/2015/12/12/259
> 
> if a root-owned process wants to enter a user
> namespace for some reason without knowing who owns it and
> therefore can't change to the namespace owner's uid and gid
> before entering, as soon as it has entered the namespace,
> the namespace owner can attach to it via ptrace and thereby
> gain access to its uid and gid.

This appears related:

Back in 2005, I performed a security audit of soon-to-be-released
OpenVZ.  (It was very nice of SWsoft/Parallels to put the effort and
funding into this before making the project public.)  The security audit
report has finally been made public here:

https://lists.openvz.org/pipermail/users/2015-October/006563.html

As I recall, one of the changes OpenVZ developers made during the audit,
in response to very early findings, was prevent a process entering a
container (called VPS or VE at the time, for Virtual Environment) from
being ptrace'd by a process already running in the container.  This
scenario would be relevant when using the "vzctl enter ..." and "vzctl
exec ..." commands.  As something fixed before audit end, this isn't
fully reflected in the audit report (which I now regret, as it would
have helped refresh my memory), except for this indirect note about vzctl:

| 2.2. Testing and review of "strace" logs revealed that only the first 16
| fd's were being closed on VPS entry.  This needs to be corrected.  Also,
| the fd's are being closed _after_ the ioctl call, which is not great,
| although the risk is now mitigated by having the VPS-entering process
| protected from ptrace(2).

My point is that it does make sense to protect a container- or
namespace-entering process from attacks by the container/namespace.
There are attacks this may mitigate.  (Other mitigations are also
needed, though: including e.g. closing the fd's, as mentioned above, and
allocating a new pty, if applicable.  vzctl does these things.  And the
specific "first 16 fd's" issue was corrected at the time, as well.)

Then, one of the recommendations for hardening OpenVZ security that I
listed in the report was:

| 3. The most reliable way to deal with attacks based on matching UIDs is
| to simply not have those, but rather translate full 32-bit unique
| UIDs/GIDs to VPS-specific ones on kernel interfaces.  This has been
| briefly discussed on the mailing list.  The biggest disadvantage that
| was mentioned is that it would make it harder to migrate VPSes across
| nodes.
| 
| It was suggested that matching UIDs/GIDs could continue to be used in
| different VPSes, but they would be different from those the host system
| would use.  In order to ensure cross-VPS security even if an attacker
| would manage to escape from a VPS' chroot jail, permissions on
| /vz/private would need to be set to 700 (with host root as the owner),
| which is being recommended above for other reasons anyway.  Additionally,
| the meaning of certain capabilities (CAP_DAC_OVERRIDE, etc.) would need
| to be "virtualized" when in VE context.  That is, the DAC override would
| apply only to files whose owner UIDs fall within the VPS' range, etc.
| 
| Unfortunately, with all these considerations, this does appear to be not
| so trivial to implement.  So this is more of an idea for further
| discussion rather than a final recommendation.

As far as I'm aware, this was never implemented.

Fast forward to 2015, OpenVZ is experimenting with user namespaces:

https://twitter.com/_openvz_/status/654625273313255425

| 15 Oct 2015
| "Call for testing: Start CT in a new user namespace: 1:1 user mapping"

https://openvz.org/Start_CT_in_a_new_user_namespace:_1:1_user_mapping
https://lists.openvz.org/pipermail/devel/2015-October/033354.html

| Now CT starts in a new user namespace. This allows us
| * to remove our capabilities (CAP_VE_*)
| * to improve security of our containers, because a process doesn't have privileges outside the container

| Testing
| * need to execute tests to check security of containers
| * execute all tests, because these changes are touching very general parts

I think this applies to experimental RHEL7-based OpenVZ kernels, rather
than to the RHEL6-based (let alone RHEL5-based) OpenVZ kernels that most
people (who use OpenVZ at all) use now.

I found no time to look into this yet, but I recognize now might be the
right time to review this and make it right.

A concern is that old, previously-fixed issues like ptrace'ing a
container-entering process might be opened up.  Another concern is that
unprivileged user namespaces are a (well-known by now?) risk on their
own.  Thus, there needs to be a way to configure a RHEL7/OpenVZ kernel
such that it can use user namespaces to enhance container security, but
users (including host system non-root users) can't use and abuse those -
and this must be the default.

Other than that, it looks like this is a way and an opportunity to
address this long-standing OpenVZ hardening recommendation of mine.

I am not yet looking at Linux containers beyond OpenVZ, but as they
mature I think they'll need to consider the same issues, and my 2005
audit report might still be a relevant checklist.

I'd appreciate comments from people who are more up-to-date on this.

Thanks,

Alexander

From: Fiedler Roman <Roman.Fiedler@ait.ac.at>

Hi,

> Von: John Johansen [mailto:john.johansen@canonical.com]
> Betreff: [oss-security] CVE Request: Linux kernel: privilege escalation in 
> user
> namespaces
>
> Hi,
>
> I haven't seen CVE request for this one yet so,
>
> Jann Horn reported a privilege escalation in user namespaces to the lkml
> mailing list
>
> https://lkml.org/lkml/2015/12/12/259
>
> if a root-owned process wants to enter a user namespace for some reason
> without knowing who owns it and therefore can't change to the namespace
> owner's uid and gid before entering, as soon as it has entered the
> namespace, the namespace owner can attach to it via ptrace and thereby
> gain access to its uid and gid.

Could it be, that this is identical to

https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1475050

which led to

https://bugs.launchpad.net/bugs/cve/2015-1334

except, that combined with another timerace, this gives host uid 0 escalation 
no matter how the target namespace looks like or target uid is known or not?

The bug is marked as fixed, but looking at it, the very similar kernel issue 
seems not be addressed and it is also still marked "private security" although 
fix was released.

I could ask Ubuntu Security if we should make that bug public or perhaps could 
add accounts to the list of authorized users when told the Launchpad user name 
to add.

Kind Regards,
Roman

bugbot adjusting priority

Hi,
 I was going to agree that this looked more like a hardening - Eric Biederman says as much in the thread - but that mail from Roman that you included shows that lxc-attach is very likely to be vulnerable to a ptrace attack while it is still externally privileged.

https://lkml.org/lkml/2015/12/25/71
is a better patch than the one mentioned in the description.
I would feel more comfortable if this had gone upstream already though...

It probably won't go upstream.  Eric suggested that using the 'dumpable' flag to prevent ptrace is probably a better idea.  lxc-attach could use prctl(PT_SET_DUMPABLE) to ensure it cannot be ptraced.

So I'd probably rather not apply the patch, but it really is credible that lxc-attach is vulnerable and the patch looks quite safe.

I'll attach the patch.  If no-one objects I'll add it to SLE12(and -SP*)

Created attachment 665363 [details]
Proposed patch

(In reply to Neil Brown from comment #8)
> So I'd probably rather not apply the patch, but it really is credible that
> lxc-attach is vulnerable and the patch looks quite safe.
> 
> I'll attach the patch.  If no-one objects I'll add it to SLE12(and -SP*)

So why aren't we patching lxc-attach?

Or you'd prefer to patch the kernel too, just in case, considering the
fact that the patch is pretty safe?

Btw, what's with the while-loop? Is that some sort of a namespaces chain
of parents?

Thanks.

(In reply to Borislav Petkov from comment #10)

> So why aren't we patching lxc-attach?

Maybe we should.
I don't know enough about how lxc-attach is used.
using PT_SET_DUMPABLE to disable ptrace would be easy enough, but I don't
know if there might be a case where it needs to be re-enabled again.  Maybe it drops privileged and runs some regular user program that might need to be traced.

Best ask someone who uses the tool.

> 
> Or you'd prefer to patch the kernel too, just in case, considering the
> fact that the patch is pretty safe?

That was my thinking, yes.


> 
> Btw, what's with the while-loop? Is that some sort of a namespaces chain
> of parents?

Yes.  Namespaces can be nested.  It walks up the chain of nested name spaces until if finds one where both of the relevant processes have well defined uids.  Then it checks privileges there.

(In reply to Neil Brown from comment #11)
> Maybe we should.
> I don't know enough about how lxc-attach is used.
> using PT_SET_DUMPABLE to disable ptrace would be easy enough, but I don't
> know if there might be a case where it needs to be re-enabled again.  Maybe
> it drops privileged and runs some regular user program that might need to be
> traced.
> 
> Best ask someone who uses the tool.

Also, I don't think that patching one tool takes care of the issue. What
about other tools/progs using user namespaces?!

> That was my thinking, yes.

I agree. And this way we're covered, no matter the userspace tool.

> Yes. Namespaces can be nested. It walks up the chain of nested name
> spaces until if finds one where both of the relevant processes have
> well defined uids. Then it checks privileges there.

Ah ok, makes more sense. Regardless, namespaces stuff is krazy like
that! :-)

Thanks Neil.

I've submitted the kernel patch to SLE12 and SLE12-SP2 (-SP1 gets it automatically from SLE12).
So I think we are done here?

*** Bug 960561 has been marked as a duplicate of this bug. ***

(In reply to Neil Brown from comment #13)
> I've submitted the kernel patch to SLE12 and SLE12-SP2 (-SP1 gets it
> automatically from SLE12).
> So I think we are done here?

What about SLE11* and openSUSE 13.2 and Leap? They all have CONFIG_USER_NS=y.

> What about SLE11*

Easier said than done.  The uid mapping was very different back in 3.0.
Enough so that I'll need to make sure I actually understand how it works in both the new and old version.  Maybe next week.

13.2 and LEAP were just 'cherry-pick' and 'check', so they are done.

> What about SLE11* and ...? They all have CONFIG_USER_NS=y.

An important part of the (supposed) vulnerability is that a privileged process enters a user-namespace and can then be taken over.
Prior to
Commit: cde1975bc242 ("userns: Implent proc namespace operations")
in v3.8-rc1, a process count not enter a user namespace.

So kernels prior to 3.8, and SLE-11 specifically, do not need fixing.
(I'm so glad I didn't have to backport the patch ... it was getting messy).

Oh cool, saved by the ... kernel version! :-)

Ok, that should cover all our releases, AFAICT. Thanks a lot Neil!

Bouncing back to sec-team.

SUSE-SU-2016:0785-1: An update that solves 10 vulnerabilities and has 66 fixes is now available.

Category: security (important)
Bug References: 812259,816099,855062,867583,884701,899908,922071,937444,940338,940946,941363,943989,945219,947953,949752,950292,951155,955308,955654,956084,956514,957525,957986,959090,959146,959257,959463,959629,959709,960174,960227,960458,960561,960629,961257,961500,961509,961516,961588,961658,961971,962336,962356,962788,962965,963193,963449,963572,963746,963765,963767,963825,963960,964201,964730,965199,965344,965830,965840,965891,966026,966094,966278,966437,966471,966693,966864,966910,967802,968018,968074,968206,968230,968234,968253,969112
CVE References: CVE-2013-7446,CVE-2015-5707,CVE-2015-8709,CVE-2015-8767,CVE-2015-8785,CVE-2015-8812,CVE-2016-0723,CVE-2016-0774,CVE-2016-2069,CVE-2016-2384
Sources used:
SUSE Linux Enterprise Workstation Extension 12 (src):    kernel-default-3.12.55-52.42.1
SUSE Linux Enterprise Software Development Kit 12 (src):    kernel-docs-3.12.55-52.42.2, kernel-obs-build-3.12.55-52.42.2
SUSE Linux Enterprise Server 12 (src):    kernel-default-3.12.55-52.42.1, kernel-source-3.12.55-52.42.1, kernel-syms-3.12.55-52.42.1, kernel-xen-3.12.55-52.42.1
SUSE Linux Enterprise Module for Public Cloud 12 (src):    kernel-ec2-3.12.55-52.42.1
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12_Update_12-1-2.1
SUSE Linux Enterprise Desktop 12 (src):    kernel-default-3.12.55-52.42.1, kernel-source-3.12.55-52.42.1, kernel-syms-3.12.55-52.42.1, kernel-xen-3.12.55-52.42.1

openSUSE-SU-2016:1008-1: An update that solves 15 vulnerabilities and has 26 fixes is now available.

Category: security (important)
Bug References: 814440,884701,949936,951440,951542,951626,951638,953527,954018,954404,954405,954876,958439,958463,958504,959709,960561,960563,960710,961263,961500,961509,962257,962866,962977,963746,963765,963767,963931,965125,966137,966179,966259,966437,966684,966693,968018,969356,969582,970845,971125
CVE References: CVE-2015-1339,CVE-2015-7799,CVE-2015-7872,CVE-2015-7884,CVE-2015-8104,CVE-2015-8709,CVE-2015-8767,CVE-2015-8785,CVE-2015-8787,CVE-2015-8812,CVE-2016-0723,CVE-2016-2069,CVE-2016-2184,CVE-2016-2383,CVE-2016-2384
Sources used:
openSUSE Leap 42.1 (src):    kernel-debug-4.1.20-11.1, kernel-default-4.1.20-11.1, kernel-docs-4.1.20-11.3, kernel-ec2-4.1.20-11.1, kernel-obs-build-4.1.20-11.2, kernel-obs-qa-4.1.20-11.1, kernel-obs-qa-xen-4.1.20-11.1, kernel-pae-4.1.20-11.1, kernel-pv-4.1.20-11.1, kernel-source-4.1.20-11.1, kernel-syms-4.1.20-11.1, kernel-vanilla-4.1.20-11.1, kernel-xen-4.1.20-11.1

SUSE-SU-2016:1019-1: An update that solves 9 vulnerabilities and has 70 fixes is now available.

Category: security (important)
Bug References: 816099,867251,875631,880007,943645,944749,945219,949752,955308,956084,956852,957986,959146,959257,959463,959709,960174,960458,960561,960629,961257,961500,961516,961588,961658,963193,963746,963765,963827,963960,964201,964730,965087,965199,965830,965891,965924,966026,966094,966278,966437,966471,966693,966831,966864,966910,967047,967292,967299,967650,967651,967802,967903,968010,968018,968074,968141,968206,968230,968234,968253,968448,968512,968643,968670,969112,969439,969571,969655,969690,969735,969992,969993,970062,970160,970249,970909,971125,971360
CVE References: CVE-2015-8709,CVE-2015-8812,CVE-2015-8816,CVE-2016-2143,CVE-2016-2184,CVE-2016-2384,CVE-2016-2782,CVE-2016-3139,CVE-2016-3156
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP1 (src):    kernel-default-3.12.57-60.35.1
SUSE Linux Enterprise Software Development Kit 12-SP1 (src):    kernel-docs-3.12.57-60.35.3, kernel-obs-build-3.12.57-60.35.1
SUSE Linux Enterprise Server 12-SP1 (src):    kernel-default-3.12.57-60.35.1, kernel-source-3.12.57-60.35.1, kernel-syms-3.12.57-60.35.1, kernel-xen-3.12.57-60.35.1
SUSE Linux Enterprise Module for Public Cloud 12 (src):    kernel-ec2-3.12.57-60.35.1
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12-SP1_Update_4-1-2.3
SUSE Linux Enterprise Desktop 12-SP1 (src):    kernel-default-3.12.57-60.35.1, kernel-source-3.12.57-60.35.1, kernel-syms-3.12.57-60.35.1, kernel-xen-3.12.57-60.35.1

SUSE-SU-2016:1764-1: An update that solves 26 vulnerabilities and has 95 fixes is now available.

Category: security (important)
Bug References: 880007,889207,899908,903279,908151,931448,937086,940413,942262,943645,943989,945219,956084,956852,957986,957988,957990,959146,959514,959709,960174,960561,960629,961500,961512,961658,962336,962872,963193,963572,963746,963765,963827,963960,964201,964461,965087,965153,965199,965319,965830,965924,966054,966094,966437,966471,966573,966693,966831,966864,966910,967047,967251,967292,967299,967650,967651,967802,967903,968010,968018,968074,968141,968206,968230,968234,968253,968448,968497,968512,968643,968670,968687,968812,968813,969112,969439,969571,969655,969690,969735,969992,969993,970062,970160,970504,970604,970609,970892,970909,970911,970948,970955,970956,970958,970970,971124,971125,971126,971159,971170,971360,971600,971628,972003,972068,972174,972780,972844,972891,972951,973378,973556,973855,974406,974418,975371,975488,975772,975945,980246
CVE References: CVE-2015-7566,CVE-2015-8550,CVE-2015-8551,CVE-2015-8552,CVE-2015-8709,CVE-2015-8785,CVE-2015-8812,CVE-2015-8816,CVE-2016-0723,CVE-2016-2143,CVE-2016-2184,CVE-2016-2185,CVE-2016-2186,CVE-2016-2188,CVE-2016-2384,CVE-2016-2782,CVE-2016-3134,CVE-2016-3136,CVE-2016-3137,CVE-2016-3138,CVE-2016-3139,CVE-2016-3140,CVE-2016-3156,CVE-2016-3689,CVE-2016-3707,CVE-2016-3951
Sources used:
SUSE Linux Enterprise Real Time Extension 12-SP1 (src):    kernel-compute-3.12.58-14.1, kernel-compute_debug-3.12.58-14.1, kernel-rt-3.12.58-14.1, kernel-rt_debug-3.12.58-14.1, kernel-source-rt-3.12.58-14.1, kernel-syms-rt-3.12.58-14.1

rekeased

openSUSE-SU-2016:2144-1: An update that solves 53 vulnerabilities and has 28 fixes is now available.

Category: security (important)
Bug References: 901754,941113,942702,945219,955654,957052,957988,959709,960561,961512,963762,963765,966245,966437,966693,966849,967972,967973,967974,967975,968010,968011,968012,968013,968018,968670,969354,969355,970114,970275,970892,970909,970911,970948,970955,970956,970958,970970,971124,971125,971126,971360,971628,971799,971919,971944,972174,973378,973570,974308,974418,974646,975945,978401,978445,978469,978821,978822,979021,979213,979548,979867,979879,979913,980348,980363,980371,980725,981267,982706,983143,983213,984464,984755,984764,986362,986365,986377,986572,986573,986811
CVE References: CVE-2012-6701,CVE-2013-7446,CVE-2014-9904,CVE-2015-3288,CVE-2015-6526,CVE-2015-7566,CVE-2015-8709,CVE-2015-8785,CVE-2015-8812,CVE-2015-8816,CVE-2015-8830,CVE-2016-0758,CVE-2016-1583,CVE-2016-2053,CVE-2016-2184,CVE-2016-2185,CVE-2016-2186,CVE-2016-2187,CVE-2016-2188,CVE-2016-2384,CVE-2016-2543,CVE-2016-2544,CVE-2016-2545,CVE-2016-2546,CVE-2016-2547,CVE-2016-2548,CVE-2016-2549,CVE-2016-2782,CVE-2016-2847,CVE-2016-3134,CVE-2016-3136,CVE-2016-3137,CVE-2016-3138,CVE-2016-3139,CVE-2016-3140,CVE-2016-3156,CVE-2016-3672,CVE-2016-3689,CVE-2016-3951,CVE-2016-4470,CVE-2016-4482,CVE-2016-4485,CVE-2016-4486,CVE-2016-4565,CVE-2016-4569,CVE-2016-4578,CVE-2016-4580,CVE-2016-4581,CVE-2016-4805,CVE-2016-4913,CVE-2016-4997,CVE-2016-5244,CVE-2016-5829
Sources used:
openSUSE 13.2 (src):    bbswitch-0.8-3.20.3, cloop-2.639-14.20.3, crash-7.0.8-20.3, hdjmod-1.28-18.21.3, ipset-6.23-20.3, kernel-debug-3.16.7-42.1, kernel-default-3.16.7-42.1, kernel-desktop-3.16.7-42.1, kernel-docs-3.16.7-42.2, kernel-ec2-3.16.7-42.1, kernel-obs-build-3.16.7-42.2, kernel-obs-qa-3.16.7-42.1, kernel-obs-qa-xen-3.16.7-42.1, kernel-pae-3.16.7-42.1, kernel-source-3.16.7-42.1, kernel-syms-3.16.7-42.1, kernel-vanilla-3.16.7-42.1, kernel-xen-3.16.7-42.1, pcfclock-0.44-260.20.2, vhba-kmp-20140629-2.20.2, virtualbox-5.0.20-48.5, xen-4.4.4_02-46.2, xtables-addons-2.6-22.3

I commented the patch out from SP2 as:
* it never reached upstream
* the issue was disputed
* it collides with the upstream fix bfedb589 (mm: Add a user_ns owner to mm_struct and fix ptrace permission checks)

Please revisit if this patch is still needed or can be dropped forever (and do so).

openSUSE-SU-2017:0456-1: An update that solves 11 vulnerabilities and has 98 fixes is now available.

Category: security (important)
Bug References: 1000092,1000619,1003077,1003253,1005918,1006469,1006472,1007729,1008742,1009546,1009674,1009718,1009911,1009969,1010612,1010690,1011176,1011250,1011602,1011660,1011913,1012422,1012829,1012910,1013000,1013001,1013273,1013531,1013540,1013542,1013792,1013994,1014120,1014392,1014410,1014701,1014710,1015038,1015212,1015359,1015367,1015416,1015840,1016250,1016403,1016517,1016884,1016979,1017164,1017170,1017410,1017589,1018100,1018316,1018358,1018385,1018446,1018813,1018913,1019061,1019148,1019260,1019351,1019594,1019630,1019631,1019784,1019851,1020214,1020488,1020602,1020685,1020817,1020945,1020975,1021248,1021251,1021258,1021260,1021294,1021455,1021474,1022304,1022429,1022476,1022547,1022559,1022971,1023101,1023175,921494,959709,960561,964944,966170,966172,966186,966191,969474,969475,969756,971975,974215,979378,981709,985561,987192,987576,991273
CVE References: CVE-2015-8709,CVE-2016-7117,CVE-2016-8645,CVE-2016-9793,CVE-2016-9806,CVE-2016-9919,CVE-2017-2583,CVE-2017-2584,CVE-2017-5551,CVE-2017-5576,CVE-2017-5577
Sources used:
openSUSE Leap 42.2 (src):    kernel-debug-4.4.46-11.1, kernel-default-4.4.46-11.1, kernel-docs-4.4.46-11.3, kernel-obs-build-4.4.46-11.1, kernel-obs-qa-4.4.46-11.1, kernel-source-4.4.46-11.1, kernel-syms-4.4.46-11.1, kernel-vanilla-4.4.46-11.1

SUSE-SU-2017:0575-1: An update that solves 11 vulnerabilities and has 95 fixes is now available.

Category: security (important)
Bug References: 1000092,1000619,1003077,1005918,1006469,1006472,1007729,1008742,1009546,1009674,1009718,1009911,1010612,1010690,1010933,1011176,1011602,1011660,1011913,1012382,1012422,1012829,1012910,1013000,1013001,1013273,1013540,1013792,1013994,1014120,1014410,1015038,1015367,1015840,1016250,1016403,1016517,1016884,1016979,1017164,1017170,1017410,1018100,1018316,1018358,1018446,1018813,1018913,1019061,1019148,1019168,1019260,1019351,1019594,1019630,1019631,1019784,1019851,1020048,1020214,1020488,1020602,1020685,1020817,1020945,1020975,1021082,1021248,1021251,1021258,1021260,1021294,1021455,1021474,1022304,1022429,1022476,1022547,1022559,1022971,1023101,1023175,1023762,1023884,1023888,1024081,1024234,1024508,1024938,1025235,921494,959709,964944,969476,969477,969479,971975,974215,981709,982783,985561,987192,987576,989056,991273,998106
CVE References: CVE-2015-8709,CVE-2016-7117,CVE-2016-9806,CVE-2017-2583,CVE-2017-2584,CVE-2017-5551,CVE-2017-5576,CVE-2017-5577,CVE-2017-5897,CVE-2017-5970,CVE-2017-5986
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP2 (src):    kernel-default-4.4.49-92.11.1
SUSE Linux Enterprise Software Development Kit 12-SP2 (src):    kernel-docs-4.4.49-92.11.3, kernel-obs-build-4.4.49-92.11.1
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    kernel-default-4.4.49-92.11.1, kernel-source-4.4.49-92.11.1, kernel-syms-4.4.49-92.11.1
SUSE Linux Enterprise Server 12-SP2 (src):    kernel-default-4.4.49-92.11.1, kernel-source-4.4.49-92.11.1, kernel-syms-4.4.49-92.11.1
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12-SP2_Update_5-1-6.1
SUSE Linux Enterprise High Availability 12-SP2 (src):    kernel-default-4.4.49-92.11.1
SUSE Linux Enterprise Desktop 12-SP2 (src):    kernel-default-4.4.49-92.11.1, kernel-source-4.4.49-92.11.1, kernel-syms-4.4.49-92.11.1
OpenStack Cloud Magnum Orchestration 7 (src):    kernel-default-4.4.49-92.11.1

all done now I think