linux-kernel - A bug in read operation for /dev/zero and a proposed fix.

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-next>] [day] [month] [year] [list]

Date:	Thu, 4 Jun 2009 13:32:55 -0700 (PDT)
From:	Salman Qazi <sqazi@...gle.com>
To:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: A bug in read operation for /dev/zero and a proposed fix.

While running 20 parallel instances of dd as follows:

#!/bin/bash

for i in `seq 1 20`; do
         dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 &
done
wait

on a 16G machine, we noticed that rather than just killing the
processes, the entire kernel went down.  Stracing dd reveals that it first
does an mmap2, which makes 1GB worth of zero page mappings.  Then it 
performs
a read on those pages from /dev/zero, and finally it performs a write. 
The
machine died during the reads.  Looking at the code, it was noticed that
/dev/zero's read operation had been changed at some point from giving
zero page mappings to actually zeroing the page.  The zeroing of the
pages causes physical pages to be allocated to the process.  But, when
the process exhausts all the memory that it can, the kernel cannot kill
it, as it is still in the kernel mode allocating more memory. 
Consequently,
the kernel eventually crashes.

To fix this, I propose that when a fatal signal is pending during
/dev/zero read operation, we simply return and let the user process die.
Here is a patch that does that.

Signed-off-by: Salman Qazi <sqazi@...gle.com>
---
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 8f05c38..2ffa36e 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -696,6 +696,11 @@ static ssize_t read_zero(struct file * file, char __user * buf,
  			break;
  		buf += chunk;
  		count -= chunk;
+		/* The exit code here doesn't actually matter, as userland
+		 * will never see it.
+		 */
+		if (fatal_signal_pending(current))
+			return -ENOMEM;
  		cond_resched();
  	}
  	return written ? written : -EFAULT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/