From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752418AbdLEWCB (ORCPT ); Tue, 5 Dec 2017 17:02:01 -0500 Received: from merlin.infradead.org ([205.233.59.134]:41512 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751066AbdLEWB4 (ORCPT ); Tue, 5 Dec 2017 17:01:56 -0500 Date: Tue, 5 Dec 2017 23:01:36 +0100 From: Peter Zijlstra To: Arnd Bergmann Cc: Kees Cook , Mark Fasheh , Joel Becker , Andrew Morton , Ingo Molnar , Joseph Qi , piaojun , ocfs2-devel@oss.oracle.com, LKML Subject: Re: [PATCH] ocfs2: use get_task_comm Message-ID: <20171205220136.GW3165@worktop.lehotels.local> References: <20171205152110.2050975-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 05, 2017 at 10:44:17PM +0100, Arnd Bergmann wrote: > On Tue, Dec 5, 2017 at 9:32 PM, Kees Cook wrote: > > On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann 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.