In dir_add() and do_name(), de->name and vcollected are allocated by
kstrdup(). And de->name and vcollected are dereferenced in the following
codes. However, memory allocation functions such as kstrdup() may fail.
Dereferencing this null pointer may cause the kernel go wrong. Thus we
should check these two kstrdup() operations.
Further, if kstrdup() returns NULL, we should free de in dir_add().
Signed-off-by: Gen Zhang <[email protected]>
---
diff --git a/init/initramfs.c b/init/initramfs.c
index 178130f..1421488 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -125,6 +125,10 @@ 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) {
+ kfree(de);
+ panic("can't allocate dir_entry name buffer");
+ }
de->mtime = mtime;
list_add(&de->list, &dir_list);
}
@@ -340,6 +344,10 @@ static int __init do_name(void)
if (body_len)
ksys_ftruncate(wfd, body_len);
vcollected = kstrdup(collected, GFP_KERNEL);
+ if (!vcollected) {
+ panic("can't allocate vcollected buffer");
+ return 0;
+ }
state = CopyFile;
}
}
On Fri, 24 May 2019 11:30:45 +0800 Gen Zhang <[email protected]> wrote:
> In dir_add() and do_name(), de->name and vcollected are allocated by
> kstrdup(). And de->name and vcollected are dereferenced in the following
> codes. However, memory allocation functions such as kstrdup() may fail.
> Dereferencing this null pointer may cause the kernel go wrong. Thus we
> should check these two kstrdup() operations.
> Further, if kstrdup() returns NULL, we should free de in dir_add().
We generally assume that memory allocations within __init code cannot
fail. If one does fail, something quite horrid has happened. The
resulting oops will provide the same information as the proposed panic()
anyway.
On Thu, May 23, 2019 at 08:35:23PM -0700, Andrew Morton wrote:
> On Fri, 24 May 2019 11:30:45 +0800 Gen Zhang <[email protected]> wrote:
>
> > In dir_add() and do_name(), de->name and vcollected are allocated by
> > kstrdup(). And de->name and vcollected are dereferenced in the following
> > codes. However, memory allocation functions such as kstrdup() may fail.
> > Dereferencing this null pointer may cause the kernel go wrong. Thus we
> > should check these two kstrdup() operations.
> > Further, if kstrdup() returns NULL, we should free de in dir_add().
>
> We generally assume that memory allocations within __init code cannot
> fail. If one does fail, something quite horrid has happened. The
> resulting oops will provide the same information as the proposed panic()
> anyway.
Thanks for your reply, Andrew.
You mean that it is not necessary to check memory allcoation in __init,
right?
Thanks
Gen