| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 Jul 2018 10:36:20 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Manfred Spraul <manfred@...orfullife.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dave@...olabs.net>, 1vier1@....de,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH 2/6] ipc: reorganize initialization of kern_ipc_perm.seq
On Thu, Jul 5, 2018 at 7:59 AM, Manfred Spraul <manfred@...orfullife.com> wrote:
> ipc_addid() initializes kern_ipc_perm.seq after having called
> ipc_idr_alloc().
>
> Thus a parallel semop() or msgrcv() that uses ipc_obtain_object_check()
> may see an uninitialized value.
>
> The patch moves the initialization of kern_ipc_perm.seq before the
> calls of ipc_idr_alloc().
>
> Notes:
> 1) This patch has a user space visible side effect:
> If /proc/sys/kernel/*_next_id is used (i.e.: checkpoint/restore) and
> if semget()/msgget()/shmget() fails in the final step of adding the id
> to the rhash tree, then .._next_id is cleared. Before the patch, is
> remained unmodified.
>
> There is no change of the behavior after a successful ..get() call:
> It always clears .._next_id, there is no impact to non checkpoint/restore
> code as that code does not use .._next_id.
>
> 2) The patch correctly documents that after a call to ipc_idr_alloc(),
> the full tear-down sequence must be used. The callers of ipc_addid()
> do not fullfill that, i.e. more bugfixes are required.
>
> Reported-by: syzbot+2827ef6b3385deb07eaf@...kaller.appspotmail.com
> Signed-off-by: Manfred Spraul <manfred@...orfullife.com>
> Cc: Dmitry Vyukov <dvyukov@...gle.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Davidlohr Bueso <dave@...olabs.net>
> Cc: Michael Kerrisk <mtk.manpages@...il.com>
> Signed-off-by: Manfred Spraul <manfred@...orfullife.com>
> ---
> Documentation/sysctl/kernel.txt | 3 ++-
> ipc/util.c | 45 +++++++++++++++++++++++----------
> 2 files changed, 34 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index eded671d55eb..b2d4a8f8fe97 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -440,7 +440,8 @@ Notes:
> 1) kernel doesn't guarantee, that new object will have desired id. So,
> it's up to userspace, how to handle an object with "wrong" id.
> 2) Toggle with non-default value will be set back to -1 by kernel after
> -successful IPC object allocation.
> +successful IPC object allocation. If an IPC object allocation syscall
> +fails, it is undefined if the value remains unmodified or is reset to -1.
>
> ==============================================================
>
> diff --git a/ipc/util.c b/ipc/util.c
> index 4e81182fa0ac..662c28c6c9fa 100644
> --- a/ipc/util.c
> +++ b/ipc/util.c
> @@ -197,13 +197,24 @@ static struct kern_ipc_perm *ipc_findkey(struct ipc_ids *ids, key_t key)
> /*
> * Specify desired id for next allocated IPC object.
> */
> -#define ipc_idr_alloc(ids, new) \
> - idr_alloc(&(ids)->ipcs_idr, (new), \
> - (ids)->next_id < 0 ? 0 : ipcid_to_idx((ids)->next_id),\
> - 0, GFP_NOWAIT)
> +static inline int ipc_idr_alloc(struct ipc_ids *ids,
> + struct kern_ipc_perm *new)
> +{
> + int key;
>
> -static inline int ipc_buildid(int id, struct ipc_ids *ids,
> - struct kern_ipc_perm *new)
> + if (ids->next_id < 0) {
> + key = idr_alloc(&ids->ipcs_idr, new, 0, 0, GFP_NOWAIT);
> + } else {
> + key = idr_alloc(&ids->ipcs_idr, new,
> + ipcid_to_idx(ids->next_id),
> + 0, GFP_NOWAIT);
> + ids->next_id = -1;
> + }
> + return key;
> +}
> +
> +static inline void ipc_set_seq(struct ipc_ids *ids,
> + struct kern_ipc_perm *new)
> {
> if (ids->next_id < 0) { /* default, behave as !CHECKPOINT_RESTORE */
> new->seq = ids->seq++;
> @@ -211,24 +222,19 @@ static inline int ipc_buildid(int id, struct ipc_ids *ids,
> ids->seq = 0;
> } else {
> new->seq = ipcid_to_seqx(ids->next_id);
> - ids->next_id = -1;
> }
> -
> - return SEQ_MULTIPLIER * new->seq + id;
> }
>
> #else
> #define ipc_idr_alloc(ids, new) \
> idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT)
>
> -static inline int ipc_buildid(int id, struct ipc_ids *ids,
> +static inline void ipc_set_seq(struct ipc_ids *ids,
> struct kern_ipc_perm *new)
> {
> new->seq = ids->seq++;
> if (ids->seq > IPCID_SEQ_MAX)
> ids->seq = 0;
> -
> - return SEQ_MULTIPLIER * new->seq + id;
> }
>
> #endif /* CONFIG_CHECKPOINT_RESTORE */
> @@ -270,6 +276,19 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit)
> new->cuid = new->uid = euid;
> new->gid = new->cgid = egid;
>
> + ipc_set_seq(ids, new);
> +
> + /*
> + * As soon as a new object is inserted into the idr,
> + * ipc_obtain_object_idr() or ipc_obtain_object_check() can find it,
> + * and the lockless preparations for ipc operations can start.
> + * This means especially: permission checks, audit calls, allocation
> + * of undo structures, ...
> + *
> + * Thus the object must be fully initialized, and if something fails,
> + * then the full tear-down sequence must be followed.
> + * (i.e.: set new->deleted, reduce refcount, call_rcu())
> + */
> id = ipc_idr_alloc(ids, new);
> idr_preload_end();
>
> @@ -291,7 +310,7 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit)
> if (id > ids->max_id)
> ids->max_id = id;
>
> - new->id = ipc_buildid(id, ids, new);
> + new->id = SEQ_MULTIPLIER * new->seq + id;
>
> return id;
> }
Hi Manfred,
The series looks like a significant improvement to me. Thanks!
I feel that this code can be further simplified (unless I am missing
something here). Please take a look at this version:
https://github.com/dvyukov/linux/commit/f77aeaf80f3c4ab524db92184d874b03063fea3a?diff=split
This is on top of your patches. It basically does the same as your
code, but consolidates all id/seq assignment and dealing with next_id,
and deduplicates code re CONFIG_CHECKPOINT_RESTORE. Currently it's a
bit tricky to follow e.g. where exactly next_id is consumed and where
it needs to be left intact.
The only difference is that my code assigns new->id earlier. Not sure
if it can lead to anything bad. But if yes, then it seems that
currently uninitialized new->id is exposed. If necessary (?) we could
reset new->id in the same place where we set new->deleted.
Other patches in the series look good to me.
p.s. I've uploaded full context diffs of all patches here:
https://github.com/dvyukov/linux/commits/ipc1
View attachment "ipc.txt" of type "text/plain" (2480 bytes)
Powered by blists - more mailing lists