kernel, branch linux-2.6.18.y

Linux 2.6.18.8

2007-02-23T23:52:30Z

fix umask when noACL kernel meets extN tuned for ACLs

2007-02-23T23:49:53Z

Fix insecure default behaviour reported by Tigran Aivazian: if an ext2 or ext3 filesystem is tuned to mount with "acl", but mounted by a kernel built without ACL support, then umask was ignored when creating inodes - though root or user has umask 022, touch creates files as 0666, and mkdir creates directories as 0777. This appears to have worked right until 2.6.11, when a fix to the default mode on symlinks (always 0777) assumed VFS applies umask: which it does, unless the mount is marked for ACLs; but ext[23] set MS_POSIXACL in s_flags according to s_mount_opt set according to def_mount_opts. We could revert to the 2.6.10 ext[23]_init_acl (adding an S_ISLNK test); but other filesystems only set MS_POSIXACL when ACLs are configured. We could fix this at another level; but it seems most robust to avoid setting the s_mount_opt flag in the first place (at the expense of more ifdefs). Likewise don't set the XATTR_USER flag when built without XATTR support. Signed-off-by: Hugh Dickins Acked-by: Andreas Gruenbacher Cc: Tigran Aivazian Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

Fix for shmem_truncate_range() BUG_ON()

2007-02-23T23:49:53Z

Ran into BUG() while doing madvise(REMOVE) testing. If we are punching a hole into shared memory segment using madvise(REMOVE) and the entire hole is below the indirect blocks, we hit following assert. BUG_ON(limit <= SHMEM_NR_DIRECT); Signed-off-by: Badari Pulavarty Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

make ppc64 current preempt-safe

2007-02-23T23:49:53Z

Repeated -j20 kernel builds on a G5 Quad running an SMP PREEMPT kernel would often collapse within a day, some exec failing with "Bad address". In each case examined, load_elf_binary was doing a kernel_read, but generic_file_aio_read's access_ok saw current->thread.fs.seg as USER_DS instead of KERNEL_DS. objdump of filemap.o shows gcc 4.1.0 emitting "mr r5,r13 ... ld r9,416(r5)" here for get_paca()->__current, instead of the expected and much more usual "ld r9,416(r13)"; I've seen other gcc4s do the same, but perhaps not gcc3s. So, if the task is preempted and rescheduled on a different cpu in between the mr and the ld, r5 will be looking at a different paca_struct from the one it's now on, pick up the wrong __current, and perhaps the wrong seg. Presumably much worse could happen elsewhere, though that split is rare. Other architectures appear to be safe (x86_64's read_pda is more limiting than get_paca), but ppc64 needs to force "current" into one instruction. Signed-off-by: Hugh Dickins Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

fix msync error on unmapped area

2007-02-23T23:49:52Z

Fix the 2.6.18 sys_msync to report -ENOMEM correctly when an unmapped area falls within its range, and not to overshoot: to satisfy LSB 3.1 tests and to fix Debian Bug#394392. Took the 2.6.19 sys_msync as starting point (including its cleanup of repeated "current->mm"s), reintroducing the msync_interval and balance_dirty_pages_ratelimited_nr needed in 2.6.18. The misbehaviour fixed here may not seem very serious; but it was enough to mislead Debian into backporting 2.6.19's dirty page tracking patches, with attendant mayhem when those resulted in unsuspected file corruption. Signed-off-by: Hugh Dickins Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

read_zero_pagealigned() locking fix

2007-02-23T23:49:52Z

Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem, but another thread's racing read of /dev/zero, or a normal fault, can easily set that pte again, in between zap_page_range and zeromap_page_range getting there. It's been wrong ever since 2.4.3. The simple fix is to use down_write instead, but that would serialize reads of /dev/zero more than at present: perhaps some app would be badly affected. So instead let zeromap_page_range return the error instead of BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in that case - there's no need to optimize for it. Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of zeromap_page_range), though it really isn't interesting there. And since mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that than -ENOMEM. Signed-off-by: Hugh Dickins Cc: Ramiro Voicu: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

Fix incorrect user space access locking in mincore() (CVE-2006-4814)

2007-02-23T23:49:52Z

Doug Chapman noticed that mincore() will doa "copy_to_user()" of the result while holding the mmap semaphore for reading, which is a big no-no. While a recursive read-lock on a semaphore in the case of a page fault happens to work, we don't actually allow them due to deadlock schenarios with writers due to fairness issues. Doug and Marcel sent in a patch to fix it, but I decided to just rewrite the mess instead - not just fixing the locking problem, but making the code smaller and (imho) much easier to understand. Cc: Doug Chapman Cc: Marcel Holtmann Cc: Hugh Dickins Cc: Andrew Morton [chrisw: fold in subsequent fix: 4fb23e439ce0] Acked-by: Hugh Dickins [chrisw: fold in subsequent fix: 825020c3866e] Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

2007-02-23T23:49:52Z

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and forced by binary compatibility. UML/32bit breaks because of this - since it is wise enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host kernels. Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had: default: return sys_ptrace(request, pid, addr, data); Instead here we have: case PTRACE_GET_THREAD_AREA: case ...: return sys_ptrace(request, pid, addr, data); default: return -EINVAL; This change was a style change - when a case is added, it must be explicitly tested this way. In this case, not enough testing was done. Cc: Andi Kleen Signed-off-by: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Greg Kroah-Hartman

V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

2007-02-23T23:49:52Z

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer. (cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332) Signed-off-by: Oleg Nesterov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Greg Kroah-Hartman

V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

2007-02-23T23:49:52Z

Autodetect LG TAPC G701D as tuner type 37, fixing mis-detected tuners in some Hauppauge tv tuner cards. Thanks to Adonis Papas, for pointing this out. (cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf) Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman