- Feb 23, 2007
-
-
Greg Kroah-Hartman authored
-
Hugh Dickins authored
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 <hugh@veritas.com> Acked-by:
Andreas Gruenbacher <agruen@suse.de> Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Badari Pulavarty authored
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 <pbadari@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Hugh Dickins authored
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 authored
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 authored
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:
-
Linus Torvalds authored
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 <dchapman@redhat.com> Cc: Marcel Holtmann <holtmann@redhat.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@osdl.org> [chrisw: fold in subsequent fix: 4fb23e43 ] Acked-by:
Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
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 f0f2d653 ) 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 <ak@suse.de> Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Oleg Nesterov authored
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 419dd837 ) Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Michael Krufky authored
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 1323fbda ) Signed-off-by:
-
Martin Samuelsson authored
Or status flags together in DECODER_GET_STATUS instead of and-zapping them. (cherry picked from commit 55d5440d ) Signed-off-by:
Martin Samuelsson <sam@home.se> Signed-off-by:
-
Grant Likely authored
Host endianess does not affect the order that pixel rgb data comes in from the quickcam (the values are bytes, not words or longs). The driver is erroniously swapping the order of rgb values for big endian machines. This patch is needed get the Quickcam communicator working on big endian machines (tested on powerpc) (cherry picked from commit c6d704c8 ) Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Jean Delvare authored
reference to .init.text: from .text between 'cx88_card_setup' (at offset 0x68c) and 'cx88_risc_field' Caused by leadtek_eeprom() being declared __devinit and called from a non-devinit context. (cherry picked from commit 69f7e75a ) Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Hans Verkuil authored
This bug broke the MPEG audio mode controls. (cherry picked from commit cb2c7b49 ) Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Ang Way Chuang authored
CRC-32 checking during ULE decapsulation always failed on x86_64 systems due to the size of a variable used to store CRC. This bug was discovered on Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such problem. This patch has been tested on 64-bit system as well as 32-bit system. (cherry picked from commit dedcefb0 ) Signed-off-by:
Ang Way Chuang <wcang@nrg.cs.usm.my> Signed-off-by:
-
Roland Dreier authored
When ib_cancel_mad() is called, it puts the canceled send on a list and schedules a "flushed" callback from process context. However, this leaves a window where a receive completion could be processed before the send is fully flushed. This is fine, except that ib_find_send_mad() will find the MAD and return it to the receive processing, which results in the sender getting both a successful receive and a "flushed" send completion for the same request. Understandably, this confuses the sender, which is expecting only one of these two callbacks, and leads to grief such as a use-after-free in IPoIB. Fix this by changing ib_find_send_mad() to return a send struct only if the status is still successful (and not "flushed"). The search of the send_list already had this check, so this patch just adds the same check to the search of the wait_list. Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Eric Sandeen authored
http://kernelfun.blogspot.com/2006/11/mokb-14-11-2006-linux-26x-selinux.html mount that image... fs: filesystem was not cleanly unmounted, running fsck.hfs is recommended. mounting read-only. hfs: get root inode failed. BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018 printing eip ... EIP is at superblock_doinit+0x21/0x767 ... [] selinux_sb_kern_mount+0xc/0x4b [] vfs_kern_mount+0x99/0xf6 [] do_kern_mount+0x2d/0x3e [] do_mount+0x5fa/0x66d [] sys_mount+0x77/0xae [] syscall_call+0x7/0xb DWARF2 unwinder stuck at syscall_call+0x7/0xb hfs_fill_super() returns success even if root_inode = hfs_iget(sb, &fd.search_key->cat, &rec); or sb->s_root = d_alloc_root(root_inode); fails. This superblock finds its way to superblock_doinit() which does: struct dentry *root = sb->s_root; struct inode *inode = root->d_inode; and boom. Need to make sure the error cases return an error, I think. [akpm@osdl.org: return -ENOMEM on oom] Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Signed-off-by:
-
Andrew Morton authored
If grow_buffers() is for some reason passed a block number which wants to lie outside the maximum-addressable pagecache range (PAGE_SIZE * 4G bytes) then it will accidentally truncate `index' and will then instnatiate a page at the wrong pagecache offset. This causes __getblk_slow() to go into an infinite loop. This can happen with corrupted disks, or with software errors elsewhere. Detect that, and handle it. Signed-off-by:
-
Dirk Eibach authored
On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to 2.6.18 broke RTC support. The main problem are changes to ds1337_init_client(). When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7 in status register is set. This has to be reset by writing 0 to status register. But since there are only 16 byte written to the chip and the first byte is interpreted as an address, the status register (which is the 16th) is never written. The other problem is, that initializing all registers to zero is not valid for day, date and month register. Funny enough this is checked by ds1337_detect(), which depends on this values not being zero. So then treated by ds1337_init_client() the ds1337 is not detected anymore, whereas the failure bit in the status register is still set. Broken by commit f9e89579 (2.6.16-rc1, 2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit 763d9c04 ). Signed-off-by:
Dirk Stieler <stieler@gdsys.de> Signed-off-by:
Dirk Eibach <eibach@gdsys.de> Signed-off-by:
-
Roland Dreier authored
struct srp_device.fmr_page_mask was unsigned long, which means that the top part of addresses above 4G was being chopped off on 32-bit architectures. Of course nothing good happens when data from SRP targets is DMAed to the wrong place. Fix this by changing fmr_page_mask to u64, to match the addresses actually used by IB devices. Thanks to Brian Cain <Brian.Cain@ge.com> and David McMillen <davem@systemfabricworks.com> for help diagnosing the bug and testing the fix. Signed-off-by:
-
Tejun Heo authored
Clear-garbage-after-CDB patch missed scsi_execute() and it causes some ODDs (HL-DT-ST DVD-RAM GSA-H30N) choke during SCSI scan. Note that this patch is only for -stable. There is another more reliable fix for this problem proposed for devel tree. http://thread.gmane.org/gmane.linux.ide/14605/focus=14605 Signed-off-by:
Tejun Heo <htejun@gmail.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Douglas Gilbert <dougg@torque.net> Signed-off-by:
-
Andi Kleen authored
SYSENTER can cause a NT to be set which might cause crashes on the IRET in the next task. Following similar i386 patch from Linus. Signed-off-by:
Andi Kleen <ak@suse.de> [backport from Chuck Ebbert] Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by:
-
Michael Buesch authored
If bcm43xx were to process an afterburner (ampdu) status response, Linux would oops. The ampdu and intermediate status bits are properly named. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop. Signed-off-by:
-
- Feb 20, 2007
-
-
Greg Kroah-Hartman authored
-
Greg Banks authored
Due to type confusion, when an nfsacl verison 2 'ACCESS' request finishes and tries to clean up, it calls fh_put on entiredly the wrong thing and this can cause an oops. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- Dec 16, 2006
-
-
Chris Wright authored
-
Arjan van de Ven authored
On the Core2 cpus, the rdtsc instruction is not serializing (as defined in the architecture reference since rdtsc exists) and due to the deep speculation of these cores, it's possible that you can observe time go backwards between cores due to this speculation. Since the kernel already deals with this with the SYNC_RDTSC flag, the solution is simple, only assume that the instruction is serializing on family 15... The price one pays for this is a slightly slower gettimeofday (by a dozen or two cycles), but that increase is quite small to pay for a really-going-forward tsc counter. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Marcel Holtmann authored
With malformed packets it might be possible to overwrite internal CMTP and CAPI data structures. This patch adds additional length checks to prevent these kinds of remote attacks. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Daniel Barkalow authored
At least some nforce cards continue to send legacy interrupts when MSI is enabled, and these interrupts are treated as unhandled by the kernel. This patch disables legacy interrupts explicitly when enabling MSI mode. The correct fix is to change the MSI infrastructure to disable legacy interrupts when enabling MSI, but this is potentially risky if the device isn't PCI-2.3 or is quirky, so the correct fix is going into mainline, while patches like this one go into -stable. Legend has it that it is most correct to disable legacy interrupts before enabling MSI, but the mainline patch does it in the other order, and this patch is "obviously" the same as mainline. Signed-off-by:
Daniel Barkalow <barkalow@iabervon.org> Signed-off-by:
-
Hirokazu Takata authored
The m32r kernel 2.6.18-rc1 or after cause build errors of "unknown isa configuration" for userspace application programs, such as glibc, gdb, etc. This is because the recent kernel do not include linux/config.h not to expose kernel headers for userspace. To fix the above compile errors, this patch fixes two headers ptrace.h and sigcontext.h for m32r and makes them platform-independent. Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Cc: <stable@kernel.org> Signed-off-by:
-
Zachary Amsden authored
It is possible to have tasklets get scheduled before softirqd has had a chance to spawn on all CPUs. This is totally harmless; after success during action CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes softirqd on the appropriate CPU to process the already pending tasklets. So there is no danger of having a missed wakeup for any tasklets that were already pending. In particular, i386 is affected by this during startup, and is visible when using a very large initrd; during the time it takes for the initrd to be decompressed, a timer IRQ can come in and schedule RCU callbacks. It is also possible that resending of a hardware IRQ via a softirq triggers the same bug. Because of different timing conditions, this shows up in all emulators and virtual machines tested, including Xen, VMware, Virtual PC, and Qemu. It is also possible to trigger on native hardware with a large enough initrd, although I don't have a reliable case demonstrating that. Signed-off-by:
Zachary Amsden <zach@vmware.com> Cc: <caglar@pardus.org.tr> Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> Signed-off-by:
-
Andrey Mirkin authored
OpenVZ Linux kernel team has found a problem with mounting in compat mode. Simple command "mount -t smbfs ..." on Fedora Core 5 distro in 32-bit mode leads to oops: Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 PGD 34d48067 PUD 34d03067 PMD 0 Oops: 0000 [1] SMP CPU: 0 Modules linked in: iptable_nat simfs smbfs ip_nat ip_conntrack vzdquota parport_pc lp parport 8021q bridge llc vznetdev vzmon nfs lockd sunrpc vzdev iptable_filter af_packet xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle xt_limit ipt_tos ipt_REJECT ip_tables x_tables thermal processor fan button battery asus_acpi ac uhci_hcd ehci_hcd usbcore i2c_i801 i2c_core e100 mii floppy ide_cd cdrom Pid: 14656, comm: mount RIP: 0060:[<ffffffff802bc7c6>] [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 RSP: 0000:ffff810034d31f38 EFLAGS: 00010292 RAX: 000000000000002c RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff810034c86bc0 RSI: 0000000000000096 RDI: ffffffff8061fc90 RBP: ffff810034d31f78 R08: 0000000000000000 R09: 000000000000000d R10: ffff810034d31e58 R11: 0000000000000001 R12: ffff810039dc3000 R13: 000000000805ea48 R14: 0000000000000000 R15: 00000000c0ed0000 FS: 0000000000000000(0000) GS:ffffffff80749000(0033) knlGS:00000000b7d556b0 CS: 0060 DS: 007b ES: 007b CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000034d43000 CR4: 00000000000006e0 Process mount (pid: 14656, veid=300, threadinfo ffff810034d30000, task ffff810034c86bc0) Stack: 0000000000000000 ffff810034dd0000 ffff810034e4a000 000000000805ea48 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000805ea48 ffffffff8021e64e 0000000000000000 0000000000000000 Call Trace: [<ffffffff8021e64e>] ia32_sysret+0x0/0xa Code: 83 3b 06 0f 85 41 01 00 00 0f b7 43 0c 89 43 14 0f b7 43 0a RIP [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 RSP <ffff810034d31f38> CR2: 0000000000000000 The problem is that data_page pointer can be NULL, so we should skip data conversion in this case. Signed-off-by:
Andrey Mirkin <amirkin@openvz.org> Cc: <stable@kernel.org> Signed-off-by:
-
Russell King authored
Later glibc requires the *at syscalls. Add them. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Stefan Richter authored
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431 iBook G3 threw a machine check exception and put the display backlight to full brightness after ohci1394 was unloaded and reloaded. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> [dsd@gentoo.org: also added missing if condition, commit 63cca59e ] Signed-off-by:
Daniel Drake <dsd@gentoo.org> Acked-by:
-
Hans Verkuil authored
The TUNER_LG_NTSC_TAPE is identical in all respects to the TUNER_PHILIPS_FM1236_MK3. So use the params struct for the Philips tuner. Also add this LG_NTSC_TAPE tuner to the switches where radio specific parameters are set so it behaves like a TUNER_PHILIPS_FM1236_MK3. This change fixes the radio support for this tuner (the wrong bandswitch byte was used). Thanks to Andy Walls <cwalls@radix.net> for finding this bug. Signed-off-by:
-
Michael Krufky authored
In some cases when using VSB, the AGC status register has been known to falsely report "no signal" when in fact there is a carrier lock. The datasheet labels these status flags as QAM only, yet the lgdt330x module is using these flags for both QAM and VSB. This patch allows for the carrier recovery lock status register to be tested, even if the agc signal status register falsely reports no signal. Thanks to jcrews from #linuxtv in irc, for initially reporting this bug. Signed-off-by:
-
Andy Gospodarek authored
This is a small fix-up to finish out the work done by Jay Vosburgh to add carrier-state support for bonding devices. The output in /proc/net/bonding/bondX was correct, but when collecting the same info via an iotcl it could still be incorrect. Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Cc: Jeff Garzik <jeff@garzik.org> Cc: Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Jeet Chaudhuri authored
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in. This fixes an oops reported (and fixed) by Jeet Chaudhuri, when max_sdu_size is greater than 0. Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Miller authored
We grab a reference to the route's inetpeer entry but forget to release it in xfrm4_dst_destroy(). Bug discovered by Kazunori MIYAZAWA <kazunori@miyazawa.org> Signed-off-by:
-
