linux-kernel - Re: [PATCH] initramfs: forcing panic when kstrdup failed

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, 10 Dec 2019 16:52:00 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     zhanglin <zhang.lin16@....com.cn>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Steven Price <steven.price@....com>, david.engraf@...go.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        xue.zhihong@....com.cn, wang.yi59@....com.cn,
        jiang.xuexin@....com.cn
Subject: Re: [PATCH] initramfs: forcing panic when kstrdup failed

On Tue, 10 Dec 2019 09:15:54 +0100 Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> > --- a/init/initramfs.c
> > +++ b/init/initramfs.c
> > @@ -125,6 +125,8 @@ static void __init dir_add(const char *name, time64_t mtime)
> >                 panic("can't allocate dir_entry buffer");
> >         INIT_LIST_HEAD(&de->list);
> >         de->name = kstrdup(name, GFP_KERNEL);
> > +       if (!de->name)
> > +               panic("can't allocate dir_entry.name buffer");
> >         de->mtime = mtime;
> >         list_add(&de->list, &dir_list);
> >  }
> > @@ -340,6 +342,8 @@ static int __init do_name(void)
> >                                 if (body_len)
> >                                         ksys_ftruncate(wfd, body_len);
> >                                 vcollected = kstrdup(collected, GFP_KERNEL);
> > +                               if (!vcollected)
> > +                                       panic("can not allocate vcollected buffer.");
> >                                 state = CopyFile;
> >                         }
> >                 }
> 
> Do we really need to add more messages for out-of-memory conditions?
> The trend is to remove the printing of those messages, as the memory
> allocation subsystem will have printed a backtrace already anyway.

Yup.  And we traditionally assume that memory allocations won't fail at
init time anyway.  The reasoning being that the system is so enormously
messed up that the problem is both unrecoverable and very obvious.