- 09 May, 2011 40 commits
-
-
Dan Streetman authored
commit 16985408 upstream. Currently a non-root-hub USB device's wakeup settings are initialized when the device is set to a configured state using device_init_wakeup(), but this is not correct as wakeup is split into "capable" (can_wakeup) and "enabled" (should_wakeup). The settings should be initialized instead in the device initialization (usb_new_device) with the "capable" setting disabled and the "enabled" setting enabled. The "capable" setting should be set based on the device being configured or unconfigured, and "enabled" setting set based on the sysfs power/wakeup control. This patch retains the sysfs power/wakeup setting of a non-root-hub USB device over a USB device re-configuration, which can happen (for example) after a suspend/resume cycle. Signed-off-by:
Dan Streetman <ddstreet@ieee.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> [bwh: Adjust context for 2.6.32] Signed-off-by:
-
Florian Schilhabel authored
commit 15d93ed0 upstream. This patch adds some device ids. The list of supported devices was extracted from realteks driver package. (0x050d, 0x815F) and (0x0df6, 0x004b) are not in the official list of supported devices and may not work correctly. In case of problems with these, they should probably be removed from the list. Signed-off-by:
Florian Schilhabel <florian.c.schilhabel@googlemail.com> Signed-off-by:
-
Florian Schilhabel authored
commit 60b42de3 upstream. This patch removes some device-ids. The list of unsupported devices was extracted from realteks driver package. removed IDs are: (0x0bda, 0x8192) (0x0bda, 0x8709) (0x07aa, 0x0043) (0x050d, 0x805E) (0x0df6, 0x0031) (0x1740, 0x9201) (0x2001, 0x3301) (0x5a57, 0x0290) These devices are _not_ rtl819su based. Signed-off-by:
-
Ben Hutchings authored
commit 41a38d9e upstream. The current code creates directories in procfs named after interfaces, but doesn't handle renaming. This can result in name collisions and consequent WARNINGs. It also means that the interface name cannot reliably be used to remove the directory - in fact the current code doesn't even try, and always uses "wlan0"! Since the name of a proc_dir_entry is embedded in it, use that when removing it. Add a netdev notifier to catch interface renaming, and remove and re-add the directory at this point. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ben Hutchings authored
commit 9a3dfa05 upstream. Currently various resources may be leaked in case of an error. Signed-off-by:
-
Florian Schilhabel authored
commit 199ef62a upstream. added 2 checks for skb == NULL. plus cosmetics Signed-off-by:
-
Éric Piel authored
commit 7f29f17b upstream. According to the Dell/Ubuntu driver, what was previously observed as "jumpy cursor" corresponds to the hardware sending incorrect data for the first two reports of a one touch finger. So let's use the same workaround as in the other driver. Also, detect another firmware version with the same behaviour, as in the other driver. Signed-off-by:
Éric Piel <eric.piel@tremplin-utc.net> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> [bwh: Adjust for 2.6.32] Signed-off-by:
-
Dmitry Torokhov authored
commit a083632e upstream. Apparently there are Elantech touchpads that report non-zero in the 2nd byte of their signature. Adjust the detection routine so that if 2nd byte is zero and 3rd byte contains value that is not a valid report rate, we still assume that signature is valid. Tested-by:
-
Dmitry Torokhov authored
commit 504e8bee upstream. Apparently all 3 bytes returned by ETP_FW_VERSION_QUERY are significant and should be taken into account when matching hardware version/features. Tested-by:
-
Florian Ragwitz authored
commit e938fbfd upstream. In older versions of the elantech hardware/firmware those bits always were unset, so it didn't actually matter, but newer versions seem to use those high bits for something else, screwing up the coordinates we report to the input layer for those devices. Signed-off-by:
Florian Ragwitz <rafl@debian.org> Signed-off-by:
-
Florian Ragwitz authored
commit f81bc788 upstream. Apparently hardware vendors now ship elantech touchpads with different version magic. This options allows for them to be tested easier with the current driver in order to add their magic to the whitelist later. Signed-off-by:
-
Florian Ragwitz authored
commit 225c61aa upstream. The check determining whether device should use 4- or 6-byte packets was trying to compare firmware with 2.48, but was failing on majors greater than 2. The new check ensures that versions like 4.1 are checked properly. Signed-off-by:
-
Dmitry Torokhov authored
commit c7a1f3cc upstream. Elantech touchpads work in absolute mode and do not generate relative events so they should not be advertising them. Signed-off-by:
-
Takashi Iwai authored
commit 5f57d67d upstream. The new type of touchpads can be detected via a new query command 0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits. When the device is detected, the driver now reports only the left button as the supported buttons so that X11 driver can detect that the device is Clickpad. A Clickpad device gives the button events only as the middle button. The kernel driver morphs to the left button. The real handling of Clickpad is done rather in X driver side. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ben Hutchings authored
commit b3ccbb24 upstream. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ben Hutchings authored
commit 866691a2 upstream. Signed-off-by:
-
Ben Hutchings authored
commit 8489992e upstream. Signed-off-by:
-
Ben Hutchings authored
commit 36c04a61 upstream. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Ben Hutchings authored
commit b9721d5a upstream. Signed-off-by:
-
Ben Hutchings authored
commit 34336ec0 upstream. Replace run-time string formatting with preprocessor string manipulation. Signed-off-by:
Divy Le Ray <divy@chelsio.com> Signed-off-by:
-
Ben Hutchings authored
commit 45229b42 upstream. Replace run-time string formatting with preprocessor string manipulation. Signed-off-by:
Eilon Greenstein <eilong@broadcom.com> Signed-off-by:
-
Dhananjay Phadke authored
commit 7e8e5d97 upstream. Add MODULE_FIRMWARE hints for various firmware file types, required by different chip revisions. Signed-off-by:
Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by:
-
Timo Warns authored
commit c340b1d6 upstream. The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices. The patch validates the value of vblk_size. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Timo Warns <warns@pre-sense.de> Cc: Eugene Teo <eugeneteo@kernel.sg> Cc: Harvey Harrison <harvey.harrison@gmail.com> Cc: Richard Russon <rich@flatcap.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dave Jones authored
commit c6914a6f upstream. We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Sachin Prabhu authored
commit 1574dff8 upstream. An open on a NFS4 share using the O_CREAT flag on an existing file for which we have permissions to open but contained in a directory with no write permissions will fail with EACCES. A tcpdump shows that the client had set the open mode to UNCHECKED which indicates that the file should be created if it doesn't exist and encountering an existing flag is not an error. Since in this case the file exists and can be opened by the user, the NFS server is wrong in attempting to check create permissions on the parent directory. The patch adds a conditional statement to check for create permissions only if the file doesn't exist. Signed-off-by:
Sachin S. Prabhu <sprabhu@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Jim Bos authored
commit 22d3243d upstream. The fix in commit 6b4e81db ("i8k: Tell gcc that *regs gets clobbered") to work around the gcc miscompiling i8k.c to add "+m (*regs)" caused register pressure problems and a build failure. Changing the 'asm' statement to 'asm volatile' instead should prevent that and works around the gcc bug as well, so we can remove the "+m". [ Background on the gcc bug: a memory clobber fails to mark the function the asm resides in as non-pure (aka "__attribute__((const))"), so if the function does nothing else that triggers the non-pure logic, gcc will think that that function has no side effects at all. As a result, callers will be mis-compiled. Adding the "+m" made gcc see that it's not a pure function, and so does "asm volatile". The problem was never really the need to mark "*regs" as changed, since the memory clobber did that part - the problem was just a bug in the gcc "pure" function analysis - Linus ] Signed-off-by:
Jim Bos <jim876@xs4all.nl> Acked-by:
Jakub Jelinek <jakub@redhat.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
-
Jim Bos authored
commit 6b4e81db upstream. More recent GCC caused the i8k driver to stop working, on Slackware compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't work anymore, meaning the driver didn't load or gave total nonsensical output. As it turned out the asm(..) statement forgot to mention it modifies the *regs variable. Credits to Andi Kleen and Andreas Schwab for providing the fix. Signed-off-by:
-
Dan Rosenberg authored
commit 0f22072a upstream. When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not bound the nsops argument. A sufficiently large value will cause an integer overflow in allocation size, followed by copying too much data into the allocated buffer. Fix this by restricting nsops to SEMOPM. Untested. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Eric W. Biederman authored
commit a05d2ad1 upstream. This fixes the following oops discovered by Dan Aloni: > Anyway, the following is the output of the Oops that I got on the > Ubuntu kernel on which I first detected the problem > (2.6.37-12-generic). The Oops that followed will be more useful, I > guess. >[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference > at (null) > [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420 > [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 > [ 5594.693720] Oops: 0002 [#1] SMP > [ 5594.699888] last sysfs file: The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet. That is always wrong and as of commit 7361c36c the pseudo packet had become enough different from a normal packet that the kernel started oopsing. Do for seqpacket_recv what was done for seqpacket_send in 2.5 and only allow it on connected seqpacket sockets. Tested-by:
Dan Aloni <dan@aloni.org> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Boris Ostrovsky authored
commit e20a2d20 upstream. Older AMD K8 processors (Revisions A-E) are affected by erratum 400 (APIC timer interrupts don't occur in C states greater than C1). This, for example, means that X86_FEATURE_ARAT flag should not be set for these parts. This addresses regression introduced by commit b87cf80a ("x86, AMD: Set ARAT feature on AMD processors") where the system may become unresponsive until external interrupt (such as keyboard input) occurs. This results, for example, in time not being reported correctly, lack of progress on the system and other lockups. Reported-by:
Joerg-Volker Peetz <jvpeetz@web.de> Tested-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
Boris Ostrovsky <Boris.Ostrovsky@amd.com> Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alan Stern authored
commit cee6a262 upstream. This patch (as1460) fixes a regression in the usbip driver caused by the new check for Transaction Translators in USB-2 hubs. The root hub registered by vhci_hcd needs to have the has_tt flag set, because it can connect to low- and full-speed devices as well as high-speed devices. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
Nikola Ciprich <nikola.ciprich@linuxbox.cz> Signed-off-by:
-
Chris Ball authored
commit 0c9c99a7 upstream. It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference. Seen on S3C6410 system. Based on a patch by Dimitris Papastamos. Reported-by:
Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Ben Dooks authored
commit b7b4d342 upstream. It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference. Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8 Seen on S3C6410 system. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Chris Ball authored
commit 9fdcdbb0 upstream. If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier. The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out. Signed-off-by:
-
James Bottomley authored
commit 86cbfb56 upstream. SCSI uses request_queue->queuedata == NULL as a signal that the queue is dying. We set this state in the sdev release function. However, this allows a small window where we release the last reference but haven't quite got to this stage yet and so something will try to take a reference in scsi_request_fn and oops. It's very rare, but we had a report here, so we're pushing this as a bug fix The actual fix is to set request_queue->queuedata to NULL in scsi_remove_device() before we drop the reference. This causes correct automatic rejects from scsi_request_fn as people who hold additional references try to submit work and prevents anything from getting a new reference to the sdev that way. Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Dan Rosenberg authored
commit a1f74ae8 upstream. At two points in handling device ioctls via /dev/mpt2ctl, user-supplied length values are used to copy data from userspace into heap buffers without bounds checking, allowing controllable heap corruption and subsequently privilege escalation. Additionally, user-supplied values are used to determine the size of a copy_to_user() as well as the offset into the buffer to be read, with no bounds checking, allowing users to read arbitrary kernel memory. Signed-off-by:
Eric Moore <eric.moore@lsi.com> Signed-off-by:
-
Dan Rosenberg authored
commit 5f6279da upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. Not especially relevant from a security perspective, since users must have CAP_SYS_ADMIN to open the character device. First, the user can call pmcraid_chr_ioctl() with a type PMCRAID_PASSTHROUGH_IOCTL. A pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. Prevent this value from being negative in pmcraid_ioctl_passthrough(). Signed-off-by:
-
Igor Mammedov authored
commit c36b58e8 upstream. Mouse gets "stuck" after restore of PV guest but buttons are in working condition. If driver has been configured for ABS coordinates at start it will get XENKBD_TYPE_POS events and then suddenly after restore it'll start getting XENKBD_TYPE_MOTION events, that will be dropped later and they won't get into user-space. Regression was introduced by hunk 5 and 6 of 5ea5254a ("Input: xen-kbdfront - advertise either absolute or relative coordinates"). Driver on restore should ask xen for request-abs-pointer again if it is available. So restore parts that did it before 5ea5254a. Acked-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Igor Mammedov <imammedo@redhat.com> [v1: Expanded the commit description] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit b522f021 upstream. page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 194b3da8 upstream. pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by:
-
