user/sven/linux.git, branch v2.6.25.2

Linux 2.6.25.2

2008-05-06T23:21:32Z

fix SMP ordering hole in fcntl_setlk() (CVE-2008-1669)

2008-05-06T23:21:10Z

commit 0b2bac2f1ea0d33a3621b27ca68b9ae760fca2e9 upstream. fcntl_setlk()/close() race prevention has a subtle hole - we need to make sure that if we *do* have an fcntl/close race on SMP box, the access to descriptor table and inode->i_flock won't get reordered. As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs. STORE descriptor table entry, LOAD inode->i_flock with not a single lock in common on both sides. We do have BKL around the first STORE, but check in locks_remove_posix() is outside of BKL and for a good reason - we don't want BKL on common path of close(2). Solution is to hold ->file_lock around fcheck() in there; that orders us wrt removal from descriptor table that preceded locks_remove_posix() on close path and we either come first (in which case eviction will be handled by the close side) or we'll see the effect of close and do eviction ourselves. Note that even though it's read-only access, we do need ->file_lock here - rcu_read_lock() won't be enough to order the things. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

Linux 2.6.25.1

2008-05-01T21:45:25Z

Fix dnotify/close race (CVE-2008-1375)

2008-05-01T21:44:40Z

commit 214b7049a7929f03bbd2786aaef04b8b79db34e2 upstream. We have a race between fcntl() and close() that can lead to dnotify_struct inserted into inode's list *after* the last descriptor had been gone from current->files. Since that's the only point where dnotify_struct gets evicted, we are screwed - it will stick around indefinitely. Even after struct file in question is gone and freed. Worse, we can trigger send_sigio() on it at any later point, which allows to send an arbitrary signal to arbitrary process if we manage to apply enough memory pressure to get the page that used to host that struct file and fill it with the right pattern... Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drivers/net/tehuti: use proper capability check for raw IO access

2008-05-01T21:44:39Z

commit 6203554207728f43cfb9fd48585cd6500da73d42 in mainline. Yeah, in practice they both mean "root", but Alan correctly points out that anybody who gets to do raw IO space accesses should really be using CAP_SYS_RAWIO rather than CAP_NET_ADMIN. Pointed-out-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

hrtimer: raise softirq unlocked to avoid circular lock dependency

2008-05-01T21:44:39Z

commit 0c96c5979a522c3323c30a078a70120e29b5bdbc upstream The scheduler hrtimer bits in 2.6.25 introduced a circular lock dependency in a rare code path: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.25-sched-devel.git-x86-latest.git #19 ------------------------------------------------------- X/2980 is trying to acquire lock: (&rq->rq_lock_key#2){++..}, at: [] task_rq_lock+0x56/0xa0 but task is already holding lock: (&cpu_base->lock){++..}, at: [] lock_hrtimer_base+0x31/0x60 which lock already depends on the new lock. The scenario which leads to this is: posix-timer signal is delivered -> posix-timer is rearmed timer is already expired in hrtimer_enqueue() -> softirq is raised To prevent this we need to move the raise of the softirq out of the base->lock protected code path. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman

x86: Fix 32-bit x86 MSI-X allocation leakage

2008-05-01T21:44:39Z

commit 9d9ad4b51d2b29b5bbeb4011f5e76f7538119cf9 upstream This bug was introduced in the 2.6.24 lguest merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code. This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will only be able to use legacy interrupts. Signed-off-by: Peter P Waskiewicz Jr Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

alpha: unbreak OSF/1 (a.out) binaries

2008-05-01T21:44:39Z

commit 2444e56b0c08e6f3e3877583841a1213e3263d98 upstream OSF/1 brk(2) was broken by following one-liner in sys_brk() (commit 4cc6028d4040f95cdb590a87db478b42b8be0508): - if (brk < mm->end_code) + if (brk < mm->start_brk) goto out; The problem is that osf_set_program_attributes() does update mm->end_code, but not mm->start_brk, which still contains inappropriate value left from binary loader, so brk() always fails. Signed-off-by: Ivan Kokshaysky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Correct regression in relogin code.

2008-05-01T21:44:39Z

commit: 666301e673e192c87a40e07a8357d6996b57b70f upstream Commit 63a8651f2548c6bb5132c0b4e7dad4f57a9274db ([SCSI] qla2xxx: Correct infinite-login-retry issue.) introduced a small regression where a successful relogin would result in an fcport's loop_id to be incorrectly reset to FC_NO_LOOP_ID. Only clear-out loopid, if retries have been 'truly' exhausted. Signed-off-by: Andrew Vasquez Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

RDMA/nes: Fix adapter reset after PXE boot

2008-05-01T21:44:38Z

commit: bc5698f3ecc9587e1edb343a2878f8d228c49e0e upstream After PXE boot, the iw_nes driver does a full reset to ensure the card is in a clean state. However, it doesn't wait for firmware to complete its work before issuing a port reset to enable the ports, which leads to problems bringing up the ports. The solution is to wait for firmware to complete its work before proceeding with port reset. This bug was flagged by Roland Dreier . Signed-off-by: Chien Tung Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman