public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: P J P <ppandit@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs
Date: Sun, 15 Sep 2013 14:33:53 +0530 (IST)	[thread overview]
Message-ID: <alpine.LFD.2.03.1309151431180.7830@erqung.pbz> (raw)

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1091 bytes --]

   Hello,

While building the 3.11 kernel recently, I bumped into this issue.

Menuconfig allows one to choose compression format of an initial ramdisk 
image. If we select any compression other than the default gzip(1), it leads 
to a NULL pointer dereference while loading the initramfs image, at boot up.

Because - $ make install - does not pass on the selected compression format to 
dracut(8) tool, it generates the initramfs file compressed with the default 
gzip(1) format. But the kernel knows only to decompress the chosen format.

The attached patch herein, replaces the crash by an explicit panic() call with 
an appropriate error message. It keeps the kernel from eventually panicking in 
init/do_mounts.c: mount_root_block() with an inaccurate error message and 
which also looses the earlier printk output that hints about the missing 
gzip(1) decompression support.
   -> panic("VFS: Unable to mount root fs on %s", b);

Could someone please review this patch?

Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB  C939 D048 7860 3655 602B

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1832 bytes --]

From 4ff1ddae358dff002080d753e45721a89d07b3af Mon Sep 17 00:00:00 2001
From: P J P <prasad@redhat.com>
Date: Sun, 15 Sep 2013 13:03:17 +0530
Subject: [PATCH 1/2] NULL pointer dereference while loading initramfs

Make menuconfig allows one to choose compression format of an
initial ramdisk image. But this choice does not result in duly
compressed initial ramdisk image. Because - $ make install - does
not pass on the selected compression choice to the dracut(8) tool,
which creates the initramfs file. dracut(8) generates the image
with the default compression, ie. gzip(1).

If a user chose any other compression instead of gzip(1), it leads
to a crash due to NULL pointer dereference in crd_load(), caused by
a NULL function pointer returned by the 'decompress_method()' routine.
Because the initramfs image is gzip(1) compressed, whereas the kernel
knows how decompress the chosen format and not gzip(1).

This patch replaces the crash by an explicit panic() call with an
appropriate error message. This shall prevent the kernel from
eventually panicking in: init/do_mounts.c: mount_block_root() with
  -> panic("VFS: Unable to mount root fs on %s", b);

Signed-off-by: P J P <prasad@redhat.com>

diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index 6be2879..76faec1 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -342,6 +342,13 @@ static int __init crd_load(int in_fd, int out_fd, decompress_fn deco)
 	int result;
 	crd_infd = in_fd;
 	crd_outfd = out_fd;
+
+    if (!deco)
+    {
+        printk(KERN_EMERG "Invalid decompression routine address: %p\n", deco);
+        panic("Could not decompress initial ramdisk image.");
+    }
+
 	result = deco(NULL, 0, compr_fill, compr_flush, NULL, NULL, error);
 	if (decompress_error)
 		result = 1;
-- 
1.8.3.1


             reply	other threads:[~2013-09-15  9:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-15  9:03 P J P [this message]
2013-09-23 19:41 ` [PATCH 1/2] Fix NULL pointer dereference while loading initramfs Andrew Morton
2013-09-24  1:38   ` Rob Landley
2013-09-24 19:01     ` P J P
2013-09-24 18:45   ` P J P
2013-09-30 21:43   ` P J P
2013-10-05 20:42   ` P J P
2013-10-05 21:28     ` Andrew Morton
2013-10-06  8:09       ` P J P

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.03.1309151431180.7830@erqung.pbz \
    --to=ppandit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox