bugbot adjusting priority

The code in SLE11-SP3 is quite different in this area. We are missing b2a4df200d57 ("KEYS: Expand the capacity of a keyring") which is  and 034faeb9ef39 ("KEYS: Fix keyring quota misaccounting on key replacement and unlink") which are 3.13. I am not familiar with this code but it smells like the second one is the culprit.

All that I can see is that our __key_link_begin stores its pre-allocation to prealloc which is then cleaned up in __key_link_end so we shouldn't leak. Somebody familiar with the code should double check but I guess we are not affected in SLE11-SP3 and prior.

SLE12 has the first patch b2a4df200d57 but it lacks the second.

is public

From: Tyler Hicks
While improving the system call coverage in stress-ng[1], Colin Ian King
discovered a bug in the Linux kernel keyring that can be used to cause a
local denial of service due to memory exhaustion when the same key is
repeatedly added to the kernel keyring via the add_key() syscall.

This issue has been assigned CVE-2015-1333.

From: Tyler Hicks

mancha pinged me on IRC while trying to figure out what kernel versions
are affected and I realized that I forgot to include an import detail in
my original email.

The following commit introduced the issue:

  commit 034faeb9ef390d58239e1dce748143f6b35a0d9b
  Date:   Wed Oct 30 11:15:24 2013 +0000

      KEYS: Fix keyring quota misaccounting on key replacement and unlink

Which means that v3.13 and newer kernels are affected:

  $ git describe --contains 034faeb9ef390d58239e1dce748143f6b35a0d9b
  v3.13-rc1~18^2~6^2~2

(In reply to Michal Hocko from comment #2)
> The code in SLE11-SP3 is quite different in this area. We are missing
> b2a4df200d57 ("KEYS: Expand the capacity of a keyring") which is  and
> 034faeb9ef39 ("KEYS: Fix keyring quota misaccounting on key replacement and
> unlink") which are 3.13. I am not familiar with this code but it smells like
> the second one is the culprit.
> 
> All that I can see is that our __key_link_begin stores its pre-allocation to
> prealloc which is then cleaned up in __key_link_end so we shouldn't leak.
> Somebody familiar with the code should double check but I guess we are not
> affected in SLE11-SP3 and prior.
> 
> SLE12 has the first patch b2a4df200d57 but it lacks the second.

Thanks for Michal's help. I checked SLE12/SLE12 SP1 and SLE11-SP4, as Michal's point out, the secure issue doesn't affect to SLE12 and SLE11.

This secure issue affects openSUSE 13.2, I backported Colin Ian King's ca4da5dd1f patch from v4.2-rc5 to openSUSE 13.2. Waiting maintainer merge.

Reopen for waiting openSUSE 13.2 patch got merged.

Backported patch merged to openSUSE 13.2 kernel. Set this issue to FIXED.

openSUSE-SU-2015:1842-1: An update that solves 7 vulnerabilities and has 7 fixes is now available.

Category: security (important)
Bug References: 919154,926238,937969,938645,939834,940338,941104,941305,941867,942178,944296,947155,951195,951440
CVE References: CVE-2015-0272,CVE-2015-1333,CVE-2015-2925,CVE-2015-3290,CVE-2015-5283,CVE-2015-5707,CVE-2015-7872
Sources used:
openSUSE 13.2 (src):    bbswitch-0.8-3.13.2, cloop-2.639-14.13.2, crash-7.0.8-13.2, hdjmod-1.28-18.14.2, ipset-6.23-13.2, kernel-debug-3.16.7-29.1, kernel-default-3.16.7-29.1, kernel-desktop-3.16.7-29.1, kernel-docs-3.16.7-29.3, kernel-ec2-3.16.7-29.1, kernel-obs-build-3.16.7-29.2, kernel-obs-qa-3.16.7-29.1, kernel-obs-qa-xen-3.16.7-29.1, kernel-pae-3.16.7-29.1, kernel-source-3.16.7-29.1, kernel-syms-3.16.7-29.1, kernel-vanilla-3.16.7-29.1, kernel-xen-3.16.7-29.1, pcfclock-0.44-260.13.2, vhba-kmp-20140629-2.13.2, xen-4.4.2_06-27.2, xtables-addons-2.6-13.2