- 09 Jan, 2007 29 commits
-
-
Chuck Ebbert authored
Check struct type before dereferencing fields in ebt_entry. Failure to check can cause oops. Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Maxime Bizon authored
I have a Marvell board which has the same i2c hw block than mv64xxx, so I'm trying to use i2c-mv64xxx driver. But I get the following random oops at boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 Backtrace: [<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c) [<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0) r8 = C0501E08 r7 = 00000005 r6 = C0501E08 r5 = 00000005 r4 = C048BB78 [<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134) r6 = C0449C78 r5 = F1020000 r4 = FFFFFFFF [<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100) r8 = C1CAC400 r7 = 00000005 r6 = 00000002 r5 = F1020000 r4 = FFFFFFFF [<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0) r7 = C041B2AC r6 = C0397E4C r5 = 00000000 r4 = 00000005 [<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244) [<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24) The oops is caused by a spurious interrupt that occurs when request_irq is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL. I noticed that hardware init is done after requesting irq. Thus any pending irq from previous hardware usage may cause this. Signed-off-by: Maxime Bizon <mbizon@freebox.fr> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
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. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Phillip Lougher authored
Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/ fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops is an unchecked corrupted block length field read by cramfs_readpage(). This patch adds a sanity check to cramfs_readpage() which checks that the block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is intentional, even though the uncompressed data is not going to be larger than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than the original source data. Mkcramfs checks that the compressed size is always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could use the original uncompressed data in this case, but it doesn't. Signed-off-by: Phillip Lougher <phillip@lougher.org.uk> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Eric Sandeen authored
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz Basically it makes a filesystem, splats some random bits over it, then tries to mount it and do some simple filesystem actions. At best, the filesystem catches the corruption gracefully. At worst, things spin out of control. As you might guess, we found a couple places in ext3 where things spin out of control :) First, we had a corrupted directory that was never checked for consistency... it was corrupt, and pointed to another bad "entry" of length 0. The for() loop looped forever, since the length of ext3_next_entry(de) was 0, and we kept looking at the same pointer over and over and over and over... I modeled this check and subsequent action on what is done for other directory types in ext3_readdir... (adding this check adds some computational expense; I am testing a followup patch to reduce the number of times we check and re-check these directory entries, in all cases. Thanks for the idea, Andreas). Next we had a root directory inode which had a corrupted size, claimed to be > 200M on a 4M filesystem. There was only really 1 block in the directory, but because the size was so large, readdir kept coming back for more, spewing thousands of printk's along the way. Per Andreas' suggestion, if we're in this read error condition and we're trying to read an offset which is greater than i_blocks worth of bytes, stop trying, and break out of the loop. With these two changes fsfuzz test survives quite well on ext3. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Eric Sandeen authored
This one was pointed out on the MOKB site: http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html If a directory's i_size is corrupted, ext2_find_entry() will keep processing pages until the i_size is reached, even if there are no more blocks associated with the directory inode. This patch puts in some minimal sanity-checking so that we don't keep checking pages (and issuing errors) if we know there can be no more data to read, based on the block count of the directory inode. This is somewhat similar in approach to the ext3 patch I sent earlier this year. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
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> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Adrian Bunk authored
Stolen from a patch by Randy Dunlap. Signed-off-by: Adrian Bunk <bunk@stusta.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> Forwarded-by: Jordan Neumeyer Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
John Heffner authored
This changes the microsecond RTT sampling so that samples are taken in the same way that RTT samples are taken for the RTO calculator: on the last segment acknowledged, and only when the segment hasn't been retransmitted. Signed-off-by: John Heffner <jheffner@psc.edu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Paolo 'Blaisorblade' Giarrusso authored
Makes UML compile on any possible processor choice. The two problems were: *) x86 code, when 386 is selected, checks at runtime boot_cpuflags, which we not have. *) 3Dnow support for memcpy() et al. does not compile currently and fixing t is not trivial, so simply disable it; with this change, if one selects MK UML compiles (while it did not). Merged upstream. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Willy Tarreau authored
The line: hp->Mode &= !RIO_PCI_INT_ENABLE; is obviously wrong as RIO_PCI_INT_ENABLE=0x04 and is used as a bitmask 2 lines before. Getting no IRQ would not disable RIO_PCI_INT_ENABLE but rather RIO_PCI_BOOT_FROM_RAM which equals 0x01. Obvious fix is to change ! for ~. Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Chuck Short authored
Update pci ids. Signed-off-by: Chuck Short <zulcss@gmail.com> Signed-off-by: Ben Collins <bcollins@ubuntu.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Dave Airlie authored
Signed-off-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Jason Gaston authored
This updated patch adds the Intel ICH9 LPC and SMBus Controller DID's. Signed-off-by: Jason Gaston <jason.d.gaston@intel.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Jason Gaston authored
This updated patch adds the Intel ICH9 LPC and SMBus Controller DID's. Signed-off-by: Jason Gaston <jason.d.gaston@intel.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Rudolf Marek authored
Documentation update included. Compile tested. Signed-off-by: Rudolf Marek <r.marek@sh.cvut.cz> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
David Brownell authored
Return a fault code if the Dataflash driver runs into a "no device present" error when the MISO line has a pulldown (it currently expects a pullup), so that rmmod won't oops. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
David L Stevens authored
It is important that we only assign dev->ip{,6}_ptr only after all portions of the inet{,6} are setup. Otherwise we can receive packets before the multicast spinlocks et al. are initialized. Signed-off-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
David S. Miller authored
This matches what the ISA cs4231 driver uses. Tested by Georg Chini. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Georg Chini authored
SBUS: Change IRQ-handler return value from 0 to IRQ_HANDLED and fix some initialisation problems. Change period_bytes_min from 4096 to 256 to allow driver to work with low latency (VOIP) applications. Hope this does not break EBUS. Signed-off-by: Georg Chini <georg.chini@triaton-webhosting.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Mikael Pettersson authored
Implementations assume the buffer is at least 4 byte aligned. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Adrian Bunk authored
Based on patches from Linus' tree. Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Fabrice Knevez authored
"sunkbd_enable(sunkbd, 0);" has no effect. Adding "sunkbd->enabled = enable" in sunkbd_enable (obvious) Signed-off-by: Fabrice Knevez <nuxdoors@cegetel.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Andrew Morton authored
WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to .init.data:ibmtr_mem_base from .text between 'ibmtr_probe1' (at offset 0x6e6) and 'ibmtr_probe_card' WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to .init.data:ibmtr_mem_base from .text between 'ibmtr_probe1' (at offset 0x74a) and 'ibmtr_probe_card' WARNING: drivers/net/tokenring/ibmtr.o - Section mismatch: reference to .init.data:ibmtr_mem_base from .text between 'ibmtr_probe1' (at offset 0x7fd) and 'ibmtr_probe_card' Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
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. Backport to 2.6.16 by Chuck Ebbert <76306.1226@compuserve.com> [Changed 'set_debugreg' to the older 'set_debug' in setup64.c and added raw_local_save_flags() from 2.6.19 to system.h] Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Chuck Ebbert authored
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
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: Adrian Bunk <bunk@stusta.de>
-
Andrew Morton authored
If grow_buffers() is for some reason passed a block number which wants to li outside the maximum-addressable pagecache range (PAGE_SIZE * 4G bytes) then 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: Andrew Morton <akpm@osdl.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 04 Jan, 2007 6 commits
-
-
Linus Torvalds authored
(And reset it on new thread creation) It turns out that eflags is important to save and restore not just because of iopl, but due to the magic bits like the NT bit, which we don't want leaking between different threads. Backported to 2.6.16 by Chuck Ebbert <76306.1226@compuserve.com> [Backport consisted of removing the CFI annotations.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Marcel Holtmann authored
The function isdn_ppp_ccp_reset_alloc_state() sets ->timer.function and ->timer.data and later on calls add_timer() with no init_timer() ever done. Noted by Al Viro. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
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. Also included are two fixes for the original patch including one by Oleg Nesterov. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Miklos Szeredi authored
Fuse didn't always call i_size_write() with i_mutex held which caused rare hangs on SMP/32bit. This bug has been present since fuse-2.2, well before being merged into mainline. The simplest solution is to protect i_size_write() with the per-connection spinlock. Using i_mutex for this purpose would require some restructuring of the code and I'm not even sure it's always safe to acquire i_mutex in all places i_size needs to be set. Since most of vmtruncate is already duplicated for other reasons, duplicate the remaining part as well, making all i_size_write() calls internal to fuse. Using i_size_write() was unnecessary in fuse_init_inode(), since this function is only called on a newly created locked inode. Reported by a few people over the years, but special thanks to Dana Henriksen who was persistent enough in helping me debug it. Adrian Bunk: Backported to 2.6.16. Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Robert Olsson authored
Adrian Bunk: Backported to 2.6.16. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
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: Jean Delvare <khali@linux-fr.org>
-
- 03 Jan, 2007 1 commit
-
-
Patrick McHardy authored
The move of qdisc destruction to a rcu callback broke locking in the entire qdisc layer by invalidating previously valid assumptions about the context in which changes to the qdisc tree occur. The two assumptions were: - since changes only happen in process context, read_lock doesn't need bottem half protection. Now invalid since destruction of inner qdiscs, classifiers, actions and estimators happens in the RCU callback unless they're manually deleted, resulting in dead-locks when read_lock in process context is interrupted by write_lock_bh in bottem half context. - since changes only happen under the RTNL, no additional locking is necessary for data not used during packet processing (f.e. u32_list). Again, since destruction now happens in the RCU callback, this assumption is not valid anymore, causing races while using this data, which can result in corruption or use-after-free. Instead of "fixing" this by disabling bottem halfs everywhere and adding new locks/refcounting, this patch makes these assumptions valid again by moving destruction back to process context. Since only the dev->qdisc pointer is protected by RCU, but ->enqueue and the qdisc tree are still protected by dev->qdisc_lock, destruction of the tree can be performed immediately and only the final free needs to happen in the rcu callback to make sure dev_queue_xmit doesn't access already freed memory. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 26 Dec, 2006 1 commit
-
-
Adrian Bunk authored
-
- 18 Dec, 2006 3 commits
-
-
Adrian Bunk authored
-
Trond Myklebust authored
If the open intents tell us that a given lookup is going to result in a, exclusive create, we currently optimize away the lookup call itself. The reason is that the lookup would not be atomic with the create RPC call, so why do it in the first place? A problem occurs, however, if the VFS aborts the exclusive create operation after the lookup, but before the call to create the file/directory: in this case we will end up with a hashed negative dentry in the dcache that has never been looked up. Fix this by only actually hashing the dentry once the create operation has been successfully completed. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Brian King authored
The PCI ID table in the DAC960 driver conflicts with some devices that use the ipr driver. All ipr adapters that use this chip have an IBM subvendor ID and all DAC960 adapters that use this chip have a Mylex subvendor id. Signed-off-by: Brian King <brking@us.ibm.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-