kernel, branch linux-2.6.33.y

Linux 2.6.33.20

2011-11-07T22:19:03Z

ext2,ext3,ext4: don't inherit APPEND_FL or IMMUTABLE_FL for new inodes

2011-11-07T21:47:44Z

commit 1cd9f0976aa4606db8d6e3dc3edd0aca8019372a upstream. This doesn't make much sense, and it exposes a bug in the kernel where attempts to create a new file in an append-only directory using O_CREAT will fail (but still leave a zero-length file). This was discovered when xfstests #79 was generalized so it could run on all file systems. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman

drivers/net/rionet.c: fix ethernet address macros for LE platforms

2011-11-07T21:47:42Z

commit e0c87bd95e8dad455c23bc56513af8dcb1737e55 upstream. Modify Ethernet addess macros to be compatible with BE/LE platforms Signed-off-by: Alexandre Bounine Cc: Chul Kim Cc: Kumar Gala Cc: Matt Porter Cc: Li Yang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ext4: fix BUG_ON() in ext4_ext_insert_extent()

2011-11-07T21:47:42Z

Does not corrispond with a direct commit in Linus's tree as it was fixed differently in the 3.0 release. We will meet with a BUG_ON() if following script is run. mkfs.ext4 -b 4096 /dev/sdb1 1000000 mount -t ext4 /dev/sdb1 /mnt/sdb1 fallocate -l 100M /mnt/sdb1/test sync for((i=0;i<170;i++)) do dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=`expr $i \* 2` done umount /mnt/sdb1 mount -t ext4 /dev/sdb1 /mnt/sdb1 dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=341 umount /mnt/sdb1 mount /dev/sdb1 /mnt/sdb1 dd if=/dev/zero of=/mnt/sdb1/test conv=notrunc bs=256k count=1 seek=340 sync The reason is that it forgot to mark dirty when splitting two extents in ext4_ext_convert_to_initialized(). Althrough ex has been updated in memory, it is not dirtied both in ext4_ext_convert_to_initialized() and ext4_ext_insert_extent(). The disk layout is corrupted. Then it will meet with a BUG_ON() when writting at the start of that extent again. Cc: "Theodore Ts'o" Cc: Xiaoyun Mao Cc: Yingbin Wang Cc: Jia Wan Signed-off-by: Zheng Liu Signed-off-by: Greg Kroah-Hartman

net_sched: Fix qdisc_notify()

2011-11-07T21:47:41Z

commit 53b0f08042f04813cd1a7473dacd3edfacb28eb3 upstream. Ben Pfaff reported a kernel oops and provided a test program to reproduce it. https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805 tc_fill_qdisc() should not be called for builtin qdisc, or it dereference a NULL pointer to get device ifindex. Fix is to always use tc_qdisc_dump_ignore() before calling tc_fill_qdisc(). Reported-by: Ben Pfaff Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

nl80211: fix overflow in ssid_len

2011-11-07T21:47:40Z

commit 57a27e1d6a3bb9ad4efeebd3a8c71156d6207536 upstream. When one of the SSID's length passed in a scan or sched_scan request is larger than 255, there will be an overflow in the u8 that is used to store the length before checking. This causes the check to fail and we overrun the buffer when copying the SSID. Fix this by checking the nl80211 attribute length before copying it to the struct. This is a follow up for the previous commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem entirely. Reported-by: Ido Yariv Signed-off-by: Luciano Coelho Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

Bluetooth: Prevent buffer overflow in l2cap config request

2011-11-07T21:47:40Z

commit 7ac28817536797fd40e9646452183606f9e17f71 upstream. A remote user can provide a small value for the command size field in the command header of an l2cap configuration request, resulting in an integer underflow when subtracting the size of the configuration request header. This results in copying a very large amount of data via memcpy() and destroying the kernel heap. Check for underflow. Signed-off-by: Dan Rosenberg Signed-off-by: Gustavo F. Padovan Signed-off-by: Greg Kroah-Hartman

vm: fix vm_pgoff wrap in upward expansion

2011-11-07T21:47:39Z

commit 42c36f63ac1366ab0ecc2d5717821362c259f517 upstream. Commit a626ca6a6564 ("vm: fix vm_pgoff wrap in stack expansion") fixed the case of an expanding mapping causing vm_pgoff wrapping when you had downward stack expansion. But there was another case where IA64 and PA-RISC expand mappings: upward expansion. This fixes that case too. Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

vm: fix vm_pgoff wrap in stack expansion

2011-11-07T21:47:39Z

commit a626ca6a656450e9f4df91d0dda238fff23285f4 upstream. Commit 982134ba6261 ("mm: avoid wrapping vm_pgoff in mremap()") fixed the case of a expanding mapping causing vm_pgoff wrapping when you used mremap. But there was another case where we expand mappings hiding in plain sight: the automatic stack expansion. This fixes that case too. This one also found by Robert Święcki, using his nasty system call fuzzer tool. Good job. Reported-and-tested-by: Robert Święcki Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.

2011-11-07T21:47:38Z

commit 8d03e971cf403305217b8e62db3a2e5ad2d6263f upstream. Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding byte each. This byte in "cinfo" is copied to userspace uninitialized. Signed-off-by: Filip Palian Acked-by: Marcel Holtmann Signed-off-by: Gustavo F. Padovan Signed-off-by: Greg Kroah-Hartman