Bugzilla – Bug 948536
VUL-0: CVE-2015-7613: kernel: Unauthorized access to IPC objects with SysV shm
Last modified: 2022-02-13 11:07:38 UTC
Created attachment 649871 [details] https://github.com/torvalds/linux/commit/b9a532277938798b53178d5a66af6e2915cb27cf from http://seclists.org/oss-sec/2015/q4/6 While working on KernelThreadSanitizer (KTSAN), a data race detector for kernels, Dmitry Vyukov found a data race that can trick the kernel into using unitialized memory. - This can at least give access to arbitrary SysV shared memory and Dmitry developed a proof of concept exploit for this. (On many systems, this can be used to escalate privileges). - While we didn't investigate this deeply, it is almost certain that this vulnerability can be used to gain arbitrary code execution in the kernel. Exercise left to the reader. This vulnerability has been fixed upstream by Linus with this commit: https://github.com/torvalds/linux/commit/b9a532277938798b53178d5a66af6e2915cb27cf From Dmitry Vyukov: ----------- While working on KernelThreadSanitizer (KTSAN), a data race detector for kernel, I've got a report that says that ipc_addid() installs a not-completely initialized object into the shared object table. In particular, uid/gid are not initialized. ipc_obtain_object_check() in turn obtains the object and verifies uid/gid for permission purposes. Since the fields are not initialized, the check can falsely succeed. Below are details including a proof-of-concept exploit. Here is the race report on 4.2 kernel: ThreadSanitizer: data-race in ipc_obtain_object_check Read at 0xffff88047f810f68 of size 8 by thread 2749 on CPU 5: [<ffffffff8147d84d>] ipc_obtain_object_check+0x7d/0xd0 ipc/util.c:621 [< inline >] msq_obtain_object_check ipc/msg.c:90 [<ffffffff8147e708>] msgctl_nolock.constprop.9+0x208/0x430 ipc/msg.c:480 [< inline >] SYSC_msgctl ipc/msg.c:538 [<ffffffff8147f061>] SyS_msgctl+0xa1/0xb0 ipc/msg.c:522 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188 Previous write at 0xffff88047f810f68 of size 8 by thread 2755 on CPU 4: [<ffffffff8147cf97>] ipc_addid+0x217/0x260 ipc/util.c:257 [<ffffffff8147eb4c>] newque+0xac/0x240 ipc/msg.c:141 [< inline >] ipcget_public ipc/util.c:355 [<ffffffff8147daa2>] ipcget+0x202/0x280 ipc/util.c:646 [< inline >] SYSC_msgget ipc/msg.c:255 [<ffffffff8147efaa>] SyS_msgget+0x7a/0x90 ipc/msg.c:241 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188 Mutexes locked by thread 2755: Mutex 445417 is locked here: [<ffffffff81ee0d45>] down_write+0x65/0x80 kernel/locking/rwsem.c:62 [< inline >] ipcget_public ipc/util.c:348 [<ffffffff8147d90c>] ipcget+0x6c/0x280 ipc/util.c:646 [< inline >] SYSC_msgget ipc/msg.c:255 [<ffffffff8147efaa>] SyS_msgget+0x7a/0x90 ipc/msg.c:241 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188 Mutex 453634 is locked here: [< inline >] __raw_spin_lock include/linux/spinlock_api_smp.h:158 [<ffffffff81ee37d0>] _raw_spin_lock+0x50/0x70 kernel/locking/spinlock.c:151 [< inline >] spin_lock include/linux/spinlock.h:312 [<ffffffff8147ce0e>] ipc_addid+0x8e/0x260 ipc/util.c:238 [<ffffffff8147eb4c>] newque+0xac/0x240 ipc/msg.c:141 [< inline >] ipcget_public ipc/util.c:355 [<ffffffff8147daa2>] ipcget+0x202/0x280 ipc/util.c:646 [< inline >] SYSC_msgget ipc/msg.c:255 [<ffffffff8147efaa>] SyS_msgget+0x7a/0x90 ipc/msg.c:241 [<ffffffff81ee3e11>] entry_SYSCALL_64_fastpath+0x31/0x95 arch/x86/entry/entry_64.S:188 What happens is as follows. ipc_addid installs new ipc object with idr_alloc, from this point on it is accessible to other threads. At this point the object contains unitialized garbage. Then it fills in uid, etc: new->cuid = new->uid = euid; new->gid = new->cgid = egid; new->seq = ids->seq++; While this happens another thread can get access to the object and do uid check on the unitialized garbage, which can give falsely give accesses to the shared object to a process that should not have access to the object. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7613 http://seclists.org/oss-sec/2015/q4/7
Commit b9a532277938798b53178d5a66af6e2915cb27cf contains a reference to... > We already did this for the IPC semaphore code (see commit e8577d1f0329: > "ipc/sem.c: fully initialize sem_array before making it visible") but we > clearly forgot about msg and shm. > From e8577d1f0329d4842e8302e289fb2c22156abef4 Mon Sep 17 00:00:00 2001 > From: Manfred Spraul <manfred@colorfullife.com> > Date: Tue, 2 Dec 2014 15:59:34 -0800 > Subject: [PATCH] ipc/sem.c: fully initialize sem_array before making it > visible > > ipc_addid() makes a new ipc identifier visible to everyone. New objects > start as locked, so that the caller can complete the initialization > after the call. Within struct sem_array, at least sma->sem_base and > sma->sem_nsems are accessed without any locks, therefore this approach > doesn't work. > > Thus: Move the ipc_addid() to the end of the initialization. which we may want to include.
bugbot adjusting priority
commit e8577d1f0329 ("ipc/sem.c: fully initialize sem_array before making it visible") is already in SLE12 as part of v3.12.40.
I have a backport of b9a532277938 ("Initialize msg/shm IPC objects before doing ipc_addid()") in users/mmarek/SLE12/bsc948536.
(In reply to Davidlohr Bueso from comment #9) > Backport looks good, I'll update the rest of the branches. So actually SLE12 is the only version that uses the lockless ipc object lookups and security checks, such as ipc_obtain_object_check(). This means that older versions (SLE11) are not exposed to the half initialized data structures as the object is never visible. Thus having ipc_addid() not be at the end of the initialization process is safe as we always serialize against the ipc object lock. In fact Linus mentions this in the changelog: "" Yes, we initialize the IPC object in a locked state, but with all the lockless RCU lookup work, that IPC object lock no longer means that the state cannot be seen. "" Technically there is nothing wrong with doing the backport, as both approaches are correct; but I don't see any strong benefits.
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
SUSE-SU-2015:2084-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_5-3-2.1
SUSE-SU-2015:2085-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_4-3-2.1
SUSE-SU-2015:2086-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_7-2-4.1
SUSE-SU-2015:2087-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_6-2-2.1
SUSE-SU-2015:2089-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_1-4-2.3
SUSE-SU-2015:2090-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_3-3-2.1
SUSE-SU-2015:2091-1: An update that solves two vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 940338,940342,948536,948701 CVE References: CVE-2015-5707,CVE-2015-7613 Sources used: SUSE Linux Enterprise Live Patching 12 (src): kgraft-patch-SLE12_Update_2-4-2.3
This issue does not affect the older products, as they do not use lockless ipc object access.