- 09 Dec, 2010 40 commits
-
-
Laurent Pinchart authored
commit c4ed8c66 upstream. At least one 5986:0241 webcam model includes vendor-specific descriptors at the end of its streaming interface descriptors. Print an information UVC_TRACE_DESCR message and try to continue parsing the descriptors rather than bailing out with an error. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: maximilian attems <max@stro.at> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Luke Macken authored
commit a5757c2a upstream. Enable the EFI framebuffer on 14 more Macs, including the iMac11,1 iMac10,1 iMac8,1 Macmini3,1 Macmini4,1 MacBook5,1 MacBook6,1 MacBook7,1 MacBookPro2,2 MacBookPro5,2 MacBookPro5,3 MacBookPro6,1 MacBookPro6,2 and MacBookPro7,1 Information gathered from various user submissions. https://bugzilla.redhat.com/show_bug.cgi?id=528232 http://ubuntuforums.org/showthread.php?t=1557326 [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Luke Macken <lmacken@redhat.com> Signed-off-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Thomas Gerlach authored
commit 8a3bdfe6 upstream. Description of patch: --------------------- This is a patch for the EFI framebuffer driver to enable the framebuffer of the NVIDIA 9400M as found in MacBook Pro (MBP) 5,1 and up. The framebuffer of the NVIDIA graphic cards are located at the following addresses in memory: 9400M: 0xC0010000 9600M GT: 0xB0030000 The patch delivered right here only provides the memory location of the framebuffer of the 9400M device. The 9600M GT is not covered. It is assumed that the 9400M is used when powered up the MBP. The information which device is currently powered and in use is stored in the 64 bytes large EFI variable "gpu-power-prefs". More specifically, byte 0x3B indicates whether 9600M GT (0x00) or 9400M (0x01) is online. The PCI bus IDs are the following: 9400M: PCI 03:00:00 9600M GT: PCI 02:00:00 The EFI variables can be easily read-out and manipulated with "rEFIt", an MBP specific bootloader tool. For more information on how handle rEFIt and EFI variables please consult "http://refit.sourceforge.net" and "http://ubuntuforums.org/archive/index.php/t-1076879.html". IMPORTANT NOTE: The information on how to activate the 9400M device given at "ubuntuforums.org" is not correct, since it states gpu-power-prefs[0x3B] = 0x00 -> 9400M (PCI 02:00:00) gpu-power-prefs[0x3B] = 0x01 -> 9600M GT (PCI 03:00:00) Actually, the assignment of the values and the PCI bus IDs are swapped. Suggestions: ------------ To cover framebuffers of both 9400M and 9600M GT, I would suggest to implement a conditional on "gpu-power-prefs". Depending on the value of byte 0x3B, the according framebuffer is selected. However, this requires kernel access to the EFI variables. [akpm@linux-foundation.org: rename optname, per Peter Jones] Signed-off-by:
Thomas Gerlach <t.m.gerlach@freenet.de> Acked-by:
-
Jack Steiner authored
commit 36ac4b98 upstream. Fix calculation of "max_pnode" for systems where the the highest blade has neither cpus or memory. (And, yes, although rare this does occur). Signed-off-by:
Jack Steiner <steiner@sgi.com> LKML-Reference: <20100910150808.GA19802@sgi.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: maximilian attems <max@stro.at> Signed-off-by:
-
Jack Steiner authored
commit 2acebe9e upstream. SGI:UV: Delete extra boot messages that describe the system topology. These messages are no longer useful. Signed-off-by:
-
David S. Miller authored
[ Upstream commit c2785259 ] Explicitly clear the "in-syscall" bit when we have no signal handler and back up the program counters to back up the system call. Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 392c2180 ] Don't invoke the signal handler tracehook in that situation either. Reported-by:
-
David S. Miller authored
[ Upstream commit 05c5e769 ] If another cpu does a very wide munmap() on the signal frame area, it can tear down the page table hierarchy from underneath us. Borrow an idea from the 64-bit fault path's get_user_insn(), and disable cross call interrupts during the page table traversal to lock them in place while we operate. Reported-by:
-
Robin Holt authored
[ Upstream fixed this in a different way as parts of the commits: 8d987e5c (net: avoid limits overflow) a9febbb4 (sysctl: min/max bounds are optional) 27b3d80a (sysctl: fix min/max handling in __do_proc_doulongvec_minmax()) -DaveM ] On a 16TB x86_64 machine, sysctl_tcp_mem[2], sysctl_udp_mem[2], and sysctl_sctp_mem[2] can integer overflow. Set limit such that they are maximized without overflowing. Signed-off-by:
Robin Holt <holt@sgi.com> To: "David S. Miller" <davem@davemloft.net> Cc: Willy Tarreau <w@1wt.eu> Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi> Cc: James Morris <jmorris@namei.org> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Vlad Yasevich <vladislav.yasevich@hp.com> Cc: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by:
-
Jarek Poplawski authored
gianfar: Fix crashes on RX path (Was Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic) [ Upstream commit 0d1fe1111c667e9c713d7efc7ae468a605f236a4 ] The rx_recycle queue is global per device but can be accesed by many napi handlers at the same time, so it needs full skb_queue primitives (with locking). Otherwise, various crashes caused by broken skbs are possible. This patch resolves, at least partly, bugzilla bug 19692. (Because of some doubts that there could be still something around which is hard to reproduce my proposal is to leave this bug opened for a month.) Fixes commit: 0fd56bb5 ("gianfar: Add support for skb recycling") Reported-by:
emin ak <eminak71@gmail.com> Tested-by:
Jarek Poplawski <jarkao2@gmail.com> CC: Andy Fleming <afleming@freescale.com> Signed-off-by:
-
Antonio Ospite authored
commit e42dee9a upstream. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid] [...] This is reproducible by disconnecting the device while userspace writes to dev node in a loop and doesn't check return values in order to exit the loop. Signed-off-by:
Antonio Ospite <ospite@studenti.unina.it> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Antonio Ospite authored
commit d20d5ffa upstream. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [<ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid] [...] This is reproducible by disconnecting the device while userspace does ioctl in a loop and doesn't check return values in order to exit the loop. Signed-off-by:
-
Jeff Mahoney authored
commit 0f04cfd0 upstream. While reviewing commit 1c40be12, I audited other users of tc_action_ops->dump for information leaks. That commit covered almost all of them but act_police still had a leak. opt.limit and opt.capab aren't zeroed out before the structure is passed out. This patch uses the C99 initializers to zero everything unused out. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Acked-by:
-
Larry Finger authored
commit f36d83a8 upstream. This driver issues a kernel panic over conditions that do not justify such drastic action. Change these to log entries with a stack dump. This patch fixes the system crash reported in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-and-Tested-by:
Robie Basik <rb-oss-3@justgohome.co.uk> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 3bad28ec and 2a767fda upstream merged together. They should not be writable by any user Reported-by:
-
James Jones authored
commit 0e91ec0c upstream. The find_next_bit, find_first_bit, find_next_zero_bit and find_first_zero_bit functions were not properly clamping to the maxbit argument at the bit level. They were instead only checking maxbit at the byte level. To fix this, add a compare and a conditional move instruction to the end of the common bit-within-the- byte code used by all the functions and be sure not to clobber the maxbit argument before it is used. Reviewed-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Tested-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
James Jones <jajones@nvidia.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Will Deacon authored
commit 1142b71d upstream. Commit 8b592783 added a Thumb-2 variant of usracc which, when it is called with \rept=2, calls usraccoff once with an offset of 0 and secondly with a hard-coded offset of 4 in order to avoid incrementing the pointer again. If \inc != 4 then we will store the data to the wrong offset from \ptr. Luckily, the only caller that passes \rept=2 to this function is __clear_user so we haven't been actively corrupting user data. This patch fixes usracc to pass \inc instead of #4 to usraccoff when it is called a second time. Reported-by:
Tony Thompson <tony.thompson@arm.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Pekka Enberg authored
commit 63bfd738 upstream. As pointed out by Linus, commit dab5855b ("perf_counter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to merging. Fix the problem by moving perf_event_mmap() hook to mprotect_fixup(). Note: there's another successful return path from mprotect_fixup() if old flags equal to new flags. We don't, however, need to call perf_event_mmap() there because 'perf' already knows the VMA is executable. Reported-by:
Dave Jones <davej@redhat.com> Analyzed-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
-
Dan Rosenberg authored
commit 3c6f27bf upstream. A single uninitialized padding byte is leaked to userspace. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
-
Steven J. Magnani authored
commit 04c34961 upstream. Depending on processor speed, page size, and the amount of memory a process is allowed to amass, cleanup of a large VM may freeze the system for many seconds. This can result in a watchdog timeout. Make sure other tasks receive some service when cleaning up large VMs. Signed-off-by:
Steven J. Magnani <steve@digidescorp.com> Cc: Greg Ungerer <gerg@snapgear.com> Reviewed-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
Uwe Kleine-König authored
commit d1d73578 upstream. According to the comment describing ops_lock in the definition of struct backlight_device and when comparing with other functions in backlight.c the mutex must be hold when checking ops to be non-NULL. Fixes a problem added by c835ee7f ("backlight: Add suspend/resume support to the backlight core") in Jan 2009. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Richard Purdie <rpurdie@linux.intel.com> Signed-off-by:
-
Will Newton authored
commit 69e83dad upstream. Disable the winch irq early to make sure we don't take an interrupt part way through the freeing of the handler data, resulting in a crash on shutdown: winch_interrupt : read failed, errno = 9 fd 13 is losing SIGWINCH support ------------[ cut here ]------------ WARNING: at lib/list_debug.c:48 list_del+0xc6/0x100() list_del corruption, next is LIST_POISON1 (00100100) 082578c8: [<081fd77f>] dump_stack+0x22/0x24 082578e0: [<0807a18a>] warn_slowpath_common+0x5a/0x80 08257908: [<0807a23e>] warn_slowpath_fmt+0x2e/0x30 08257920: [<08172196>] list_del+0xc6/0x100 08257940: [<08060244>] free_winch+0x14/0x80 08257958: [<080606fb>] winch_interrupt+0xdb/0xe0 08257978: [<080a65b5>] handle_IRQ_event+0x35/0xe0 08257998: [<080a8717>] handle_edge_irq+0xb7/0x170 082579bc: [<08059bc4>] do_IRQ+0x34/0x50 082579d4: [<08059e1b>] sigio_handler+0x5b/0x80 082579ec: [<0806a374>] sig_handler_common+0x44/0xb0 08257a68: [<0806a538>] sig_handler+0x38/0x50 08257a78: [<0806a77c>] handle_signal+0x5c/0xa0 08257a9c: [<0806be28>] hard_handler+0x18/0x20 08257aac: [<00c14400>] 0xc14400 Signed-off-by:
Will Newton <will.newton@gmail.com> Acked-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Nelson Elhage authored
commit 33dd94ae upstream. If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not otherwise reset before do_exit(). do_exit may later (via mm_release in fork.c) do a put_user to a user-controlled address, potentially allowing a user to leverage an oops into a controlled write into kernel memory. This is only triggerable in the presence of another bug, but this potentially turns a lot of DoS bugs into privilege escalations, so it's worth fixing. I have proof-of-concept code which uses this bug along with CVE-2010-3849 to write a zero to an arbitrary kernel address, so I've tested that this is not theoretical. A more logical place to put this fix might be when we know an oops has occurred, before we call do_exit(), but that would involve changing every architecture, in multiple places. Let's just stick it in do_exit instead. [akpm@linux-foundation.org: update code comment] Signed-off-by:
Nelson Elhage <nelhage@ksplice.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
Ken Sumrall authored
commit a0822c55 upstream. The attribute cache for a file was not being cleared when a file is opened with O_TRUNC. If the filesystem's open operation truncates the file ("atomic_o_trunc" feature flag is set) then the kernel should invalidate the cached st_mtime and st_ctime attributes. Also i_size should be explicitly be set to zero as it is used sometimes without refreshing the cache. Signed-off-by:
Ken Sumrall <ksumrall@android.com> Cc: Anfei <anfei.zhou@gmail.com> Cc: "Anand V. Avati" <avati@gluster.com> Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Len Brown authored
commit 7a1d602f upstream. https://bugzilla.kernel.org/show_bug.cgi?id=12641Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Zhang Rui authored
commit dab5fff1 upstream. We didn't free per_cpu(acfreq_data, cpu)->freq_table when acpi_freq driver is unloaded. Resulting in the following messages in /sys/kernel/debug/kmemleak: unreferenced object 0xf6450e80 (size 64): comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s) hex dump (first 32 bytes): 00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$. 02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5.. backtrace: [<c123ba97>] kmemleak_alloc+0x27/0x50 [<c109f96f>] __kmalloc+0xcf/0x110 [<f9da97ee>] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq] [<c11cd8d2>] cpufreq_add_dev+0x142/0x3a0 [<c11920b7>] sysdev_driver_register+0x97/0x110 [<c11cce56>] cpufreq_register_driver+0x86/0x140 [<f9dad080>] 0xf9dad080 [<c1001130>] do_one_initcall+0x30/0x160 [<c10626e9>] sys_init_module+0x99/0x1e0 [<c1002d97>] sysenter_do_call+0x12/0x26 [<ffffffff>] 0xffffffff https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21Tested-by:
Toralf Forster <toralf.foerster@gmx.de> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Jacques Viviers authored
commit 6fdbad80 upstream. Add the PID for the Vardaan Enterprises VEUSB422R3 USB to RS422/485 converter. It uses the same chip as the FTDI_8U232AM_PID 0x6001. This should also work with the stable branches for: 2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36 Signed-off-by:
Jacques Viviers <jacques.viviers@gmail.com> Signed-off-by:
-
Michael Stuermer authored
commit 28942bb6 upstream. Another variant of the RT Systems programming cable for ham radios. Signed-off-by:
Michael Stuermer <ms@mallorn.de> Signed-off-by:
-
Greg Kroah-Hartman authored
commit e24d7ace upstream. They should not be writable by any user. Reported-by:
-
Greg Kroah-Hartman authored
commit d489a4b3 upstream. It should not be writable by any user. Reported-by:
-
Johan Hovold authored
commit 677aeafe upstream. This reverts commit 6a1a82df. RTS and DTR should not be modified based on CRTSCTS when calling set_termios. Modem control lines are raised at port open by the tty layer and should stay raised regardless of whether hardware flow control is enabled or not. This is in conformance with the way serial ports work today and many applications depend on this behaviour to be able to talk to hardware implementing hardware flow control (without the applications actually using it). Hardware which expects different behaviour on these lines can always use TIOCMSET/TIOCMBI[SC] after port open to change them. Reported-by:
Daniel Mack <daniel@caiaq.de> Reported-by:
Dave Mielke <dave@mielke.cc> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 48f11547 upstream. They should not be writable by any user. Reported-by:
-
Greg Kroah-Hartman authored
commit c990600d upstream. They should not be writable by any user. Reported-by:
-
Greg Kroah-Hartman authored
commit e502ac5e upstream. Some of the sysfs files had the incorrect permissions. Some didn't make sense at all (writable for a file that you could not write to?) Reported-by:
-
Greg Kroah-Hartman authored
commit d9624e75 upstream. A non-writable sysfs file shouldn't have writable attributes. Reported-by:
-
Alan Stern authored
commit 02e2c51b upstream. This patch (as1435) fixes an obscure and unlikely race in ehci-hcd. When an async URB is unlinked, the corresponding QH is removed from the async list. If the QH's endpoint is then disabled while the URB is being given back, ehci_endpoint_disable() won't find the QH on the async list, causing it to believe that the QH has been lost. This will lead to a memory leak at best and quite possibly to an oops. The solution is to trust usbcore not to lose track of endpoints. If the QH isn't on the async list then it doesn't need to be taken off the list, but the driver should still wait for the QH to become IDLE before disabling it. In theory this fixes Bugzilla #20182. In fact the race is so rare that it's not possible to tell whether the bug is still present. However, adding delays and making other changes to force the race seems to show that the patch works. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> CC: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Vasiliy Kulikov authored
commit 886ccd45 upstream. Structure usbdevfs_connectinfo is copied to userland with padding byted after "slow" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by:
Vasiliy Kulikov <segooon@gmail.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit eca67aae upstream. Structure iowarrior_info is copied to userland with padding byted between "serial" and "revision" fields uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 5dc92cf1 upstream. Structure sisusb_info is copied to userland with "sisusb_reserved" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by:
-
ma rui authored
commit 58c0d9d7 upstream. When huawei datacard with PID 0x14AC is insterted into Linux system, the present kernel will load the "option" driver to all the interfaces. But actually, some interfaces run as other function and do not need "option" driver. In this path, we modify the id_tables, when the PID is 0x14ac ,VID is 0x12d1, Only when the interface's Class is 0xff,Subclass is 0xff, Pro is 0xff, it does need "option" driver. Signed-off-by:
ma rui <m00150988@huawei.com> Signed-off-by:
-
