- 29 Aug, 2005 4 commits
-
-
Patrick McHardy authored
Based upon a bug report and initial patch by Ollie Wild. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
"David S. Miller" <davem@davemloft.net> Signed-off-by:
Chris Wright <chrisw@osdl.org>
-
Linus Torvalds authored
It turns out that empty distance code tables are not an error, and that a compressed block with only literals can validly have an empty table and should not be flagged as a data error. Some old versions of gzip had problems with this case, but it does not affect the zlib code in the kernel. Analysis and explanations thanks to Sergey Vlasov <vsu@altlinux.ru> Cc: Sergey Vlasov <vsu@altlinux.ru> Cc: Tavis Ormandy <taviso@gentoo.org> Cc: Tim Yamin <plasmaroo@gentoo.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Bhavesh P. Davda authored
This bug is quite subtle and only happens in a very interesting situation where a real-time threaded process is in the middle of a coredump when someone whacks it with a SIGKILL. However, this deadlock leaves the system pretty hosed and you have to reboot to recover. Not good for real-time priority-preemption applications like our telephony application, with 90+ real-time (SCHED_FIFO and SCHED_RR) processes, many of them multi-threaded, interacting with each other for high volume call processing. Acked-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Herbert Xu authored
The interface needs much redesigning if we wish to allow normal users to do this in some way. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
- 15 Aug, 2005 9 commits
-
-
Chris Wright authored
-
Rusty Russell authored
Fwd from Daniel Drake <dsd@gentoo.org>. The module code assumes noone will ever ask for a per-cpu area more than SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks sometimes asks for 32-byte alignment for the per-cpu section on a module, and if CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON(). This is obviously an unusual combination, as there have been few reports, but better to warn than die. See: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html And more recently: http://bugs.gentoo.org/show_bug.cgi?id=97006Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Howells authored
The attached patch makes sure that a keyring that failed to instantiate properly is destroyed without oopsing [CAN-2005-2099]. The problem occurs in three stages: (1) The key allocator initialises the type-specific data to all zeroes. In the case of a keyring, this will become a link in the keyring name list when the keyring is instantiated. (2) If a user (any user) attempts to add a keyring with anything other than an empty payload, the keyring instantiation function will fail with an error and won't add the keyring to the name list. (3) The keyring's destructor then sees that the keyring has a description (name) and tries to remove the keyring from the name list, which oopses because the link pointers are both zero. This bug permits any user to take down a box trivially. Signed-off-by:David Howells <dhowells@redhat.com> Signed-off-by:
-
David Howells authored
[PATCH] CAN-2005-2098 Error during attempt to join key management session can leave semaphore pinned The attached patch prevents an error during the key session joining operation from hanging future joins in the D state [CAN-2005-2098]. The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING operation has one error path that doesn't release the session management semaphore. Further attempts to get the semaphore will then sleep for ever in the D state. This can happen in four situations, all involving an attempt to allocate a new session keyring: (1) ENOMEM. (2) The users key quota being reached. (3) A keyring name that is an empty string. (4) A keyring name that is too long. Any user may attempt this operation, and so any user can cause the problem to occur. Signed-off-by:
-
Linus Torvalds authored
Add fakey 'deflateBound()' function to the in-kernel zlib routines It's not the real deflateBound() in newer zlib libraries, partly because the upcoming usage of it won't have the "stream" available, so we can't have the same interfaces anyway. This uses the new deflateBound() thing to sanity-check the input to the zlib decompressor before we even bother to start reading in the blocks. Problem noted by Tim Yamin <plasmaroo@gentoo.org> Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
Tim Yamin authored
Fix outstanding security bugs in the Linux zlib implementations. See: a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html CAN-2005-2458 b) http://bugs.gentoo.org/show_bug.cgi?id=94584 CAN-2005-2459 Signed-off-by:
Tim Yamin <plasmaroo@gentoo.org> Signed-off-by:
Tavis Ormandy <taviso@gentoo.org> Signed-off-by:
-
Andi Kleen authored
This patch fixes the SMP boot timing problem that hit various people and was introduced in 2.6.12. Please apply to stable. >From Eric Biederman sync_tsc was using smp_call_function to ask the boot processor to report it's tsc value. smp_call_function performs an IPI_send_allbutself which is a broadcast ipi. There is a window during processor startup during which the target cpu has started and before it has initialized it's interrupt vectors so it can properly process an interrupt. Receveing an interrupt during that window will triple fault the cpu and do other nasty things. Why cli does not protect us from that is beyond me. The simple fix is to match ia64 and provide a smp_call_function_single. Which avoids the broadcast and is more efficient. This certainly fixes the problem of getting stuck on boot which was very easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for the right reasons. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
Patch for 2.6.12-STABLE This fixes a bug in SRAT handling on AMD systems that was introduced with the dual core support. It would be disabled on CPUs without dual core. Just drop the bogus check. Signed-off-by:
-
Eric Dumazet authored
A kernel BUG() is triggered by a call to set_mempolicy() with a negative first argument. This is because the mode is declared as an int, and the validity check doesnt check < 0 values. Alternatively, mode could be declared as unsigned int or unsigned long. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
- 05 Aug, 2005 14 commits
-
-
Chris Wright authored
-
Dave Jones authored
Date: Thu, 28 Jul 2005 16:38:21 +0000 (-0700) Subject: powernow-k8 requires that a data structure for X-Git-Tag: v2.6.13-rc4 X-Git-Url: http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=03938c3f1062b0f279a0ef937a471d4db83702ed powernow-k8 requires that a data structure for each core be created in the _cpu_init function call. The cpufreq infrastructure doesn't call _cpu_init for the second core in each processor. Some systems crashed when _get was called with an odd-numbered core because it tried to dereference a NULL pointer since the data structure had not been created. The attached patch solves the problem by initializing data structures for all shared cores in the _cpu_init function. It should apply to 2.6.12-rc6 and has been tested by AMD and Sun. Signed-off-by:
Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Tommy Christensen authored
X-Git-Url: http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f4637b55ba960d9987a836617271659e9b7b0de8 [VLAN]: Fix early vlan adding leads to not functional device OK, I can see what's happening here. eth0 doesn't detect link-up until after a few seconds, so when the vlan interface is opened immediately after eth0 has been opened, it inherits the link-down state. Subsequently the vlan interface is never properly activated and are thus unable to transmit any packets. dev->state bits are not supposed to be manipulated directly. Something similar is probably needed for the netif_device_present() bit, although I don't know how this is meant to work for a virtual device. Signed-off-by:
-
Blaisorblade authored
CC: <stable@kernel.org> sys_get_thread_area does not memset to 0 its struct user_desc info before copying it to user space... since sizeof(struct user_desc) is 16 while the actual datas which are filled are only 12 bytes + 9 bits (across the bitfields), there is a (small) information leak. This was already committed to Linus' repository. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Andrew Morton authored
[PATCH] bio_clone fix Fix bug introduced in 2.6.11-rc2: when we clone a BIO we need to copy over the current index into it as well. It corrupts data with some MD setups. See http://bugzilla.kernel.org/show_bug.cgi?id=4946 Huuuuuuuuge thanks to Matthew Stapleton <matthew4196@gmail.com> for doggedly chasing this one down. Acked-by:
Jens Axboe <axboe@suse.de> Cc: <linux-raid@vger.kernel.org> Cc: <dm-devel@redhat.com> Signed-off-by:
-
Herbert Xu authored
[XFRM]: Fix possible overflow of sock->sk_policy Spotted by, and original patch by, Balazs Scheidler. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: Wait until all references to ip_conntrack_untracked are dropped on unload Fixes a crash when unloading ip_conntrack. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: Fix potential memory corruption in NAT code (aka memory NAT) The portptr pointing to the port in the conntrack tuple is declared static, which could result in memory corruption when two packets of the same protocol are NATed at the same time and one conntrack goes away. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: Fix deadlock in ip6_queue Already fixed in ip_queue, ip6_queue was missed. Signed-off-by:
-
Patrick McHardy authored
This is the code to load packet data into a register: k = fentry->k; if (k < 0) { ... } else { u32 _tmp, *p; p = skb_header_pointer(skb, k, 4, &_tmp); if (p != NULL) { A = ntohl(*p); continue; } } skb_header_pointer checks if the requested data is within the linear area: int hlen = skb_headlen(skb); if (offset + len <= hlen) return skb->data + offset; When offset is within [INT_MAX-len+1..INT_MAX] the addition will result in a negative number which is <= hlen. I couldn't trigger a crash on my AMD64 with 2GB of memory, but a coworker tried on his x86 machine and it crashed immediately. This patch fixes the check in skb_header_pointer to handle large positive offsets similar to skb_copy_bits. Invalid data can still be accessed using negative offsets (also similar to skb_copy_bits), anyone using negative offsets needs to verify them himself. Thanks to Thomas Vögtle <thomas.voegtle@coreworks.de> for verifying the problem by crashing his machine and providing me with an Oops. Signed-off-by: -
Siddha, Suresh B authored
malicious 32bit app can have an elf section at 0xffffe000. During exec of this app, we will have a memory leak as insert_vm_struct() is not checking for return value in syscall32_setup_pages() and thus not freeing the vma allocated for the vsyscall page. Check the return value and free the vma incase of failure. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
-
Michal Ostrowski authored
If bailing out because there is nothing to receive in rp_do_receive(), tty_ldisc_deref is not called. Failure to do so increases the ref count=20 and causes release_dev() to hang since it can't get the ref count to 0. Signed-off-by:
Michal Ostrowski <mostrows@watson.ibm.com> Signed-off-by:
-
Andrew Vasquez authored
Correct handling of fc_remote_port_add() failure case. Immediately return if fc_remote_port_add() fails to allocate resources for the rport. Original code would result in NULL pointer dereference upon failure. Reported-by:
Michael Reed <mdr@sgi.com> Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
-
Tom Rini authored
For inclusion into 2.6.12.stable, extracted from current Linus git: [PATCH] kbuild: build TAGS problem with O= make O=/dir TAGS fails with: MAKE TAGS find: security/selinux/include: No such file or directory find: include: No such file or directory find: include/asm-i386: No such file or directory find: include/asm-generic: No such file or directory The problem is in this line: ifeq ($(KBUILD_OUTPUT),) KBUILD_OUTPUT is not defined (ever) after make reruns itself. This line is used in the TAGS, tags, and cscope makes. Signed-off-by:George Anzinger <george@mvista.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
- 15 Jul, 2005 11 commits
-
-
Greg KH authored
-
Wen-chien Jesse Sung authored
This up() should be down() instead. Signed-off-by:
Wen-chien Jesse Sung <jesse@cola.voip.idv.tw> Signed-off-by:
-
blaisorblade@yahoo.it authored
From: Jeff Dike <jdike@addtoit.com>, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Revert the following patch, because of miscompilation problems in different environments leading to UML not working *at all* in TT mode; it was merged lately in 2.6 development cycle, a little after being written, and has caused problems to lots of people; I know it's a bit too long, but it shouldn't have been merged in first place, so I still apply for inclusion in the -stable tree. Anyone using this feature currently is either using some older kernel (some reports even used 2.6.12-rc4-mm2) or using this patch, as included in my -bs patchset. For now there's not yet a fix for this patch, so for now the best thing is to drop it (which was widely reported to give a working kernel). "Convert the boot-time host ptrace testing from clone to fork. They were essentially doing fork anyway. This cleans up the code a bit, and makes valgrind a bit happier about grinding it." URL: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=98fdffccea6cc3fe9dba32c0fcc310bcb5d71529Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
KAMBAROV, ZAUR authored
We add a check of the return value of tty_ldisc_ref(), which is checked 7 out of 8 times, e.g.: 149 ld = tty_ldisc_ref(tty); 150 if (ld != NULL) { 151 if (ld->set_termios) 152 (ld->set_termios)(tty, &old_termios); 153 tty_ldisc_deref(ld); 154 } This defect was found automatically by Coverity Prevent, a static analysis tool. (akpm: presumably `ld' is never NULL. Oh well) Signed-off-by:Zaur Kambarov <zkambarov@coverity.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Michael Krufky authored
Changed hue offset to 128 to correct behavior in cx88 cards. Previously, setting 0% or 100% hue was required to avoid blue/green people on screen. Now, 50% Hue means no offset, just like bt878 stuff. Signed-off-by:
Michael Krufky <mkrufky@m1k.net> Signed-off-by:
Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by:
-
Kylene Jo Hall authored
A problem was reported that the tpm driver was interfereing with networking on the 8139 chipset. The tpm driver was using a hard coded the memory address instead of the value the BIOS was putting the chip at. This was in the tpm_lpc_bus_init function. That function can be replaced with querying the value at Vendor specific locations. This patch replaces all calls to tpm_lpc_bus_init and the hardcoding of the base address with a lookup of the address at the correct vendor location. Signed-off-by:
Kylene Hall <kjhall@us.ibm.com> Signed-off-by:
-
Ralf Baechle authored
Drivers really only work well in SMP if they actually can be selected. This is a leftover from the time when the 6pack drive only used to be a bitrotten variant of the slip driver. Signed-off-by:
Ralf Baechle DL5RB <ralf@linux-mips.org> Signed-off-by:
-
David S. Miller authored
[SHAPER]: Switch to spinlocks. Dave, you were right and the sleeping locks in shaper were broken. Markus Kanet noticed this and also tested the patch below that switches locking to spinlocks. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
john stultz authored
As part of my timeofday rework, I've been looking at the NTP code and I noticed that the PPC architecture is apparently misusing the NTP's time_offset (it is a terrible name!) value as some form of timezone offset. This could cause problems when time_offset changed by the NTP code. This patch changes the PPC code so it uses a more clear local variable: timezone_offset. Signed-off-by:
John Stultz <johnstul@us.ibm.com> Acked-by:
Tom Rini <trini@kernel.crashing.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: Revert nf_reset change Revert the nf_reset change that caused so much trouble, drop conntrack references manually before packets are queued to packet sockets. Adapted for 2.6.12 by Daniel Drake <dsd@gentoo.org> Signed-off-by:
Phil Oester <kernel@linuxace.com> Signed-off-by:
-
Alexander Nyberg authored
If ACPI doesn't find an irq listed, don't accept 0 as a valid PCI irq. That zero just means that nothing else found any irq information either. Fixes http://bugme.osdl.org/show_bug.cgi?id=4824Signed-off-by:
-
- 29 Jun, 2005 2 commits
-
-
Chris Wright authored
-
David S. Miller authored
1) netlink_release() should only decrement the hash entry count if the socket was actually hashed. This was causing hash->entries to underflow, which resulting in all kinds of troubles. On 64-bit systems, this would cause the following conditional to erroneously trigger: err = -ENOMEM; if (BITS_PER_LONG > 32 && unlikely(hash->entries >= UINT_MAX)) goto err; 2) netlink_autobind() needs to propagate the error return from netlink_insert(). Otherwise, callers will not see the error as they should and thus try to operate on a socket with a zero pid, which is very bad. However, it should not propagate -EBUSY. If two threads race to autobind the socket, that is fine. This is consistent with the autobind behavior in other protocols. So bug #1 above, combined with this one, resulted in hangs on netlink_sendmsg() calls to the rtnetlink socket. We'd try to do the user sendmsg() with the socket's pid set to zero, later we do a socket lookup using that pid (via the value we stashed away in NETLINK_CB(skb).pid), but that won't give us the user socket, it will give us the rtnetlink socket. So when we try to wake up the receive queue, we dive back into rtnetlink_rcv() which tries to recursively take the rtnetlink semaphore. Thanks to Jakub Jelink for providing backtraces. Also, thanks to Herbert Xu for supplying debugging patches to help track this down, and also finding a mistake in an earlier version of this fix. Signed-off-by:
-
