tun/tap: Fix crashes if open() /dev/net/tun and then poll() it. Fix NULL pointer dereference in tun_chr_pool() introduced by commit 33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554 ("tun: Limit amount of queued packets per device") and triggered by this code: int fd; struct pollfd pfd; fd = open("/dev/net/tun", O_RDWR); pfd.fd = fd; pfd.events = POLLIN | POLLOUT; poll(&pfd, 1, 0); Reported-by: Eugene Kapun <abacabadabacaba@gmail.com> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
http://xorl.wordpress.com/2009/07/17/linux-kernel-devnettun-null-pointer-dereference/
This is applicable to >=2.6.30, not <2.6.31. Also, the security impact of the bug is somewhat worse than the summary and severity level suggests. Further information, including a video demonstrating spender's exploit (acquiring a root shell in the process): http://isc.sans.org/diary.html?storyid=6820 http://lists.immunitysec.com/pipermail/dailydave/2009-July/005810.html http://www.youtube.com/watch?v=UdkpJ13e6Z0
Citation regarding the bug's scope: "The commit that introduced the vulnerability (Feb 6th): http://mirror.celinuxforum.org/gitstat/commit-detail.php?commit=33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554 Though it was committed before the release of the 2.6.29 kernel, it did not (thankfully) make it into the 2.6.29 kernel. It first appeared in 2.6.30." That's an excerpt from the (interesting) opening comment in the exploit.c file, from the cheddar_bay tarball.
This bug has galvanised upstream into queueing the following patch for stable, which enables -fno-delete-null-pointer-checks: http://patchwork.kernel.org/patch/36060/
CVE-2009-1897 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1897): The tun_chr_poll function in drivers/net/tun.c in the tun subsystem in the Linux kernel 2.6.30 and 2.6.30.1, when the -fno-delete-null-pointer-checks gcc option is omitted, allows local users to gain privileges via vectors involving a NULL pointer dereference and an mmap of /dev/net/tun, a different vulnerability than CVE-2009-1894.
