linux-kernel - Re: [PATCH] ocfs2: use get_task

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] [day] [month] [year] [list]

Message-ID: <20171205220136.GW3165@worktop.lehotels.local>
Date:   Tue, 5 Dec 2017 23:01:36 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Kees Cook <keescook@...omium.org>,
        Mark Fasheh <mfasheh@...sity.com>,
        Joel Becker <jlbec@...lplan.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Joseph Qi <jiangqi903@...il.com>, piaojun <piaojun@...wei.com>,
        ocfs2-devel@....oracle.com, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ocfs2: use get_task_comm

On Tue, Dec 05, 2017 at 10:44:17PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 5, 2017 at 9:32 PM, Kees Cook <keescook@...omium.org> wrote:
> > On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >>
> >> More generally speaking though, how exactly do we guarantee that
> >> there is NUL-termination on tsk->comm during a concurrent update?
> >> Could we ever get into a situation where overwrite the NUL byte
> >> while setting tsk->comm to a longer string, and read the new start
> >> of the string together with an unterminated end, or do we strictly
> >> guarantee that the last byte is still NUL? I assume the latter is
> >> true, just haven't found exactly where that guarantee is made.
> >
> > strncpy will zero pad with the trailing NULL, so it's supposed to
> > always be safe... still gives me the creeps, though.
> 
> But set_task_comm uses strlcpy(), not strncpy(), so you might
> get some of the old data back, the question is just whether it could
> leak uninitialized data or part of the task_struct up to the next
> NUL byte. I could not come up with any code path that would leave
> a non-NUL byte in at the end of task->comm though, so it's
> probably still safe.

So we used to have some magic code set_task_comm() which even included a
memory barrier etc.. But since none of the reading sites include a
memory barrier its all pointless.

There is no guarantee that a tsk->comm user reads the bytes in string
order.

The only thing that ensures we never run over, is the hard guarantee
that ->comm[TSK_COMM_LEN-1] == 0 at all times. If we don't trust
str*cpy() to do the right thing here, we could simply open code the
thing.