- Dec 08, 2009
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit 72c62be1 . It breaks the build, and isn't necessary for the 2.6.27 tree. Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
-
Jean Delvare authored
commit 371dc4a6 upstream Comparing apples to bananas doesn't seem right. The bug has been there since support for the IT8718F was added, so VID never worked for this chip. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Maciej Sosnowski authored
commit eb4400e3 upstream. Change spin_locks to irqsave to prevent dead-locks. Protect adding and deleting to/from dca_providers list. Drop the lock during dca_sysfs_add_req() and dca_sysfs_remove_req() calls as they might sleep (use GFP_KERNEL allocation). Signed-off-by:
Maciej Sosnowski <maciej.sosnowski@intel.com> Acked-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alan Stern authored
This is commit f9c99bb8 back-ported to 2.6.27.39. This patch (as1254-2) splits up the shutdown method of usb_serial_driver into a disconnect and a release method. The problem is that the usb-serial core was calling shutdown during disconnect handling, but drivers didn't expect it to be called until after all the open file references had been closed. The result was an oops when the close method tried to use memory that had been deallocated by shutdown. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Rory Filer <rfiler@SierraWireless.com> Signed-off-by:
-
Oliver Neukum authored
commit 4901b2c3 upstream. This patch implements suspend and resume methods for the option driver. With my hardware I can even suspend the system and keep up a connection for a short time. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-Off-By:
Matthias Urlichs <smurf@smurf.noris.de> Signed-off-by:
-
Libin Yang authored
commit a1f17a87 upstream. The following patch in the driver is required to avoid USB 1.1 device failures that may occur due to requests from USB OHCI controllers may be overwritten if the latency for any pending request by the USB controller is very long (in the range of milliseconds). Signed-off-by:
Libin Yang <libin.yang@amd.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Roel Kluin authored
commit 80a8d122 upstream. The returned error should be negative Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Roel Kluin authored
commit 286e633e upstream. Check whether index is within bounds before testing the element. Signed-off-by:
-
Anand V. Avati authored
commit f60311d5 upstream. fuse_direct_io() has a loop where requests are allocated in each iteration. if allocation fails, the loop is broken out and follows into an unconditional fuse_put_request() on that invalid pointer. Signed-off-by:
Anand V. Avati <avati@gluster.com> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Csaba Henk authored
commit 1b732396 upstream. The comment in fuse_open about O_DIRECT: "VFS checks this, but only _after_ ->open()" also holds for fuse_create, however, the same kind of check was missing there. As an impact of this bug, open(newfile, O_RDWR|O_CREAT|O_DIRECT) fails, but a stub newfile will remain if the fuse server handled the implied FUSE_CREATE request appropriately. Other impact: in the above situation ima_file_free() will complain to open/free imbalance if CONFIG_IMA is set. Signed-off-by:
Csaba Henk <csaba@gluster.com> Signed-off-by:
-
Harald Welte authored
commit d77b8197 upstream. In commit 0de51088 , we introduced the use of acpi-cpufreq on VIA/Centaur CPU's by removing a vendor check for VENDOR_INTEL. However, as it turns out, at least the Nano CPU's also need the PDC (processor driver capabilities) handshake in order to activate the methods required for acpi-cpufreq. Since arch_acpi_processor_init_pdc() contains another vendor check for Intel, the PDC is not initialized on VIA CPU's. The resulting behavior of a current mainline kernel on such systems is: acpi-cpufreq loads and it indicates CPU frequency changes. However, the CPU stays at a single frequency This trivial patch ensures that init_intel_pdc() is called on Intel and VIA/Centaur CPU's alike. Signed-off-by:
Harald Welte <HaraldWelte@viatech.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Mike Isely authored
commit 1f957257 upstream. The s2255 driver had logic which aborted processing of a video frame if there was no process waiting on the video buffer in question. That simply doesn't work when the application is doing things in an asynchronous manner. If the application went to the trouble to queue the buffer in the first place, then the driver should always attempt to complete it - even if the application at that moment has its attention turned elsewhere. Applications which always blocked waiting for I/O on the capture device would not have been affected by this. Applications which *mostly* blocked waiting for I/O on the capture device probably only would have been somewhat affected (frame lossage, at a rate which goes up as the application blocks less). Applications which never blocked on the capture device (e.g. polling only) however would never have been able to receive any video frames, since in that case this "is anyone waiting on this?" check on the buffer never would have evalutated true. This patch just deletes that harmful check against the buffer's wait queue. Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
-
Devin Heitmueller authored
commit 96fbf771 upstream. Because the counters were not reset when starting up streaming, they would be reused from the previous run. This can result in cases such that when the second instance of streaming starts up, the "cnt" variable in em28xx_audio_isocirq() can end up being negative, resulting in attempting to write to memory before the start of runtime->dma_area (as well as having a negative number of bytes to copy). Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
-
Seth Barry authored
commit a57c1dcb upstream. While having tda18271 module set with debug=17 (cal & info prints) and cal=0 (delay calibration process until first use) - I discovered that during the calibration process, if the frequency test for 69750000 returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that the tuner wouldn't be able to pickup any of the frequencies in the range (all the other frequencies bands returned bcal=1). I spent some time going over the code and the NXP's tda18271 spec (ver.4 of it i think) and adding a lot of debug prints and walking/stepping through the calibration process. I found that when the powerscan fails to find a frequency, the rf calibration is not run and the default value is supposed to be used in its place (pulled from the RF_CAL_map table) - but something was getting goofed up there. Now, my c coding skills are very rusty, but i think root of the problem is a signedness issue with the math operation for calculating the rf_a1 and rf_a2 values in tda18271_rf_tracking_filters_init func, which results in values like 20648 for rf_a1 (when it should probably have a value like 0, or so slightly negative that it should be zero - this bad value for rf_a1 would in turn makes the approx calc within tda18271c2_rf_tracking_filters_correction go out of whack). The simplest solution i found was to explicitly convert the signedness of the denominator to avoid the implicit conversion. The values placed into the u32 rf_freq array should never exceed about 900mhz, so i think the s32 max value shouldn't be an issue in this case. I've tested it out a little, and even when i get a bcal=0 with the modified code, the default calibration value gets used, rf_a1 is zero, and the tuner seems to lock on the stream and mythtv seems to play it fine. Signed-off-by:
Seth Barry <seth@cyberseth.com> Signed-off-by:
-
Michael Krufky authored
commit 4d831787 upstream. Multiplication by 62500 causes an overflow in the 32 bit freq variable, which is later divided by 1000 when using FM radio. This patch prevents the overflow by scaling the frequency value correctly upfront. Thanks to Henk Vergonet for spotting the problem and providing a preliminary patch, which this changeset was based upon. Cc: Henk Vergonet <Henk.Vergonet@gmail.com> Signed-off-by:
-
Martin Samek authored
commit 7646b9de upstream. Fixing kernel oops when driver attemps to load xc2028 firmware. Note by djh: the patch contribute by Martin is a port of a fix I made during the PCTV 340e development. It's a temporary workaround that fixes a regression (an OOPS condition) and the real fix should be in the code that manages the i2c master on the dib7000p. But this fix does address the immmediate regression and should be merged upstream until we do a cleaner fix. Signed-off-by:
Martin Samek <martin@marsark.sytes.net> Signed-off-by:
-
David Woodhouse authored
commit 199bc9ff upstream. In 2.6.23 kernel, commit a32ea1e1 ("Fix read/truncate race") fixed a race in the generic code, and as a side effect, now do_generic_file_read() can ask us to readpage() past the i_size. This seems to be correctly handled by the block routines (e.g. block_read_full_page() fills the page with zeroes in case if somebody is trying to read past the last inode's block). JFFS2 doesn't handle this; it assumes that it won't be asked to read pages which don't exist -- and thus that there will be at least _one_ valid 'frag' on the page it's being asked to read. It will fill any holes with the following memset: memset(buf, 0, min(end, frag->ofs + frag->size) - offset); When the 'closest smaller match' returned by jffs2_lookup_node_frag() is actually on a previous page and ends before 'offset', that results in: memset(buf, 0, <huge unsigned negative>); Hopefully, in most cases the corruption is fatal, and quickly causing random oopses, like this: root@10.0.0.4:~/ltp-fs-20090531# ./testcases/kernel/fs/ftest/ftest01 Unable to handle kernel paging request for data at address 0x00000008 Faulting instruction address: 0xc01cd980 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c01cd980] rb_insert_color+0x38/0x184 LR [c0043978] enqueue_hrtimer+0x88/0xc4 Call Trace: [c6c63b60] [c004f9a8] tick_sched_timer+0xa0/0xe4 (unreliable) [c6c63b80] [c0043978] enqueue_hrtimer+0x88/0xc4 [c6c63b90] [c0043a48] __run_hrtimer+0x94/0xbc [c6c63bb0] [c0044628] hrtimer_interrupt+0x140/0x2b8 [c6c63c10] [c000f8e8] timer_interrupt+0x13c/0x254 [c6c63c30] [c001352c] ret_from_except+0x0/0x14 --- Exception: 901 at memset+0x38/0x5c LR = jffs2_read_inode_range+0x144/0x17c [c6c63cf0] [00000000] (null) (unreliable) This patch fixes the issue, plus fixes all LTP tests on NAND/UBI with JFFS2 filesystem that were failing since 2.6.23 (seems like the bug above also broke the truncation). Reported-By:
Anton Vorontsov <avorontsov@ru.mvista.com> Tested-By:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dave Jones authored
commit 690e7448 upstream. A negative offset could be used to index before the event buffer and lead to a security breach. Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Julian Anastasov authored
commit f4950882 upstream. Fix combine_word problem where first octet is not read properly. The only affected place seems to be the INPUT_TERMINAL type. Before now, sound controls can be created with the output terminal's name which is a fallback mechanism used only for unknown input terminal types. For example, Line can wrongly appear as Speaker. After the change it should appear as Line. The side effect of this change can be that users can expect the wrong control name in their scripts or programs while now we return the correct one. Probably, these defines should use get_unaligned_le16 and friends. Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Russell King authored
commit 8ee763b9 upstream. pcm->r[1].slots is the double rate slot information, not the capture information. For capture, 'pcm' will already be the capture ac97 pcm structure. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
commit 4acd57c3 upstream. Signed-off-by:
-
- Nov 09, 2009
-
-
Greg Kroah-Hartman authored
-
Joerg Roedel authored
commit c5cca146 upstream. There is an erratum for IOMMU hardware which documents undefined behavior when forwarding SMI requests from peripherals and the DTE of that peripheral has a sysmgt value of 01b. This problem caused weird IO_PAGE_FAULTS in my case. This patch implements the suggested workaround for that erratum into the AMD IOMMU driver. The erratum is documented with number 63. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Joerg Roedel authored
commit ca020711 upstream. The function iommu_feature_disable is required on system shutdown to disable the IOMMU but it is marked as __init. This may result in a panic if the memory is reused. This patch fixes this bug. Signed-off-by:
-
Jiri Bohac authored
commit d9d52832 upstream. In mii monitor mode, bond_check_dev_link() calls the the ioctl handler of slave devices. It stores the ndo_do_ioctl function pointer to a static (!) ioctl variable and later uses it to call the handler with the IOCTL macro. If another thread executes bond_check_dev_link() at the same time (even with a different bond, which none of the locks prevent), a race condition occurs. If the two racing slaves have different drivers, this may result in one driver's ioctl handler being called with a pointer to a net_device controlled with a different driver, resulting in unpredictable breakage. Unless I am overlooking something, the "static" must be a copy'n'paste error (?). Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Signed-off-by:
-
Peter Zijlstra authored
commit b845b517 upstream. Avoid deadlocks against rq->lock and xtime_lock by deferring the klogd wakeup by polling from the timer tick. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Trond Myklebust authored
commit 9a3936aa upstream. Otherwise, we have to wait for the server to recall it. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit d953126a upstream. We just had a case in which a buggy server occasionally returns the wrong attributes during an OPEN call. While the client does catch this sort of condition in nfs4_open_done(), and causes the nfs4_atomic_open() to return -EISDIR, the logic in nfs_atomic_lookup() is broken, since it causes a fallback to an ordinary lookup instead of just returning the error. When the buggy server then returns a regular file for the fallback lookup, the VFS allows the open, and bad things start to happen, since the open file doesn't have any associated NFSv4 state. The fix is firstly to return the EISDIR/ENOTDIR errors immediately, and secondly to ensure that we are always careful when dereferencing the nfs_open_context state pointer. Signed-off-by:
-
Trond Myklebust authored
commit 3050141b upstream. The NFSv4 renew daemon is shared between all active super blocks that refer to a particular NFS server, so it is wrong to be shutting it down in nfs4_kill_super every time a super block is destroyed. This patch therefore kills nfs4_renewd_prepare_shutdown altogether, and leaves it up to nfs4_shutdown_client() to also shut down the renew daemon by means of the existing call to nfs4_kill_renewd(). Signed-off-by:
-
Ben Hutchings authored
commit f4373bf9 upstream. As seen in <http://bugs.debian.org/549002 >, nfs4_init_client() can overrun the source string when copying the client IP address from nfs_parsed_mount_data::client_address to nfs_client::cl_ipaddr. Since these are both treated as null-terminated strings elsewhere, the copy should be done with strlcpy() not memcpy(). Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Trond Myklebust authored
commit 52567b03 upstream. RFC 3530 states that when we recieve the error NFS4ERR_RESOURCE, we are not supposed to bump the sequence number on OPEN, LOCK, LOCKU, CLOSE, etc operations. The problem is that we map that error into EREMOTEIO in the XDR layer, and so the NFSv4 middle-layer routines like seqid_mutating_err(), and nfs_increment_seqid() don't recognise it. The fix is to defer the mapping until after the middle layers have processed the error. Signed-off-by:
-
Terry Loftin authored
commit a8b40bc7 upstream. Actually pass the NFS_FILE_SYNC option to the server to avoid a Panic in nfs_direct_write_complete() when a commit fails. At the end of an nfs write, if the nfs commit fails, all the writes will be rescheduled. They are supposed to be rescheduled as NFS_FILE_SYNC writes, but the rpc_task structure is not completely intialized and so the option is not passed. When the rescheduled writes complete, the return indicates that they are NFS_UNSTABLE and we try to do another commit. This leads to a Panic because the commit data structure pointer was set to null in the initial (failed) commit attempt. Signed-off-by:
Terry Loftin <terry.loftin@hp.com> Signed-off-by:
-
Samuel Ortiz authored
commit 69c30e1e upstream. We need to pad irda_skb_cb in order to keep it safe accross dev_queue_xmit() calls. This is some ugly and temporary hack triggered by recent qisc code changes. Even though it fixes bugzilla.kernel.org bug #11795, it will be replaced by a proper fix before 2.6.29 is released. Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
-
Avi Kivity authored
commit 6a544355 upstream. The number of entries is multiplied by the entry size, which can overflow on 32-bit hosts. Bound the entry count instead. Reported-by:
David Wagner <daw@cs.berkeley.edu> Signed-off-by:
Avi Kivity <avi@redhat.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Jiri Pirko authored
commit ad61df91 upstream. Commit 9ef1d4c7 ("[NETLINK]: Missing initializations in dumped data") introduced a typo in initialization. This patch fixes this. Signed-off-by:
Jiri Pirko <jpirko@redhat.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit ffcfb8db upstream appletalk: Fix skb leak when ipddp interface is not loaded [ backport to 2.6.27 : Chuck Ebbert <cebbert@redhat.com ] And also do a better job of returning proper NET_{RX,XMIT}_ values. Based on a patch and suggestions by Mark Smith. This fixes CVE-2009-2903 Reported-by:
Mark Smith <lk-netdev@lk-netdev.nosense.org> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Tomoki Sekiyama authored
commit 77238f2b upstream. I found a deadlock bug in UNIX domain socket, which makes able to DoS attack against the local machine by non-root users. How to reproduce: 1. Make a listening AF_UNIX/SOCK_STREAM socket with an abstruct namespace(*), and shutdown(2) it. 2. Repeat connect(2)ing to the listening socket from the other sockets until the connection backlog is full-filled. 3. connect(2) takes the CPU forever. If every core is taken, the system hangs. PoC code: (Run as many times as cores on SMP machines.) int main(void) { int ret; int csd; int lsd; struct sockaddr_un sun; /* make an abstruct name address (*) */ memset(&sun, 0, sizeof(sun)); sun.sun_family = PF_UNIX; sprintf(&sun.sun_path[1], "%d", getpid()); /* create the listening socket and shutdown */ lsd = socket(AF_UNIX, SOCK_STREAM, 0); bind(lsd, (struct sockaddr *)&sun, sizeof(sun)); listen(lsd, 1); shutdown(lsd, SHUT_RDWR); /* connect loop */ alarm(15); /* forcely exit the loop after 15 sec */ for (;;) { csd = socket(AF_UNIX, SOCK_STREAM, 0); ret = connect(csd, (struct sockaddr *)&sun, sizeof(sun)); if (-1 == ret) { perror("connect()"); break; } puts("Connection OK"); } return 0; } (*) Make sun_path[0] = 0 to use the abstruct namespace. If a file-based socket is used, the system doesn't deadlock because of context switches in the file system layer. Why this happens: Error checks between unix_socket_connect() and unix_wait_for_peer() are inconsistent. The former calls the latter to wait until the backlog is processed. Despite the latter returns without doing anything when the socket is shutdown, the former doesn't check the shutdown state and just retries calling the latter forever. Patch: The patch below adds shutdown check into unix_socket_connect(), so connect(2) to the shutdown socket will return -ECONREFUSED. Signed-off-by:
Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com> Signed-off-by:
Masanori Yoshida <masanori.yoshida.tv@hitachi.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Jan Beulich authored
commit 81766741 upstream. Restoring %ebp after the call to audit_syscall_exit() is not only unnecessary (because the register didn't get clobbered), but in the sysenter case wasn't even doing the right thing: It loaded %ebp from a location below the top of stack (RBP < ARGOFFSET), i.e. arbitrary kernel data got passed back to user mode in the register. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Roland McGrath <roland@redhat.com> LKML-Reference: <4AE5CC4D020000780001BD13@vpn.id2.novell.com> Signed-off-by:
-
