linux-kernel - Re: kstrdup_quotable

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]

Date:   Tue, 6 Nov 2018 09:22:21 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Kees Cook <keescook@...omium.org>,
        Jordan Crouse <jcrouse@...eaurora.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: kstrdup_quotable_cmdline and gfp flags

On Mon 05-11-18 22:32:07, Rasmus Villemoes wrote:
> kstrdup_quotable_cmdline takes gfp flags and passes those on to
> kstrdup_quotable, but before that it has done a kmalloc(PAGE_SIZE) with
> a hard-coded GFP_KERNEL. There is one caller of kstrdup_quotable_cmdline
> which passes GFP_ATOMIC, and the commit introducing that (65a3c2748e)
> conveniently has this piece of history:
> 
>     v2: Use GFP_ATOMIC while holding the rcu lock per Chris Wilson
> 
> So, should the GFP_KERNEL in kstrdup_quotable_cmdline simply be changed
> to use the passed-in gfp, or is there some deeper reason for the
> GFP_KERNEL (in which case it doesn't really make sense to take gfp at
> all...)?

I would just drop the gfp argument and move comm = kstrdup(task->comm, GFP_ATOMIC);
before rcu read lock

The code in its current form is buggy.
-- 
Michal Hocko
SUSE Labs