- Jul 28, 2008
-
-
Greg Kroah-Hartman authored
-
Gerrit Renker authored
[ Upstream commit 47112e25 ] This patch clamps the cscov setsockopt values to a maximum of 0xFFFF. Setsockopt values greater than 0xffff can cause an unwanted wrap-around. Further, IPv6 jumbograms are not supported (RFC 3838, 3.5), so that values greater than 0xffff are not even useful. Further changes: fixed a typo in the documentation. [ Add USHORT_MAX from upstream to linux/kernel.h -DaveM ] Signed-off-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Steffen Klassert authored
[ Upstream commit fe833fca ] When generating the ip header for the transformed packet we just copy the frag_off field of the ip header from the original packet to the ip header of the new generated packet. If we receive a packet as a chain of fragments, all but the last of the new generated packets have the IP_MF flag set. We have to mask the frag_off field to only keep the IP_DF flag from the original packet. This got lost with git commit 36cf9acf ("[IPSEC]: Separate inner/outer mode processing on output") Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 68be802c ] I just noticed "cat /proc/net/raw" was buggy, missing '\n' separators. I believe this was introduced by commit 8cd850ef ([RAW]: Cleanup IPv4 raw_seq_show.) This trivial patch restores correct behavior, and applies to current Linus tree (should also be applied to stable tree as well.) Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
Herbert Xu authored
[ Upstream commit bc6cffd1 ] We need to unshare the skb first as otherwise pskb_may_pull may write to a shared skb which could be bad. Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 392fdb0e ] The length field in the PPPOE header wasn't checked completely. This patch causes all packets shorter than the declared length to be dropped. It also changes the memcpy_toiovec call to skb_copy_datagram_iovec so that paged packets (rare for PPPOE) are handled properly. Thanks to Ilja of the Netric Security Team for discovering and reporting this bug, and Chris Wright for the total_len check. [ Incorporate warning fix from Stephen Hemminger. -DaveM ] Signed-off-by:
-
James Chapman authored
[ Upstream commit 6b6707a5 ] This patch fixes a potential memory corruption in pppol2tp_recvmsg(). If skb->len is bigger than the caller's buffer length, memcpy_toiovec() will go into unintialized data on the kernel heap, interpret it as an iovec and start modifying memory. The fix is to change the memcpy_toiovec() call to skb_copy_datagram_iovec() so that paged packets (rare for PPPOL2TP) are handled properly. Also check that the caller's buffer is big enough for the data and set the MSG_TRUNC flag if it is not so. Reported-by:
Ilja <ilja@netric.org> Signed-off-by:
James Chapman <jchapman@katalix.com> Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit 847499ce ] This fixes the bridge reference count problem and cleanups ipv6 FIB timer management. Don't use expires field, because it is not a proper way to test, instead use timer_pending(). Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit ebb36a97 ] Based upon a report by Olaf Hering. Signed-off-by:
-
Micah Dowty authored
[ Upstream commit ae6134bd ] This is a trivial patch against the hdlcdrv module that fixes its CRC calculation. The finished CRC was overwriting the first two bytes of each packet rather than being appended to the end. I've tested this with 2.6.8 and 2.6.10-rc1, but hdlcdrv hasn't changed much recently so it should work with many other kernel versions. Signed-off-by:
Micah Dowty <micah@navi.cx> Acked-by:
Thomas Sailer <t.sailer@alumni.ethz.ch> Signed-off-by:
-
- Jul 24, 2008
-
-
Greg Kroah-Hartman authored
-
Alexander Simon authored
commit dc88807e upstream. Alexander Simon found out that the Terratec Cinergy T USB XXS is just a clone of another DiB7070P-based device. Signed-off-by:
Patrick Boettcher <pb@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Ludwig Nussel <lnussel@novell.com> Signed-off-by:
-
Steven Rostedt authored
commit ee3ece83 upstream. Due to a possible deadlock, the waking of the softirq was pushed outside of the hrtimer base locks. See commit 0c96c597 Unfortunately this allows the task to migrate after setting up the softirq and raising it. Since softirqs run a queue that is per-cpu we may raise the softirq on the wrong CPU and this will keep the queued softirq task from running. To solve this issue, this patch disables preemption around the releasing of the hrtimer lock and raising of the softirq. Signed-off-by:
Steven Rostedt <srostedt@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Pierre Ossman authored
commit bf5b1935 upstream. Even the newer ENE controllers have bugs in their DMA engine that make it too dangerous to use. Disable it until someone has figured out under which conditions it corrupts data. This has caused problems at least once, and can be found as bug report 10925 in the kernel bugzilla. Signed-off-by:
Pierre Ossman <drzeus@drzeus.cx> Signed-off-by:
-
Karl Beldan authored
commit 4fe16897 upstream Signed-off-by:
Karl Beldan <karl.beldan@gmail.com> Acked-by:
Eric Miao <eric.miao@marvell.com> Signed-off-by:
-
Philipp Zabel authored
commit 97f8571e upstream The pxa27x DMA controller defaults to 64-bit alignment. This caused the SCR reads to fail (and, depending on card type, error out) when card->raw_scr was not aligned on a 8-byte boundary. For performance reasons all scatter-gather addresses passed to pxamci_request should be aligned on 8-byte boundaries, but if this can't be guaranteed, byte aligned DMA transfers in the have to be enabled in the controller to get correct behaviour. Signed-off-by:
Philipp Zabel <philipp.zabel@gmail.com> Signed-off-by:
-
Vitaly Bordug authored
commit ba0fc709 upstream There is dma_mask in of_device upon of_platform_device_create() but we don't actually set coherent_dma_mask. This may cause weird behavior of USB subsystem using of_device USB host drivers. Signed-off-by:
Vitaly Bordug <vitb@kernel.crashing.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Herbert Xu authored
Upstream commit: 872ac874 When chainiv postpones requests it never calls their completion functions. This causes symptoms such as memory leaks when IPsec is in use. Signed-off-by:
-
James Bottomley authored
commit 081a5bcb upstream The problem here is that if the ioc faults too early in the bring up sequence (as it usually does for an irq routing problem), ioc_reset gets called before the scsi host is even allocated. This causes an oops when it later schedules a renegotiation. Fix this by checking ioc->sh before trying to renegotiate. Cc: Eric Moore <Eric.Moore@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Darren Jenkins authored
commit 43f77e91 upstream Coverity CID: 2172 RESOURCE_LEAK When pool_allocate() tries to enlarge a packet, if it can not allocate enough memory, it returns NULL without first freeing the old packet. This patch just frees the packet first. Signed-off-by:
Darren Jenkins <darrenrjenkins@gmail.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Darren Jenkins authored
commit 4fc89e39 upstream Coverity CID: 1356 RESOURCE_LEAK I found a very old patch for this that was Acked but did not get applied https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when copy_from_user() returns an un-copied data length (length != 0). The below patch should be a minimally invasive fix. Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Jaya Kumar authored
commit f31ad92f upstream This patch is a bugfix for how defio handles multiple processes manipulating the same framebuffer. Thanks to Bernard Blackham for identifying this bug. It occurs when two applications mmap the same framebuffer and concurrently write to the same page. Normally, this doesn't occur since only a single process mmaps the framebuffer. The symptom of the bug is that the mapping applications will hang. The cause is that defio incorrectly tries to add the same page twice to the pagelist. The solution I have is to walk the pagelist and check for a duplicate before adding. Since I needed to walk the pagelist, I now also keep the pagelist in sorted order. Signed-off-by:
Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Bernard Blackham <bernard@largestprime.net> Signed-off-by:
-
Eric W. Biederman authored
commit 05d81d22 upstream I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird mysterious crash in sysfs. After taking an in-depth look I realized that CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of the serial8250_ports array. Ouch!!! Don't let this happen to someone else. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Andres Salomon authored
commit bca5c2c5 upstream Cortland Setlow pointed out a bug in ov7670.c where the result from ov7670_read() was just being checked for !0, rather than <0. This made me realize that ov7670_read's semantics were rather confusing; it both fills in 'value' with the result, and returns it. This is goes against general kernel convention; so rather than fixing callers, let's fix the function. This makes ov7670_read return <0 in the case of an error, and 0 upon success. Thus, code like: res = ov7670_read(...); if (!res) goto error; .will work properly. Signed-off-by:
Cortland Setlow <csetlow@tower-research.com> Signed-off-by:
Andres Salomon <dilinger@debian.org> Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Jeff Layton authored
commit 536abdb0 upstream The current definition of wksidarr works fine on little endian arches (since cpu_to_le32 is a no-op there), but on big-endian arches, it fails to compile with this error: error: braced-group within expression allowed only inside a function The problem is that this static declaration has cpu_to_le32 embedded within it, and that expands into a function macro. We need to use __constant_cpu_to_le32() instead. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Cc: Steven French <sfrench@us.ibm.com> Signed-off-by:
-
Marcin Obara authored
commit fb0e7e11 upstream This patch adds Intel TPM TIS device HID: ICO0102 Signed-off-by:
Marcin Obara <marcin_obara@users.sourceforge.net> Acked-by:
Marcel Selhorst <tpm@selhorst.net> Acked-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
-
Eugene Surovegin authored
commit a7de3902 upstream Fix RapidIO device reference counting. Signed-of-by:
Eugene Surovegin <ebs@ebshome.net> Cc: Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Paul Gortmaker authored
commit 61ca9daa upstream The IRQ rate reported back by the RTC is incorrect when HPET is enabled. Newer hardware that has HPET to emulate the legacy RTC device gets this value wrong since after it sets the rate, it returns before setting the variable used to report the IRQ rate back to users of the device -- so the set rate and the reported rate get out of sync. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Brownell <david-b@pacbell.net> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Dmitry Adamushko authored
commit bdb21928 upstream Vegard Nossum reported a crash in kmem_cache_alloc(): BUG: unable to handle kernel paging request at da87d000 IP: [<c01991c7>] kmem_cache_alloc+0xc7/0xe0 *pde = 28180163 *pte = 1a87d160 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC Pid: 3850, comm: grep Not tainted (2.6.26-rc9-00059-gb190333 #5) EIP: 0060:[<c01991c7>] EFLAGS: 00210203 CPU: 0 EIP is at kmem_cache_alloc+0xc7/0xe0 EAX: 00000000 EBX: da87c100 ECX: 1adad71a EDX: 6b6b6b6b ESI: 00200282 EDI: da87d000 EBP: f60bfe74 ESP: f60bfe54 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 and analyzed it: "The register %ecx looks innocent but is very important here. The disassembly: mov %edx,%ecx shr $0x2,%ecx rep stos %eax,%es:(%edi) <-- the fault So %ecx has been loaded from %edx... which is 0x6b6b6b6b/POISON_FREE. (0x6b6b6b6b >> 2 == 0x1adadada.) %ecx is the counter for the memset, from here: memset(object, 0, c->objsize); i.e. %ecx was loaded from c->objsize, so "c" must have been freed. Where did "c" come from? Uh-oh... c = get_cpu_slab(s, smp_processor_id()); This looks like it has very much to do with CPU hotplug/unplug. Is there a race between SLUB/hotplug since the CPU slab is used after it has been freed?" Good analysis. Yeah, it's possible that a caller of kmem_cache_alloc() -> slab_alloc() can be migrated on another CPU right after local_irq_restore() and before memset(). The inital cpu can become offline in the mean time (or a migration is a consequence of the CPU going offline) so its 'kmem_cache_cpu' structure gets freed ( slab_cpuup_callback). At some point of time the caller continues on another CPU having an obsolete pointer... Signed-off-by:
Dmitry Adamushko <dmitry.adamushko@gmail.com> Reported-by:
Vegard Nossum <vegard.nossum@gmail.com> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Hugh Dickins authored
commit 96a8e13e upstream Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32) exec'ing an ELF without a PT_GNU_STACK program header should default to an executable stack; but this got broken by the unlimited argv feature because stack vma is now created before the right personality has been established: so breaking old binaries using nested function trampolines. Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack vm_flags used to be set, before the mprotect_fixup. Checking through our existing VM_flags, none would have changed since insert_vm_struct: so this seems safer than finding a way through the personality labyrinth. Reported-by:
<pageexec@freemail.hu> Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Firat Birlik authored
Commit 9dfd5500 upstream I would like to inform you of our zd1211 based usb wifi adapter (AirTies WUS-201), which works with the zd1211rw driver with the following device id definition. Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Peter Nixon <listuser@peternixon.net> Signed-off-by:
-
Jozsef Kadlecsik authored
Upstream commit 84ebe1cd: Lost connections was reported by Thomas Bätzler (running 2.6.25 kernel) on the netfilter mailing list (see the thread "Weird nat/conntrack Problem with PASV FTP upload"). He provided tcpdump recordings which helped to find a long lingering bug in conntrack. In TCP connection tracking, checking the lower bound of valid ACK could lead to mark valid packets as INVALID because: - We have got a "higher or equal" inequality, but the test checked the "higher" condition only; fixed. - If the packet contains a SACK option, it could occur that the ACK value was before the left edge of our (S)ACK "window": if a previous packet from the other party intersected the right edge of the window of the receiver, we could move forward the window parameters beyond accepting a valid ack. Therefore in this patch we check the rightmost SACK edge instead of the ACK value in the lower bound of valid (S)ACK test. Signed-off-by:
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Joonwoo Park authored
Upstream commit aebb6a84 The current logic has a bug which cannot find matching pattern, if the pattern is matched from the first character of target string. for example: pattern=abc, string=abcdefg pattern=a, string=abcdefg Searching algorithm should return 0 for those things. Signed-off-by:
Joonwoo Park <joonwpark81@gmail.com> Signed-off-by:
-
Dan Williams authored
commit 7a1fc53c upstream Remove the dubious attempt to prefer 'compute' over 'read'. Not only is it wrong given commit c337869d (md: do not compute parity unless it is on a failed drive), but it can trigger a BUG_ON in handle_parity_checks5(). Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Will Newton authored
commit f15e3973 upstream Remove dev_info call on disconnect. The sisusb_dev pointer may have been set to zero by sisusb_delete at this point causing an oops. The message does not provide any extra information over the standard USB subsystem output so removing it does not affect functionality. Signed-off-by:
Will Newton <will.newton@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Oliver Hartkopp authored
commit 7f2d38eb upstream Even though the CAN netlayer only deals with CAN netdevices, the netlayer interface to the userspace and to the device layer should perform some sanity checks. This patch adds several sanity checks that mainly prevent userspace apps to send broken content into the system that may be misinterpreted by some other userspace application. Signed-off-by:
Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by:
Urs Thuermann <urs.thuermann@volkswagen.de> Acked-by:
Andre Naujoks <nautsch@gmail.com> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 7ca796f4 upstream As reported by Vipul Gandhi, the current serial_match_port() doesn't work for tty-devices using dynamic major number allocation. Fix it. It oopses if you suspend a serial port with _dynamic_ major number. ATM, I think, there's only the drivers/serial/jsm/jsm_driver.c driver, that does it in-tree. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Tested-by:
Vipul Gandhi <vcgandhi1@aol.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Mike Miller authored
commit 49153998 upstream This patch changes the way we determine the maximum number of outstanding commands for each controller. Most Smart Array controllers can support up to 1024 commands, the notable exceptions are the E200 and E200i. The next generation of controllers which were just added support a mode of operation called Zero Memory Raid (ZMR). In this mode they only support 64 outstanding commands. In Full Function Raid (FFR) mode they support 1024. We have been setting the queue depth by arbitrarily assigning some value for each controller. We needed a better way to set the queue depth to avoid lots of annoying "fifo full" messages. So we made the driver a little smarter. We now read the config table and subtract 4 from the returned value. The -4 is to allow some room for ioctl calls which are not tracked the same way as io commands are tracked. Please consider this for inclusion. Signed-off-by:
Mike Miller <mike.miller@hp.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jeff Mahoney authored
commit eb35c218 upstream With the removal of struct file from the xattr code, reiserfs_file_release() isn't used anymore, so the prealloc isn't discarded. This causes hangs later down the line. This patch adds it to reiserfs_delete_inode. In most cases it will be a no-op due to it already having been called, but will avoid hangs with xattrs. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
John Blackwood authored
commit 2d5c1be8 upstream There is a bug in the output of /sys/devices/system/node/node[n]/meminfo where the Active and Inactive values are in pages instead of Kbytes. Looks like this occurred back in 2.6.20 when the code was changed over to use node_page_state(). Signed-off-by:
-
