linux, branch v2.6.16.44

Linux 2.6.16.44

2007-03-20T21:25:36Z

Linux 2.6.16.44-rc2

2007-03-16T16:59:30Z

pwc-uncompress.c shouldn't #include

2007-03-14T21:25:08Z

Fix a compile error on powerpc. Signed-off-by: Adrian Bunk

Linux 2.6.16.44-rc1

2007-03-11T07:11:10Z

[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak

2007-03-11T06:43:46Z

User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead. Signed-off-by: Chris Wright Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

[IPV6]: Fix for ipv6_setsockopt NULL dereference

2007-03-11T06:42:33Z

I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155 Signed-off-by: Olaf Kirch Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk

Fix buffer overflow in Omnikey CardMan 4040 driver (CVE-2007-0005)

2007-03-11T06:39:14Z

Based on a patch from Don Howard When calling write() with a buffer larger than 512 bytes, the driver's write buffer overflows, allowing to overwrite the EIP and execute arbitrary code with kernel privileges. In read(), there exists a similar problem, but coming from the device. A malicous or buggy device sending more than 512 bytes can overflow of the driver's read buffer, with the same effects as above. Signed-off-by: Marcel Holtmann Signed-off-by: Adrian Bunk

IB/mthca: Fix off-by-one in FMR handling on memfree

2007-03-11T06:37:12Z

From: Michael S. Tsirkin mthca_table_find() will return the wrong address when the table entry being searched for is exactly at the beginning of a sglist entry (other than the first), because it uses >= when it should use >. Example: assume we have 2 entries in scatterlist, 4K each, offset is 4K. The current code will return first entry + 4K when we really want the second entry. In particular this means mapping an FMR on a memfree HCA may end up writing the page table into the wrong place, leading to memory corruption and also causing the HCA to use an incorrect address translation table. Signed-off-by: Michael S. Tsirkin Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk

IPoIB: Rejoin all multicast groups after a port event

2007-03-11T06:36:27Z

When ipoib_ib_dev_flush() is called because of a port event, the driver needs to rejoin all multicast groups, since the flush will call ipoib_mcast_dev_flush() (via ipoib_ib_dev_down()). Otherwise no (non-broadcast) multicast groups will be rejoined until the networking core calls ->set_multicast_list again, and so multicast reception will be broken for potentially a long time. Signed-off-by: Eli Cohen Signed-off-by: Michael S. Tsirkin Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk

IB/mthca: Use mmiowb after doorbell ring

2007-03-11T06:35:15Z

We discovered a problem when running IPoIB applications on multiple CPUs on an Altix system. Many messages such as: ib_mthca 0002:01:00.0: SQ 000014 full (19941644 head, 19941707 tail, 64 max, 0 nreq) appear in syslog, and the driver wedges up. Apparently this is because writes to the doorbells from different CPUs reach the device out of order. The following patch adds mmiowb() calls after doorbell rings to ensure the doorbell writes are ordered. Signed-off-by: Arthur Kepner Signed-off-by: Roland Dreier Signed-off-by: Adrian Bunk