<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/security, branch v4.9.103</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.103</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.103'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-04-13T17:48:04Z</updated>
<entry>
<title>selinux: do not check open permission on sockets</title>
<updated>2018-04-13T17:48:04Z</updated>
<author>
<name>Stephen Smalley</name>
<email>sds@tycho.nsa.gov</email>
</author>
<published>2017-05-12T16:41:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b983b2a5969c9ee4e2ec73ff3444ec6814441cb8'/>
<id>urn:sha1:b983b2a5969c9ee4e2ec73ff3444ec6814441cb8</id>
<content type='text'>
[ Upstream commit ccb544781d34afdb73a9a73ae53035d824d193bf ]

open permission is currently only defined for files in the kernel
(COMMON_FILE_PERMS rather than COMMON_FILE_SOCK_PERMS). Construction of
an artificial test case that tries to open a socket via /proc/pid/fd will
generate a recvfrom avc denial because recvfrom and open happen to map to
the same permission bit in socket vs file classes.

open of a socket via /proc/pid/fd is not supported by the kernel regardless
and will ultimately return ENXIO. But we hit the permission check first and
can thus produce these odd/misleading denials.  Omit the open check when
operating on a socket.

Signed-off-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selinux: Remove redundant check for unknown labeling behavior</title>
<updated>2018-04-08T10:12:47Z</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2017-05-19T17:09:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1978d829a63177b1cc679da74b5dbddef3264636'/>
<id>urn:sha1:1978d829a63177b1cc679da74b5dbddef3264636</id>
<content type='text'>
commit 270e8573145a26de924e2dc644596332d400445b upstream.

The check is already performed in ocontext_read() when the policy is
loaded. Removing the array also fixes the following warning when
building with clang:

security/selinux/hooks.c:338:20: error: variable 'labeling_behaviors'
    is not needed and will not be emitted
    [-Werror,-Wunneeded-internal-declaration]

Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Acked-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Cc: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: Remove unnecessary check of array base in selinux_set_mapping()</title>
<updated>2018-04-08T10:12:44Z</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2017-03-16T22:26:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=00972acdcf70f21548d9aa7915f7ceacf87dcf05'/>
<id>urn:sha1:00972acdcf70f21548d9aa7915f7ceacf87dcf05</id>
<content type='text'>
commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.

'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.

This fixes the following warning when building with clang:

security/selinux/ss/services.c:158:16: error: address of array
'p_in-&gt;perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
                while (p_in-&gt;perms &amp;&amp; p_in-&gt;perms[k]) {

Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Cc: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ima: relax requiring a file signature for new files with zero length</title>
<updated>2018-03-22T08:17:58Z</updated>
<author>
<name>Mimi Zohar</name>
<email>zohar@linux.vnet.ibm.com</email>
</author>
<published>2017-11-08T12:38:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=27a0856c212bd6a741bf058f3e5aed6964feba87'/>
<id>urn:sha1:27a0856c212bd6a741bf058f3e5aed6964feba87</id>
<content type='text'>
[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]

Custom policies can require file signatures based on LSM labels.  These
files are normally created and only afterwards labeled, requiring them
to be signed.

Instead of requiring file signatures based on LSM labels, entire
filesystems could require file signatures.  In this case, we need the
ability of writing new files without requiring file signatures.

The definition of a "new" file was originally defined as any file with
a length of zero.  Subsequent patches redefined a "new" file to be based
on the FILE_CREATE open flag.  By combining the open flag with a file
size of zero, this patch relaxes the file signature requirement.

Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
Signed-off-by: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>apparmor: Make path_max parameter readonly</title>
<updated>2018-03-22T08:17:48Z</updated>
<author>
<name>John Johansen</name>
<email>john.johansen@canonical.com</email>
</author>
<published>2017-04-06T13:55:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d55a55bc8889f360a686e91fe740048cb7733da6'/>
<id>urn:sha1:d55a55bc8889f360a686e91fe740048cb7733da6</id>
<content type='text'>
[ Upstream commit 622f6e3265707ebf02ba776ac6e68003bcc31213 ]

The path_max parameter determines the max size of buffers allocated
but it should  not be setable at run time. If can be used to cause an
oops

root@ubuntu:~# echo 16777216 &gt; /sys/module/apparmor/parameters/path_max
root@ubuntu:~# cat /sys/module/apparmor/parameters/path_max
Killed

[  122.141911] BUG: unable to handle kernel paging request at ffff880080945fff
[  122.143497] IP: [&lt;ffffffff81228844&gt;] d_absolute_path+0x44/0xa0
[  122.144742] PGD 220c067 PUD 0
[  122.145453] Oops: 0002 [#1] SMP
[  122.146204] Modules linked in: vmw_vsock_vmci_transport vsock ppdev vmw_balloon snd_ens1371 btusb snd_ac97_codec gameport snd_rawmidi btrtl snd_seq_device ac97_bus btbcm btintel snd_pcm input_leds bluetooth snd_timer snd joydev soundcore serio_raw coretemp shpchp nfit parport_pc i2c_piix4 8250_fintek vmw_vmci parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd vmwgfx psmouse mptspi ttm mptscsih drm_kms_helper mptbase syscopyarea scsi_transport_spi sysfillrect
[  122.163365]  ahci sysimgblt e1000 fb_sys_fops libahci drm pata_acpi fjes
[  122.164747] CPU: 3 PID: 1501 Comm: bash Not tainted 4.4.0-59-generic #80-Ubuntu
[  122.166250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[  122.168611] task: ffff88003496aa00 ti: ffff880076474000 task.ti: ffff880076474000
[  122.170018] RIP: 0010:[&lt;ffffffff81228844&gt;]  [&lt;ffffffff81228844&gt;] d_absolute_path+0x44/0xa0
[  122.171525] RSP: 0018:ffff880076477b90  EFLAGS: 00010206
[  122.172462] RAX: ffff880080945fff RBX: 0000000000000000 RCX: 0000000001000000
[  122.173709] RDX: 0000000000ffffff RSI: ffff880080946000 RDI: ffff8800348a1010
[  122.174978] RBP: ffff880076477bb8 R08: ffff880076477c80 R09: 0000000000000000
[  122.176227] R10: 00007ffffffff000 R11: ffff88007f946000 R12: ffff88007f946000
[  122.177496] R13: ffff880076477c80 R14: ffff8800348a1010 R15: ffff8800348a2400
[  122.178745] FS:  00007fd459eb4700(0000) GS:ffff88007b6c0000(0000) knlGS:0000000000000000
[  122.180176] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  122.181186] CR2: ffff880080945fff CR3: 0000000073422000 CR4: 00000000001406e0
[  122.182469] Stack:
[  122.182843]  00ffffff00000001 ffff880080946000 0000000000000000 0000000000000000
[  122.184409]  00000000570f789c ffff880076477c30 ffffffff81385671 ffff88007a2e7a58
[  122.185810]  0000000000000000 ffff880076477c88 01000000008a1000 0000000000000000
[  122.187231] Call Trace:
[  122.187680]  [&lt;ffffffff81385671&gt;] aa_path_name+0x81/0x370
[  122.188637]  [&lt;ffffffff813875dd&gt;] profile_transition+0xbd/0xb80
[  122.190181]  [&lt;ffffffff811af9bc&gt;] ? zone_statistics+0x7c/0xa0
[  122.191674]  [&lt;ffffffff81389b20&gt;] apparmor_bprm_set_creds+0x9b0/0xac0
[  122.193288]  [&lt;ffffffff812e1971&gt;] ? ext4_xattr_get+0x81/0x220
[  122.194793]  [&lt;ffffffff812e800c&gt;] ? ext4_xattr_security_get+0x1c/0x30
[  122.196392]  [&lt;ffffffff813449b9&gt;] ? get_vfs_caps_from_disk+0x69/0x110
[  122.198004]  [&lt;ffffffff81232d4f&gt;] ? mnt_may_suid+0x3f/0x50
[  122.199737]  [&lt;ffffffff81344b03&gt;] ? cap_bprm_set_creds+0xa3/0x600
[  122.201377]  [&lt;ffffffff81346e53&gt;] security_bprm_set_creds+0x33/0x50
[  122.203024]  [&lt;ffffffff81214ce5&gt;] prepare_binprm+0x85/0x190
[  122.204515]  [&lt;ffffffff81216545&gt;] do_execveat_common.isra.33+0x485/0x710
[  122.206200]  [&lt;ffffffff81216a6a&gt;] SyS_execve+0x3a/0x50
[  122.207615]  [&lt;ffffffff81838795&gt;] stub_execve+0x5/0x5
[  122.208978]  [&lt;ffffffff818384f2&gt;] ? entry_SYSCALL_64_fastpath+0x16/0x71
[  122.210615] Code: f8 31 c0 48 63 c2 83 ea 01 48 c7 45 e8 00 00 00 00 48 01 c6 85 d2 48 c7 45 f0 00 00 00 00 48 89 75 e0 89 55 dc 78 0c 48 8d 46 ff &lt;c6&gt; 46 ff 00 48 89 45 e0 48 8d 55 e0 48 8d 4d dc 48 8d 75 e8 e8
[  122.217320] RIP  [&lt;ffffffff81228844&gt;] d_absolute_path+0x44/0xa0
[  122.218860]  RSP &lt;ffff880076477b90&gt;
[  122.219919] CR2: ffff880080945fff
[  122.220936] ---[ end trace 506cdbd85eb6c55e ]---

Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: John Johansen &lt;john.johansen@canonical.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selinux: check for address length in selinux_socket_bind()</title>
<updated>2018-03-22T08:17:38Z</updated>
<author>
<name>Alexander Potapenko</name>
<email>glider@google.com</email>
</author>
<published>2017-03-06T18:46:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b243aa88a72263289f962844e8665157a53669d1'/>
<id>urn:sha1:b243aa88a72263289f962844e8665157a53669d1</id>
<content type='text'>
[ Upstream commit e2f586bd83177d22072b275edd4b8b872daba924 ]

KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
uninitialized memory in selinux_socket_bind():

==================================================================
BUG: KMSAN: use of unitialized memory
inter: 0
CPU: 3 PID: 1074 Comm: packet2 Tainted: G    B           4.8.0-rc6+ #1916
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 0000000000000000 ffff8800882ffb08 ffffffff825759c8 ffff8800882ffa48
 ffffffff818bf551 ffffffff85bab870 0000000000000092 ffffffff85bab550
 0000000000000000 0000000000000092 00000000bb0009bb 0000000000000002
Call Trace:
 [&lt;     inline     &gt;] __dump_stack lib/dump_stack.c:15
 [&lt;ffffffff825759c8&gt;] dump_stack+0x238/0x290 lib/dump_stack.c:51
 [&lt;ffffffff818bdee6&gt;] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
 [&lt;ffffffff818bf0fb&gt;] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
 [&lt;ffffffff822dae71&gt;] selinux_socket_bind+0xf41/0x1080 security/selinux/hooks.c:4288
 [&lt;ffffffff8229357c&gt;] security_socket_bind+0x1ec/0x240 security/security.c:1240
 [&lt;ffffffff84265d98&gt;] SYSC_bind+0x358/0x5f0 net/socket.c:1366
 [&lt;ffffffff84265a22&gt;] SyS_bind+0x82/0xa0 net/socket.c:1356
 [&lt;ffffffff81005678&gt;] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
 [&lt;ffffffff8518217c&gt;] entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.o:?
chained origin: 00000000ba6009bb
 [&lt;ffffffff810bb7a7&gt;] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
 [&lt;     inline     &gt;] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
 [&lt;     inline     &gt;] kmsan_save_stack mm/kmsan/kmsan.c:337
 [&lt;ffffffff818bd2b8&gt;] kmsan_internal_chain_origin+0x118/0x1e0 mm/kmsan/kmsan.c:530
 [&lt;ffffffff818bf033&gt;] __msan_set_alloca_origin4+0xc3/0x130 mm/kmsan/kmsan_instr.c:380
 [&lt;ffffffff84265b69&gt;] SYSC_bind+0x129/0x5f0 net/socket.c:1356
 [&lt;ffffffff84265a22&gt;] SyS_bind+0x82/0xa0 net/socket.c:1356
 [&lt;ffffffff81005678&gt;] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
 [&lt;ffffffff8518217c&gt;] return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.o:?
origin description: ----address@SYSC_bind (origin=00000000b8c00900)
==================================================================

(the line numbers are relative to 4.8-rc6, but the bug persists upstream)

, when I run the following program as root:

=======================================================
  #include &lt;string.h&gt;
  #include &lt;sys/socket.h&gt;
  #include &lt;netinet/in.h&gt;

  int main(int argc, char *argv[]) {
    struct sockaddr addr;
    int size = 0;
    if (argc &gt; 1) {
      size = atoi(argv[1]);
    }
    memset(&amp;addr, 0, sizeof(addr));
    int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
    bind(fd, &amp;addr, size);
    return 0;
  }
=======================================================

(for different values of |size| other error reports are printed).

This happens because bind() unconditionally copies |size| bytes of
|addr| to the kernel, leaving the rest uninitialized. Then
security_socket_bind() reads the IP address bytes, including the
uninitialized ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.

Signed-off-by: Alexander Potapenko &lt;glider@google.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
[PM: fixed some whitespace damage]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>security/keys: BIG_KEY requires CONFIG_CRYPTO</title>
<updated>2018-02-25T10:05:53Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-10-04T10:27:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=077463be4fd5ec4ea2eb2101074893498a152066'/>
<id>urn:sha1:077463be4fd5ec4ea2eb2101074893498a152066</id>
<content type='text'>
commit 3cd18d1981731d5f74b8e437009124ac99905d14 upstream.

The recent rework introduced a possible randconfig build failure
when CONFIG_CRYPTO configured to only allow modules:

security/keys/big_key.o: In function `big_key_crypt':
big_key.c:(.text+0x29f): undefined reference to `crypto_aead_setkey'
security/keys/big_key.o: In function `big_key_init':
big_key.c:(.init.text+0x1a): undefined reference to `crypto_alloc_aead'
big_key.c:(.init.text+0x45): undefined reference to `crypto_aead_setauthsize'
big_key.c:(.init.text+0x77): undefined reference to `crypto_destroy_tfm'
crypto/gcm.o: In function `gcm_hash_crypt_remain_continue':
gcm.c:(.text+0x167): undefined reference to `crypto_ahash_finup'
crypto/gcm.o: In function `crypto_gcm_exit_tfm':
gcm.c:(.text+0x847): undefined reference to `crypto_destroy_tfm'

When we 'select CRYPTO' like the other users, we always get a
configuration that builds.

Fixes: 428490e38b2e ("security/keys: rewrite all of big_key crypto")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: skip bounded transition processing if the policy isn't loaded</title>
<updated>2018-02-25T10:05:42Z</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2017-12-05T22:17:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5e6f51aac15ac93605187fd11b9bc75a240a53f8'/>
<id>urn:sha1:5e6f51aac15ac93605187fd11b9bc75a240a53f8</id>
<content type='text'>
commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.

We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy.  Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.

Reported-by: syzbot &lt;syzkaller-bugs@googlegroups.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Acked-by: Stephen Smalley &lt;sds@tycho.nsa.gov&gt;
Reviewed-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>selinux: ensure the context is NUL terminated in security_context_to_sid_core()</title>
<updated>2018-02-25T10:05:41Z</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2017-11-28T23:51:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fe1cb580e84865f3c6be99b952a626323228e781'/>
<id>urn:sha1:fe1cb580e84865f3c6be99b952a626323228e781</id>
<content type='text'>
commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.

The syzbot/syzkaller automated tests found a problem in
security_context_to_sid_core() during early boot (before we load the
SELinux policy) where we could potentially feed context strings without
NUL terminators into the strcmp() function.

We already guard against this during normal operation (after the SELinux
policy has been loaded) by making a copy of the context strings and
explicitly adding a NUL terminator to the end.  The patch extends this
protection to the early boot case (no loaded policy) by moving the context
copy earlier in security_context_to_sid_core().

Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Reviewed-By: William Roberts &lt;william.c.roberts@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KEYS: encrypted: fix buffer overread in valid_master_desc()</title>
<updated>2018-02-13T11:35:57Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2017-06-08T13:48:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9692602ab850eec484d8cc5a740803d34f00016c'/>
<id>urn:sha1:9692602ab850eec484d8cc5a740803d34f00016c</id>
<content type='text'>
commit 794b4bc292f5d31739d89c0202c54e7dc9bc3add upstream.

With the 'encrypted' key type it was possible for userspace to provide a
data blob ending with a master key description shorter than expected,
e.g. 'keyctl add encrypted desc "new x" @s'.  When validating such a
master key description, validate_master_desc() could read beyond the end
of the buffer.  Fix this by using strncmp() instead of memcmp().  [Also
clean up the code to deduplicate some logic.]

Cc: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Jin Qian &lt;jinqian@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
