Messages in this thread | | | From | Dmitry Vyukov <> | Date | Thu, 13 Sep 2018 10:01:47 +0200 | Subject | Re: [PATCH] selinux: Add __GFP_NOWARN to allocation at str_read() |
| |
On Thu, Sep 13, 2018 at 5:02 AM, Paul Moore <paul@paul-moore.com> wrote: > On Fri, Sep 7, 2018 at 12:43 PM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: >> syzbot is hitting warning at str_read() [1] because len parameter can >> become larger than KMALLOC_MAX_SIZE. We don't need to emit warning for >> this case. >> >> [1] https://syzkaller.appspot.com/bug?id=7f2f5aad79ea8663c296a2eedb81978401a908f0 >> >> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> >> Reported-by: syzbot <syzbot+ac488b9811036cea7ea0@syzkaller.appspotmail.com> >> --- >> security/selinux/ss/policydb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c >> index e9394e7..f4eadd3 100644 >> --- a/security/selinux/ss/policydb.c >> +++ b/security/selinux/ss/policydb.c >> @@ -1101,7 +1101,7 @@ static int str_read(char **strp, gfp_t flags, void *fp, u32 len) >> if ((len == 0) || (len == (u32)-1)) >> return -EINVAL; >> >> - str = kmalloc(len + 1, flags); >> + str = kmalloc(len + 1, flags | __GFP_NOWARN); >> if (!str) >> return -ENOMEM; > > Thanks for the patch. > > My eyes are starting to glaze over a bit chasing down all of the > different kmalloc() code paths trying to ensure that this always does > the right thing based on size of the allocation and the different slab > allocators ... are we sure that this will always return NULL when (len > + 1) is greater than KMALLOC_MAX_SIZE for the different slab allocator > configurations?
Yes, it's the blessed way to do it. We have lots of similar cases: https://elixir.bootlin.com/linux/v4.19-rc3/ident/__GFP_NOWARN
| |