- 24 Mar, 2008 24 commits
-
-
Sebastian Siewior authored
[ Upstream commit: 6212f2c7 ] The XTS blockmode uses a copy of the IV which is saved on the stack and may or may not be properly aligned. If it is not, it will break hardware cipher like the geode or padlock. This patch encrypts the IV in place so we don't have to worry about alignment. Signed-off-by:
Sebastian Siewior <sebastian@breakpoint.cc> Tested-by:
Stefan Hellermann <stefan@the2masters.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Joy Latten authored
[ Upstream commit: 2f40a178 ] When using aes-xcbc-mac for authentication in IPsec, the kernel crashes. It seems this algorithm doesn't account for the space IPsec may make in scatterlist for authtag. Thus when crypto_xcbc_digest_update2() gets called, nbytes may be less than sg[i].length. Since nbytes is an unsigned number, it wraps at the end of the loop allowing us to go back into loop and causing crash in memcpy. I used update function in digest.c to model this fix. Please let me know if it looks ok. Signed-off-by:
Joy Latten <latten@austin.ibm.com> Signed-off-by:
-
Jeff Garzik authored
commit 2551a13e Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Acked-by:
Mark Salyzyn <mark_salyzyn@adaptec.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
James Bottomley <James.Bottomley@HansenPartnership.com> FUJITA Tomonori notes: It didn't intend to fix a critical bug, however, it turned out that it does. Without this patch, the ips driver in 2.6.23 and 2.6.24 doesn't work at all. You can find the more details at the following thread: http://marc.info/?t=120293911900023&r=1&w=2 Signed-off-by:
-
Jan Beulich authored
commit e9427101 Its previous use in a call to on_each_cpu() was pointless, as at the time that code gets executed only one CPU is online. Further, the function can be __cpuinit, and for this to work without CONFIG_HOTPLUG_CPU setup_nmi() must also get an attribute (this one can even be __init; on 64-bits check_timer() also was lacking that attribute). Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> [ tglx@linutronix.de: backport to 2.6.24.3] Cc: Justin Piszcz <jpiszcz@lucidpixels.com> Signed-off-by:
-
James Bottomley authored
commit: e88a0c2c Date: Sun, 9 Mar 2008 11:57:56 -0500 Subject: drivers: fix dma_get_required_mask There's a bug in the current implementation of dma_get_required_mask() where it ands the returned mask with the current device mask. This rather defeats the purpose if you're using the call to determine what your mask should be (since you will at that time have the default DMA_32BIT_MASK). This bug results in any driver that uses this function *always* getting a 32 bit mask, which is wrong. Fix by removing the and with dev->dma_mask. Signed-off-by:
-
Nick Piggin authored
commit: f7009264 iov_iter_advance() skips over zero-length iovecs, however it does not properly terminate at the end of the iovec array. Fix this by checking against i->count before we skip a zero-length iov. The bug was reproduced with a test program that continually randomly creates iovs to writev. The fix was also verified with the same program and also it could verify that the correct data was contained in the file after each writev. Signed-off-by:
Nick Piggin <npiggin@suse.de> Tested-by:
"Kevin Coffman" <kwc@citi.umich.edu> Cc: "Alexey Dobriyan" <adobriyan@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Aurelien Jarno authored
x86: Clear DF before calling signal handler The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. This become a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. This is a backport of patch e40cd10c ("x86: clear DF before calling signal handler") that has been applied in 2.6.25-rc. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
-
Pete Zaitcev authored
Signed-off-by:
Pete Zaitcev <zaitcev@redhat.com> Cc: "Oliver Pinter" <oliver.pntr@gmail.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Ralf Baechle authored
Use set_irq_noprobe() to mark all MIPS interrupts as non-probe. Override that default for i8259 interrupts. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Acked-and-tested-by:
Rob Landley <rob@landley.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ralf Baechle authored
Probing non-ISA interrupts using the handle_percpu_irq as their handle_irq method may crash the system because handle_percpu_irq does not check IRQ_WAITING. This for example hits the MIPS Qemu configuration. This patch provides two helper functions set_irq_noprobe and set_irq_probe to set rsp. clear the IRQ_NOPROBE flag. The only current caller is MIPS code but this really belongs into generic code. As an aside, interrupt probing these days has become a mostly obsolete if not dangerous art. I think Linux interrupts should be changed to default to non-probing but that's subject of this patch. Signed-off-by:
-
Herbert Xu authored
Upstream commit: 21e43188 Because we use shared tfm objects in order to conserve memory, (each tfm requires 128K of vmalloc memory), BH needs to be turned off on output as that can occur in process context. Previously this was done implicitly by the xfrm output code. That was lost when it became lockless. So we need to add the BH disabling to IPComp directly. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Stephen Hemminger authored
Upstream commit: dea75bdf From: Stephen Hemminger <shemminger@linux-foundation.org> Based upon a patch by Marcel Wappler: This patch fixes a DHCP issue of the kernel: some DHCP servers (i.e. in the Linksys WRT54Gv5) are very strict about the contents of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131 page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'. These DHCP servers ignore Linux kernel's DHCP discovery packets with these two fields set to '255.255.255.255' (in contrast to popular DHCP clients, such as 'dhclient' or 'udhcpc'). This leads to a not booting system. Signed-off-by:
-
David S. Miller authored
Upstream commit: e4f8b5d4 Various RFCs have all sorts of things to say about the CS field of the DSCP value. In particular they try to make the distinction between values that should be used by "user applications" and things like routing daemons. This seems to have influenced the CAP_NET_ADMIN check which exists for IP_TOS socket option settings, but in fact it has an off-by-one error so it wasn't allowing CS5 which is meant for "user applications" as well. Further adding to the inconsistency and brokenness here, IPV6 does not validate the DSCP values specified for the IPV6_TCLASS socket option. The real actual uses of these TOS values are system specific in the final analysis, and these RFC recommendations are just that, "a recommendation". In fact the standards very purposefully use "SHOULD" and "SHOULD NOT" when describing how these values can be used. In the final analysis the only clean way to provide consistency here is to remove the CAP_NET_ADMIN check. The alternatives just don't work out: 1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing setups. 2) If we just fix the off-by-one error in the class comparison in IPV4, certain DSCP values can be used in IPV6 but not IPV4 by default. So people will just ask for a sysctl asking to override that. I checked several other freely available kernel trees and they do not make any privilege checks in this area like we do. For the BSD stacks, this goes back all the way to Stevens Volume 2 and beyond. Signed-off-by:
-
Denis V. Lunev authored
Upstream commit: 9937ded8 The result of the ip_route_output is not assigned to skb. This means that - it is leaked - possible OOPS below dereferrencing skb->dst - no ICMP message for this case Signed-off-by:
Denis V. Lunev <den@openvz.org> Signed-off-by:
-
Herbert Xu authored
Upstream commits: 28a89453 b5c15fc0 This is a long-standing bug in the IPsec IPv6 code that breaks when we emit a IPsec tunnel-mode datagram packet. The problem is that the code the emits the packet assumes the IPv6 stack will fragment it later, but the IPv6 stack assumes that whoever is emitting the packet is going to pre-fragment the packet. In the long term we need to fix both sides, e.g., to get the datagram code to pre-fragment as well as to get the IPv6 stack to fragment locally generated tunnel-mode packet. For now this patch does the second part which should make it work for the IPsec host case. Signed-off-by:
-
Matti Linnanvuori authored
Upstream commit: d8b2a4d2 There is a race in Linux kernel file net/core/dev.c, function dev_close. The function calls function dev_deactivate, which calls function dev_watchdog_down that deletes the watchdog timer. However, after that, a driver can call netif_carrier_ok, which calls function __netdev_watchdog_up that can add the watchdog timer again. Function unregister_netdevice calls function dev_shutdown that traps the bug !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after netif_running() has been cleared prevents function netif_carrier_on from calling __netdev_watchdog_up and adding the watchdog timer again. Signed-off-by:
Matti Linnanvuori <mattilinnanvuori@yahoo.com> Signed-off-by:
-
Jorge Boncompte [DTI2] authored
Upstream commit: 12aa343a Commit a0a400d7 ("[NET]: dev_mcast: add multicast list synchronization helpers") from you introduced a new field "da_synced" to struct dev_addr_list that is not properly initialized to 0. So when any of the current users (8021q, macvlan, mac80211) calls dev_mc_sync/unsync they mess the address list for both devices. The attached patch fixed it for me and avoid future problems. Signed-off-by:
Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
David S. Miller authored
Upstream commit: a4425859 Signed-off-by:
-
Matheos Worku authored
Upstream commit: 3b5bcede BMAC port alternate MAC address index needs to start at 1. Index 0 is used for the main MAC address. Signed-off-by:
Matheos Worku <matheos.worku@sun.com> Signed-off-by:
-
Matheos Worku authored
Upstream commit: fa907895 From: Matheos Worku <Matheos.Worku@Sun.COM> 1) niu_enable_alt_mac() needs to be adjusted so that the mask is computed properly for the BMAC case. 2) BMAC has 6 alt MAC addresses available, not 7. Signed-off-by:
-
David S. Miller authored
Upstream commit: 7adc3830 If all of the entropy is in the local and foreign addresses, but xor'ing together would cancel out that entropy, the current hash performs poorly. Suggested by Cosmin Ratiu: Basically, the situation is as follows: There is a client machine and a server machine. Both create 15000 virtual interfaces, open up a socket for each pair of interfaces and do SIP traffic. By profiling I noticed that there is a lot of time spent walking the established hash chains with this particular setup. The addresses were distributed like this: client interfaces were 198.18.0.1/16 with increments of 1 and server interfaces were 198.18.128.1/16 with increments of 1. As I said, there were 15000 interfaces. Source and destination ports were 5060 for each connection. So in this case, ports don't matter for hashing purposes, and the bits from the address pairs used cancel each other, meaning there are no differences in the whole lot of pairs, so they all end up in the same hash chain. Signed-off-by:
-
David S. Miller authored
Upstream commit: f0e98c38 Reported by Adrian Bunk. Just like in changeset a3f99858 ("[SPARC64]: Move kernel unaligned trap handlers into assembler file.") we have to move the assembler bits into a seperate asm file because as far as the compiler is concerned these inline bits we're doing in unaligned.c are unreachable. Signed-off-by:
-
David S. Miller authored
Upstream commits: 622eaec6 be71716e Some parts of the kernel now do things like do *_user() accesses while set_fs(KERNEL_DS) that fault on purpose. See, for example, the code added by changeset a0c1e907 ("futex: runtime enable pi and robust functionality"). That trips up the ASI sanity checking we make in do_kernel_fault(). Just remove it for now. Maybe we can add it back later with an added conditional which looks at the current get_fs() value. Also, because of the new futex validation init handler, we have to accept faults in init section text as well as the normal kernel text. Thanks to Tom Callaway for the bug report. Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 5fb7ba76 . It was incorrectly added to the .24.y stable tree and causes build breakages. Cc: Stephen Hemminger <stephen.hemminger@vyatta.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
- 26 Feb, 2008 16 commits
-
-
Greg Kroah-Hartman authored
-
Ingo Molnar authored
(no matching git id as the upstream code is rewritten) fix CPA cache attribute bug in v2.6.24. When phys_base is nonzero (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates the secondary alias address by -14 MB (depending on the configured offset). The default 64-bit kernels of Fedora and Ubuntu are affected: $ grep RELOCA /boot/config-2.6.23.9-85.fc8 CONFIG_RELOCATABLE=y $ grep RELOC /boot/config-2.6.22-14-generic CONFIG_RELOCATABLE=y and probably on many other distros as well. the bug affects all pages in the first 40 MB of physical RAM that are allocated by some subsystem that does ioremap_nocache() on them: if (__pa(address) < KERNEL_TEXT_SIZE) { Hence we might leave page table entries with inconsistent cache attributes around (pages mapped at both UnCacheable and Write-Back), and we can also set the wrong kernel text pages to UnCacheable. the effects of this bug can be random slowdowns and other misbehavior. If for example AGP allocates its aperture pages into the first 40 MB of physical RAM, then the -14 MB bug might mark random kernel texto pages as uncacheable, slowing down a random portion of the 64-bit kernel until the AGP driver is unloaded. Signed-off-by: -
Jay Vosburgh authored
patch 4fe4763c in mainline. Fix the "are we creating a duplicate" check to not compare the name if the name is NULL (meaning that the system should select a name). Bug reported by Benny Amorsen <benny+usenet@amorsen.dk>. Signed-off-by:
Jay Vosburgh <fubar@us.ibm.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Olaf Hering authored
Commit: 092ca5bd [POWERPC] Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos Commit 6d98bda7 changed the init order for chrp_pci_fixup_vt8231_ata(). It can not work anymore because either the irq is not yet set to 14 or pci_get_device() returns nothing. At least the printk() in chrp_pci_fixup_vt8231_ata() does not trigger anymore. pata_via works again on Pegasos with the change below. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Paul Mackerras <paulus@samba.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Chuck Ebbert authored
Commit: a1a98b72 Fix station address detection in smc Megahertz EM1144 PCMCIA ethernet adapter needs special handling because it has two VERS_1 tuples and the station address is in the second one. Conversion to generic handling of these fields broke it. Reverting that fixes the device. https://bugzilla.redhat.com/show_bug.cgi?id=233255 Thanks go to Jon Stanley for not giving up on this one until the problem was found. Signed-off-by:
Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Boaz Harrosh authored
commit: 61c92814 The patch: "gdth: switch to modern scsi host registration" missed one simple fact when moving a way from scsi_module.c. That is to call scsi_scan_host() on the probed host. With this the gdth driver from 2.6.24 is again able to see drives and boot. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Tested-by:
Joerg Dorchain <joerg@dorchain.net> Tested-by:
Stefan Priebe <s.priebe@allied-internet.ag> Tested-by:
Jon Chelton <jchelton@ffpglobal.com> Signed-off-by:
-
Oliver Neukum authored
commit 19028690 upstream if you fail in open() you must decrement the pm counter again. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Heiko Carstens authored
commit: d5b02b3f upstream Add missing exception table entry so that the kernel can handle proctection exceptions as well on the cs instruction. Currently only specification exceptions are handled correctly. The missing entry allows user space to crash the kernel. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Thomas Gleixner authored
commit 89d694b9 The default_disable() function was changed in commit: 76d21601 genirq: do not mask interrupts by default It removed the mask function in favour of the default delayed interrupt disabling. Unfortunately this also broke the shutdown in free_irq() when the last handler is removed from the interrupt for those architectures which rely on the default implementations. Now we can end up with a enabled interrupt line after the last handler was removed, which can result in spurious interrupts. Fix this by adding a default_shutdown function, which is only installed, when the irqchip implementation does provide neither a shutdown nor a disable function. Pointed-out-by:
Michael Hennerich <Michael.Hennerich@analog.com> Signed-off-by:
-
Thomas Gleixner authored
commit 63070a79 A CLOCK_REALTIME timer, which has an absolute expiry time less than the clock realtime offset calls with a negative delta into the clock events code and triggers the WARN_ON() there. This is a false positive and needs to be prevented. Check the result of timer->expires - timer->base->offset right away and return -ETIME right away. Thanks to Frans Pop, who reported the problem and tested the fixes. Signed-off-by:
Frans Pop <elendil@planet.nl> Signed-off-by:
-
Thomas Gleixner authored
commit: 5a7780e7 Various user space callers ask for relative timeouts. While we fixed that overflow issue in hrtimer_start(), the sites which convert relative user space values to absolute timeouts themself were uncovered. Instead of putting overflow checks into each place add a function which does the sanity checking and convert all affected callers to use it. Thanks to Frans Pop, who reported the problem and tested the fixes. Signed-off-by:
-
Christoph Lameter authored
patch 5bb983b0 in mainline. gcc 4.2 spits out an annoying warning if one casts a const void * pointer to a void * pointer. No warning is generated if the conversion is done through an assignment. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Oleg Nesterov authored
commit 41652937 Spotted by Pavel Emelyanov and Alexey Dobriyan. compat_sys_nanosleep() implicitly uses hrtimer_nanosleep_restart(), this can't work. Make a suitable compat_nanosleep_restart() helper. Introduced by commit c70878b4 hrtimer: hook compat_sys_nanosleep up to high res timer code Also, set ->addr_limit = KERNEL_DS before doing hrtimer_nanosleep(), this func was changed by the previous patch and now takes the "__user *" parameter. Thanks to Ingo Molnar for fixing the bug in this patch. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alexey Dobriyan <adobriyan@sw.ru> Cc: Pavel Emelyanov <xemul@sw.ru> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Toyo Abe <toyoa@mvista.com> Signed-off-by:
-
Oleg Nesterov authored
commit 080344b9 Spotted by Pavel Emelyanov and Alexey Dobriyan. hrtimer_nanosleep() sets restart_block->arg1 = rmtp, but this rmtp points to the local variable which lives in the caller's stack frame. This means that if sys_restart_syscall() actually happens and it is interrupted as well, we don't update the user-space variable, but write into the already dead stack frame. Introduced by commit 04c22714 hrtimer: Rework hrtimer_nanosleep to make sys_compat_nanosleep easier Change the callers to pass "__user *rmtp" to hrtimer_nanosleep(), and change hrtimer_nanosleep() to use copy_to_user() to actually update *rmtp. Small problem remains. man 2 nanosleep states that *rtmp should be written if nanosleep() was interrupted (it says nothing whether it is OK to update *rmtp if nanosleep returns 0), but (with or without this patch) we can dirty *rem even if nanosleep() returns 0. NOTE: this patch doesn't change compat_sys_nanosleep(), because it has other bugs. Fixed by the next patch. Signed-off-by:
-
Benjamin Herrenschmidt authored
patch 592a607b in mainline. It appears that with the U3 northbridge, if the processor is in NAP mode the whole time while waiting for an SMU command to complete, then the SMU will fail. It could be related to the weird backward mechanism the SMU uses to get to system memory via i2c to the northbridge that doesn't operate properly when the said bridge is in napping along with the CPU. That is on U3 at least, U4 doesn't seem to be affected. This didn't show before NO_HZ as the timer wakeup was enough to make it work it seems, but that is no longer the case. This fixes it by disabling NAP mode on those machines while an SMU command is in flight. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Jonathan Corbet authored
patch 900cf086 in mainline. So I spent a while pounding my head against my monitor trying to figure out the vmsplice() vulnerability - how could a failure to check for *read* access turn into a root exploit? It turns out that it's a buffer overflow problem which is made easy by the way get_user_pages() is coded. In particular, "len" is a signed int, and it is only checked at the *end* of a do {} while() loop. So, if it is passed in as zero, the loop will execute once and decrement len to -1. At that point, the loop will proceed until the next invalid address is found; in the process, it will likely overflow the pages array passed in to get_user_pages(). I think that, if get_user_pages() has been asked to grab zero pages, that's what it should do. Thus this patch; it is, among other things, enough to block the (already fixed) root exploit and any others which might be lurking in similar code. I also think that the number of pages should be unsigned, but changing the prototype of this function probably requires some more careful review. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
![Jorge Boncompte [DTI2]'s avatar](https://www.gravatar.com/avatar/5c0cf83a6a7ce7bbeef63cef2c3f4163?s=80&d=identicon "Jorge Boncompte [DTI2]")
