linux-kernel - Re: [PATCH 01/12] ipc: reorganize initialization of kern_ipc

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180710220830.pvdvq7aovja5nrmf@linux-r8p5>
Date:   Tue, 10 Jul 2018 15:08:30 -0700
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Manfred Spraul <manfred@...orfullife.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>, 1vier1@....de,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 01/12] ipc: reorganize initialization of kern_ipc_perm.id

On Mon, 09 Jul 2018, Manfred Spraul wrote:

>ipc_addid() initializes kern_ipc_perm.id after having called
>ipc_idr_alloc().
>
>Thus a parallel semop() or msgrcv() that uses ipc_obtain_object_idr()
>may see an uninitialized value.
>
>The patch moves all accesses to kern_ipc_perm.id under the spin_lock().

Yeah this is a lot better than my kzalloc() idea. I was considering
completions to avoid these races with ->getnew(), but careful init beats
that idea for obvious reasons.

The only thing I would say is that the title should be more descriptive.
Unlike the next patch, this one isn't really reorganizing anything.
How about:

  ipc: compute kern_ipc_perm.id under the ipc lock for stat cmds

>
>The issues is related to the finding of
>syzbot+2827ef6b3385deb07eaf@...kaller.appspotmail.com:
>syzbot found an issue with kern_ipc_perm.seq
>
>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>

Reviewed-by: Davidlohr Bueso <dbueso@...e.de>