linux, branch v2.6.24.1

Linux 2.6.24.1

2008-02-08T19:55:30Z

splice: missing user pointer access verification (CVE-2008-0009/10)

2008-02-08T19:46:30Z

patch 8811930dc74a503415b35c4a79d14fb0b408a361 in mainline. vmsplice_to_user() must always check the user pointer and length with access_ok() before copying. Likewise, for the slow path of copy_from_user_mmap_sem() we need to check that we may read from the user region. Signed-off-by: Jens Axboe Cc: Wojciech Purczynski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

drm: the drm really should call pci_set_master..

2008-02-08T19:46:29Z

(submitted upstream as 19a8f59ab8ceee751ea720085098355d53f727d6) perhaps bonghits could turn on my bus-mastering because the drm certainly never bothered doing it before. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

Driver core: Revert "Fix Firmware class name collision"

2008-02-08T19:46:29Z

patch 7d640c4a5b36c4733460065db1554da924044511 in mainline. This reverts commit 109f0e93b6b728f03c1eb4af02bc25d71b646c59. The original patch breaks BIOS updates on all Dell machines. The path to the firmware file for the dell_rbu driver changes, which breaks all of the userspace tools which rely on it. Note that this patch re-introduces a problem with i2c name collision that was previously fixed by this patch. Signed-off-by: Michael E Brown Signed-off-by: Greg Kroah-Hartman

fix writev regression: pan hanging unkillable and un-straceable

2008-02-08T19:46:29Z

patch 124d3b7041f9a0ca7c43a6293e1cae4576c32fd5 in mainline. Frederik Himpe reported an unkillable and un-straceable pan process. Zero length iovecs can go into an infinite loop in writev, because the iovec iterator does not always advance over them. The sequence required to trigger this is not trivial. I think it requires that a zero-length iovec be followed by a non-zero-length iovec which causes a pagefault in the atomic usercopy. This causes the writev code to drop back into single-segment copy mode, which then tries to copy the 0 bytes of the zero-length iovec; a zero length copy looks like a failure though, so it loops. Put a test into iov_iter_advance to catch zero-length iovecs. We could just put the test in the fallback path, but I feel it is more robust to skip over zero-length iovecs throughout the code (iovec iterator may be used in filesystems too, so it should be robust). Signed-off-by: Nick Piggin Signed-off-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sched: fix high wake up latencies with FAIR_USER_SCHED

2008-02-08T19:46:29Z

patch 296825cbe14d4c95ee9c41ca5824f7487bfb4d9d in mainline. The reason why we are getting better wakeup latencies for !FAIR_USER_SCHED is because of this snippet of code in place_entity(): if (!initial) { /* sleeps upto a single latency don't count. */ if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se)) ^^^^^^^^^^^^^^^^^^ vruntime -= sysctl_sched_latency; /* ensure we never gain time by being placed backwards. */ vruntime = max_vruntime(se->vruntime, vruntime); } NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and not group-level entities. With the patch attached, I could see that wakeup latencies with FAIR_USER_SCHED are restored to the same level as !FAIR_USER_SCHED. Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

sched: let +nice tasks have smaller impact

2008-02-08T19:46:29Z

patch ef9884e6f29bbe1075204f962a00f7533bf7e8f3 in mainline. Michel Dänzr has bisected an interactivity problem with plus-reniced tasks back to this commit: 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 Author: Peter Zijlstra Date: Mon Oct 15 17:00:14 2007 +0200 sched: another wakeup_granularity fix unit mis-match: wakeup_gran was used against a vruntime fix this by assymetrically scaling the vtime of positive reniced tasks. Bisected-by: Michel Dänzer Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

b43: Reject new firmware early

2008-02-08T19:46:29Z

(not in mainline, as it is not applicable.) We must reject new incompatible firmware early to avoid running into strange transmission failures. The current development tree supports newer firmware revisions. These revisions cause strange failures on the stable 2.6.24 kernel. Add a check to avoid confusing users a lot. Signed-off-by: Michael Buesch Signed-off-by: Greg Kroah-Hartman

selinux: fix labeling of /proc/net inodes

2008-02-08T19:46:28Z

patch b1aa5301b9f88a4891061650c591fb8fe1c1d1da in mainline. The proc net rewrite had a side effect on selinux, leading it to mislabel the /proc/net inodes, thereby leading to incorrect denials. Fix security_genfs_sid to ignore extra leading / characters in the path supplied by selinux_proc_get_sid since we now get "//net/..." rather than "/net/...". Signed-off-by: Stephen Smalley Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

b43legacy: fix DMA slot resource leakage

2008-02-08T19:46:28Z

patch 8dd0100ce9511e52614ecd0a6587c13ce5769c8b in mainline. This fixes four resource leakages. In any error path we must deallocate the DMA frame slots we previously allocated by request_slot(). This is done by storing the ring pointers before doing any ring allocation and restoring the old pointers in case of an error. This patch by Michael Buesch has been ported to b43legacy. Cc: Michael Buesch Signed-off-by: Stefano Brivio Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman