linux-kernel - Re: yama_ptrace_access_check(): possible recursive locking detected

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: <1345041021.31459.88.camel@twins>
Date:	Wed, 15 Aug 2012 16:30:21 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Kees Cook <keescook@...omium.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: yama_ptrace_access_check(): possible recursive locking detected

On Wed, 2012-08-15 at 15:01 +0200, Oleg Nesterov wrote:
> BTW, set_task_comm()->wmb() and memset() should die. There are
> not needed afaics, and the comment is misleading. 

As long as we guarantee there's always a terminating '\0', now strlcpy()
doesn't pad the result, however if we initialize the ->comm to all 0s in
fork() or thereabouts, we should get this guarantee from the strlcpy()
since that will never replace the last byte with anything but 0.

That barrier is indeed completely pointless as there's no pairing
barrier anywhere.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/