- 07 Nov, 2011 40 commits
-
-
Jouni Malinen authored
commit 1b9ca027 upstream. Incorrect variable was used in validating the akm_suites array from NL80211_ATTR_AKM_SUITES. In addition, there was no explicit validation of the array length (we only have room for NL80211_MAX_NR_AKM_SUITES). This can result in a buffer write overflow for stack variables with arbitrary data from user space. The nl80211 commands using the affected functionality require GENL_ADMIN_PERM, so this is only exposed to admin users. Signed-off-by:
Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mark Salyzyn authored
commit 24926dad upstream. In an enclosure model where there are chaining expanders to a large body of storage, it was discovered that libsas, responding to a broadcast event change, would only revalidate the domain of first child expander in the list. The issue is that the pointer value to the discovered source device was used to break out of the loop, rather than the content of the pointer. This still remains non-compliant as the revalidate domain code is supposed to loop through all child expanders, and not stop at the first one it finds that reports a change count. However, the design of this routine does not allow multiple device discoveries and that would be a more complicated set of patches reserved for another day. We are fixing the glaring bug rather than refactoring the code. Signed-off-by:
Mark Salyzyn <msalyzyn@us.xyratex.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Vasily Averin authored
commit d0efab26 upstream. scsi reset on hardware with enabled MSI interrupts generates WARNING message [11027.798722] aacraid: Host adapter abort request (0,0,0,0) [11027.798814] aacraid: Host adapter reset request. SCSI hang ? [11087.762237] aacraid: SCSI bus appears hung [11135.082543] ------------[ cut here ]------------ [11135.082646] WARNING: at drivers/pci/msi.c:658 pci_enable_msi_block+0x251/0x290() Signed-off-by:
Vasily Averin <vvs@sw.ru> Acked-by:
Mark Salyzyn <mark_salyzyn@us.xyratex.com> Signed-off-by:
-
James Bottomley authored
commit 96067723 upstream. Following reports on the list, it looks like the 3e-9xxx driver will leak dma mappings every time we get a transient queueing error back from the card. This is because it maps the sg list in the routine that sends the command, but doesn't unmap again in the transient failure path (even though the command is sent back to the block layer). Fix by unmapping before returning the status. Reported-by:
Chris Boot <bootc@bootc.net> Tested-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 5fe6e015 upstream. When the headphone pin is assigned as primary output to line_out_pins[], the automatic HP-pin assignment by ASSID must be suppressed. Otherwise a wrong pin might be assigned to the headphone and breaks the auto-mute. Reference: https://bugzilla.novell.com/show_bug.cgi?id=716104Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Michael Chan authored
commit db1d350f upstream. During NETDEV_UP, we use symbol_get() to get the net driver's cnic probe function. This sometimes doesn't work if NETDEV_UP happens right after NETDEV_REGISTER and the net driver is still running module init code. As a result, the cnic device may not be discovered. We fix this by probing on all NETDEV events if the device's netif_running state is up. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Mike Christie authored
commit 74dcd0ec upstream. Have libiscsi_tcp have upper layers allocate the LLD data along with the iscsi_cls_conn struct, so it is refcounted. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Peter Huewe authored
commit 3321c07a upstream. Since the buffer might contain security related data it might be a good idea to zero the buffer after we have copied it to userspace. This got assigned CVE-2011-1162. Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Peter Huewe authored
commit 6b07d30a upstream. This patch changes the call of tpm_transmit by supplying the size of the userspace buffer instead of TPM_BUFSIZE. This got assigned CVE-2011-1161. [The first hunk didn't make sense given one could expect way less data than TPM_BUFSIZE, so added tpm_transmit boundary check over bufsiz instead The last parameter of tpm_transmit() reflects the amount of data expected from the device, and not the buffer size being supplied to it. It isn't ideal to parse it directly, so we just set it to the maximum the input buffer can handle and let the userspace API to do such job.] Signed-off-by:
-
Hendrik Brueckner authored
commit 8c2381af upstream. Currently, the hvc_console_print() function drops console output if the hvc backend's put_chars() returns 0. This patch changes this behavior to allow a retry through returning -EAGAIN. This change also affects the hvc_push() function. Both functions are changed to handle -EAGAIN and to retry the put_chars() operation. If a hvc backend returns -EAGAIN, the retry handling differs: - hvc_console_print() spins to write the complete console output. - hvc_push() behaves the same way as for returning 0. Now hvc backends can indirectly control the way how console output is handled through the hvc console layer. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Acked-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Marek Vasut authored
commit 30885909 upstream. This device can be found in Acer Iconia TAB W500 tablet dock. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
-
Michal Sroczynski authored
commit 8d48fdf6 upstream. PL2303: correctly handle baudrates above 115200 Signed-off-by:
Michal Sroczynski <msroczyn@gmail.com> Signed-off-by:
-
Rajkumar Manoharan authored
commit aa3d7eef upstream. During the association, the regulatory is updated by country IE that reaps the previously found beacons. The impact is that after a STA disconnects *or* when for any reason a regulatory domain change happens the beacon hint flag is not cleared therefore preventing future beacon hints to be learned. This is important as a regulatory domain change or a restore of regulatory settings would set back the passive scan and no-ibss flags on the channel. This is the right place to do this given that it covers any regulatory domain change. Reviewed-by:
Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
-
Manual Munz authored
commit 8c23516f upstream. In ad-hoc mode, driver b43 does not issue beacons. Signed-off-by:
Manual Munz <freifunk@somakoma.de> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Jeff Layton authored
commit 9438fabb upstream. The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. Fix this by making the name_len an unsigned value in CIFSFindNext. Reported-by:
Darren Lavender <dcl@hppine99.gbr.hp.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
David Henningsson authored
commit 2e1210bc upstream. This patch fixes "Surround Speaker Playback Volume" being cut off. (Commit b4dabfc4 was probably meant to fix this, but it fixed only the "Switch" name, not the "Volume" name.) Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Mark Brown authored
commit 747da0f8 upstream. We need to report the entire jack state to the core jack code, not just the bits that were being updated by the caller, otherwise the status reported by other detection methods will be omitted from the state seen by userspace. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Jeff Kirsher authored
commit e2faeec2 upstream. The checksum field in the EEPROM on HPPA is really not a checksum but a signature (0x16d6). So allow 0x16d6 as the matching checksum on HPPA systems. This issue is present on longterm/stable kernels, I have verified that this patch is applicable back to at least 2.6.32.y kernels. v2- changed ifdef to use CONFIG_PARISC instead of __hppa__ CC: Guy Martin <gmsoft@tuxicoman.be> CC: Rolf Eike Beer <eike-kernel@sf-tec.de> CC: Matt Turner <mattst88@gmail.com> Reported-by:
Mikulas Patocka <mikulas@artax.kerlin.mff.cuni.cz> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Andrew Vasquez authored
commit 58b48576 upstream. Transitioning to a LOOP_UPDATE loop-state could cause the driver to miss normal link/target processing. LOOP_UPDATE is a crufty artifact leftover from at time the driver performed it's own internal command-queuing. Safely remove this state. Signed-off-by:
Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Randy Dunlap authored
commit f470e5ae upstream. Fix section mismatch warning: WARNING: drivers/net/irda/smsc-ircc2.o(.devinit.text+0x1a7): Section mismatch in reference from the function smsc_ircc_pnp_probe() to the function .init.text:smsc_ircc_open() Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Venkateswararao Jujjuri (JV) authored
commit c9ffb05c upstream. msize represents the maximum PDU size that includes P9_IOHDRSZ. Signed-off-by: Venkateswararao Jujjuri "<jvrao@linux.vnet.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Eric Van Hensbergen <ericvh@gmail.com> Signed-off-by:
-
Aneesh Kumar K.V authored
commit 5034990e upstream. free the fid even in case of failed clunk. Signed-off-by:
-
Eric Van Hensbergen authored
commit b85f7d92 upstream. There was a BUG_ON to protect against a bad id which could be dealt with more gracefully. Reported-by:
Natalie Orlin <norlin@us.ibm.com> Signed-off-by:
-
NeilBrown authored
commit 27a7b260 upstream. 0.90 metadata uses an unsigned 32bit number to count the number of kilobytes used from each device. This should allow up to 4TB per device. However we multiply this by 2 (to get sectors) before casting to a larger type, so sizes above 2TB get truncated. Also we allow rdev->sectors to be larger than 4TB, so it is possible for the array to be resized larger than the metadata can handle. So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in used. Also the sanity check at the end of super_90_load should include level 1 as it used ->size too. (RAID0 and Linear don't use ->size at all). Reported-by:
Pim Zandbergen <P.Zandbergen@macroscoop.nl> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Sudhakar Rajashekhara authored
commit 810198bc upstream. DA850/OMAP-L138 EMAC driver uses random mac address instead of a fixed one because the mac address is not stuffed into EMAC platform data. This patch provides a function which reads the mac address stored in SPI flash (registered as MTD device) and populates the EMAC platform data. The function which reads the mac address is registered as a callback which gets called upon addition of MTD device. NOTE: In case the MAC address stored in SPI flash is erased, follow the instructions at [1] to restore it. [1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash Modifications in v2: Guarded registering the mtd_notifier only when MTD is enabled. Earlier this was handled using mtd_has_partitions() call, but this has been removed in Linux v3.0. Modifications in v3: a. Guarded da850_evm_m25p80_notify_add() function and da850evm_spi_notifier structure with CONFIG_MTD macros. b. Renamed da850_evm_register_mtd_user() function to da850_evm_setup_mac_addr() and removed the struct mtd_notifier argument to this function. c. Passed the da850evm_spi_notifier structure to register_mtd_user() function. Modifications in v4: Moved the da850_evm_setup_mac_addr() function within the first CONFIG_MTD ifdef construct. Signed-off-by:
Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit ed467e69 upstream. We have hit a couple of customer bugs where they would like to use those parameters to run an UP kernel - but both of those options turn of important sources of interrupt information so we end up not being able to boot. The correct way is to pass in 'dom0_max_vcpus=1' on the Xen hypervisor line and the kernel will patch itself to be a UP kernel. Fixes bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637308Acked-by:
Ian Campbell <Ian.Campbell@eu.citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Igor Mammedov authored
commit d198d499 upstream. If vmalloc page_fault happens inside of interrupt handler with interrupts disabled then on exit path from exception handler when there is no pending interrupts, the following code (arch/x86/xen/xen-asm_32.S:112): cmpw $0x0001, XEN_vcpu_info_pending(%eax) sete XEN_vcpu_info_mask(%eax) will enable interrupts even if they has been previously disabled according to eflags from the bounce frame (arch/x86/xen/xen-asm_32.S:99) testb $X86_EFLAGS_IF>>8, 8+1+ESP_OFFSET(%esp) setz XEN_vcpu_info_mask(%eax) Solution is in setting XEN_vcpu_info_mask only when it should be set according to cmpw $0x0001, XEN_vcpu_info_pending(%eax) but not clearing it if there isn't any pending events. Reproducer for bug is attached to RHBZ 707552 Signed-off-by:
Igor Mammedov <imammedo@redhat.com> Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Sonny Rao authored
commit 5b339bdf upstream. We ran into an issue where it looks like we're not properly ignoring a pci device with a non-good status property when we walk the device tree and instanciate the Linux side PCI devices. However, the EEH init code does look for the property and disables EEH on these devices. This leaves us in an inconsistent where we are poking at a supposedly bad piece of hardware and RTAS will block our config cycles because EEH isn't enabled anyway. Signed-of-by:
Sonny Rao <sonnyrao@linux.vnet.ibm.com> Signed-off-by:
-
Yang Li authored
commit 38e1313f upstream. Since commit 57b150cc, desc->affinity of an irq is changed after calling desc->chip->set_affinity. Therefore we need to fix the irq_choose_cpu() not to depend on the desc->affinity for new mask. Signed-off-by:
Jiajun Wu <b06378@freescale.com> Signed-off-by:
Li Yang <leoli@freescale.com> Signed-off-by:
-
NeilBrown authored
commit 1b6afa17 upstream. I don't know what I was thinking putting 'rcu' after a dynamically sized array! The array could still be in use when we call rcu_free() (That is the point) so we mustn't corrupt it. Signed-off-by:
-
Marek Marczykowski authored
commit 4352b47a upstream. barrier variable is int, not long. This overflow caused another variable override: "err" (in PV code) and "binfo" (in xenlinux code - drivers/xen/blkfront/blkfront.c). The later caused incorrect device flags (RO/removable etc). Signed-off-by:
Marek Marczykowski <marmarek@mimuw.edu.pl> Acked-by:
Ian Campbell <Ian.Campbell@citrix.com> [v1: Changed title] Signed-off-by:
-
Michal Schmidt authored
commit d1dc7abf upstream. Suppose that several linear skbs of the same flow were received by GRO. They were thus merged into one skb with a frag_list. Then a new skb of the same flow arrives, but it is a paged skb with data starting in its frags[]. Before adding the skb to the frag_list skb_gro_receive() will of course adjust the skb to throw away the headers. It correctly modifies the page_offset and size of the frag, but it leaves incorrect information in the skb: ->data_len is not decreased at all. ->len is decreased only by headlen, as if no change were done to the frag. Later in a receiving process this causes skb_copy_datagram_iovec() to return -EFAULT and this is seen in userspace as the result of the recv() syscall. In practice the bug can be reproduced with the sfc driver. By default the driver uses an adaptive scheme when it switches between using napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is reproduced when under rx load with enough successful GRO merging the driver decides to switch from the former to the latter. Manual control is also possible, so reproducing this is easy with netcat: - on machine1 (with sfc): nc -l 12345 > /dev/null - on machine2: nc machine1 12345 < /dev/zero - on machine1: echo 1 > /sys/module/sfc/parameters/rx_alloc_method # use skbs echo 2 > /sys/module/sfc/parameters/rx_alloc_method # use pages - See that nc has quit suddenly. [v2: Modified by Eric Dumazet to avoid advancing skb->data past the end and to use a temporary variable.] Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 226917b0 (upstream ea530692 and a68e5c94 and ce5f6824 all mushed together) as Jonathan Nieder reports that this causes a regression on some hardware. More details can be found at http://bugs.debian.org/622259 Cc: Jonathan Nieder <jrnieder@gmail.com> Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: Len Brown <len.brown@intel.com> Signed-off-by:
-
Herbert Xu authored
commit 0aa68271 upstream. Currently we disallow GSO packets on the IPv6 forward path. This patch fixes this. Note that I discovered that our existing GSO MTU checks (e.g., IPv4 forwarding) are buggy in that they skip the check altogether, when they really should be checking gso_size + header instead. I have also been lazy here in that I haven't bothered to segment the GSO packet by hand before generating an ICMP message. Someone should add that to be 100% correct. Reported-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Apollon Oikonomopoulos <apoikos@gmail.com> Signed-off-by:
Faidon Liambotis <paravoid@debian.org> Signed-off-by:
-
Sridhar Samudrala authored
commit 8e1e8a47 upstream. Found this problem when testing IPv6 from a KVM guest to a remote host via e1000e device on the host. The following patch fixes the check for IPv6 GSO packet in Intel ethernet drivers to use skb_is_gso_v6(). SKB_GSO_DODGY is also set when packets are forwarded from a guest. Signed-off-by:
Sridhar Samudrala <sri@us.ibm.com> Signed-off-by:
-
Stratos Psomadakis authored
Fix broken backport for IPv6 tunnels in 2.6.32-longterm kernels. upstream commit d5aa407f ("tunnels: fix netns vs proto registration ordering") , which was included in 2.6.32.44-longterm, was not backported correctly, and results in a NULL pointer dereference in ip6_tunnel.c for longterm kernels >=2.6.32.44 Use [un]register_pernet_gen_device() instead of [un]register_pernet_device() to fix it. Signed-off-by:
Stratos Psomadakis <psomas@gentoo.org> Cc: Wolfgang Walter <wolfgang.walter@stwm.de> Cc: Tim Gardner <tim.gardner@canonical.com> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Ian Campbell authored
commit 4a0342ca upstream. CC arch/sparc/kernel/pcic.o arch/sparc/kernel/pcic.c: In function 'pcic_probe': arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds] arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds] cc1: all warnings being treated as errors I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear to be 4 instructions long and I presume from the usage that instructions are int sized. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
David S. Miller authored
commit 5598473a upstream. If we can't push the pending register windows onto the user's stack, we disallow signal delivery even if the signal would be delivered on a valid seperate signal stack. Add a register window save area in the signal frame, and store any unsavable windows there. On sigreturn, if any windows are still queued up in the signal frame, try to push them back onto the stack and if that fails we kill the process immediately. This allows the debug/tst-longjmp_chk2 glibc test case to pass. Signed-off-by:
-
Daniel Schwierzeck authored
commit fbe5e29e upstream. This oops have been already fixed with commit 27141666 atm: [br2684] Fix oops due to skb->dev being NULL It happens that if a packet arrives in a VC between the call to open it on the hardware and the call to change the backend to br2684, br2684_regvcc processes the packet and oopses dereferencing skb->dev because it is NULL before the call to br2684_push(). but have been introduced again with commit b6211ae7 atm: Use SKB queue and list helpers instead of doing it by-hand. Signed-off-by:
Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 543cc38c upstream. When hibernating ->resume may not be called by usb core, but disconnect and probe instead, so we do not increase the counter after decreasing it in ->supend. As a result we free memory early, and get crash when unplugging usb dongle. BUG: unable to handle kernel paging request at 6b6b6b9f IP: [<c06909b0>] driver_sysfs_remove+0x10/0x30 *pdpt = 0000000034f21001 *pde = 0000000000000000 Pid: 20, comm: khubd Not tainted 3.1.0-rc1-wl+ #20 LENOVO 6369CTO/6369CTO EIP: 0060:[<c06909b0>] EFLAGS: 00010202 CPU: 1 EIP is at driver_sysfs_remove+0x10/0x30 EAX: 6b6b6b6b EBX: f52bba34 ECX: 00000000 EDX: 6b6b6b6b ESI: 6b6b6b6b EDI: c0a0ea20 EBP: f61c9e68 ESP: f61c9e64 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process khubd (pid: 20, ti=f61c8000 task=f6138270 task.ti=f61c8000) Call Trace: [<c06909ef>] __device_release_driver+0x1f/0xa0 [<c0690b20>] device_release_driver+0x20/0x40 [<c068fd64>] bus_remove_device+0x84/0xe0 [<c068e12a>] ? device_remove_attrs+0x2a/0x80 [<c068e267>] device_del+0xe7/0x170 [<c06d93d4>] usb_disconnect+0xd4/0x180 [<c06d9d61>] hub_thread+0x691/0x1600 [<c0473260>] ? wake_up_bit+0x30/0x30 [<c0442a39>] ? complete+0x49/0x60 [<c06d96d0>] ? hub_disconnect+0xd0/0xd0 [<c06d96d0>] ? hub_disconnect+0xd0/0xd0 [<c0472eb4>] kthread+0x74/0x80 [<c0472e40>] ? kthread_worker_fn+0x150/0x150 [<c0809b3e>] kernel_thread_helper+0x6/0x10 Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
