- 14 Apr, 2011 36 commits
-
-
Vasiliy Kulikov authored
commit d846f711 upstream. Struct tmp is copied from userspace. It is not checked whether the "name" field is NULL terminated. This may lead to buffer overflow and passing contents of kernel stack as a module name to try_then_request_module() and, consequently, to modprobe commandline. It would be seen by all userspace processes. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Vasiliy Kulikov authored
commit c4c896e1 upstream. struct sco_conninfo has one padding byte in the end. Local variable cinfo of type sco_conninfo is copied to userspace with this uninizialized one byte, leading to old stack contents leak. Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by:
-
John W. Linville authored
commit c85ce65e upstream. Otherwise, skb_put inside of dma_rx can fail... https://bugzilla.kernel.org/show_bug.cgi?id=32042Signed-off-by:
John W. Linville <linville@tuxdriver.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Christian Lamparter authored
commit 22010761 upstream. Reported-by: Mark Davis [via p54/devices wiki] Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Linus Torvalds authored
commit 982134ba upstream. The normal mmap paths all avoid creating a mapping where the pgoff inside the mapping could wrap around due to overflow. However, an expanding mremap() can take such a non-wrapping mapping and make it bigger and cause a wrapping condition. Noticed by Robert Swiecki when running a system call fuzzer, where it caused a BUG_ON() due to terminally confusing the vma_prio_tree code. A vma dumping patch by Hugh then pinpointed the crazy wrapped case. Reported-and-tested-by:
Robert Swiecki <robert@swiecki.net> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jan Kara authored
commit b03f2456 upstream. There's no reason to write quota info in dquot_commit(). The writing is a relict from the old days when we didn't have dquot_acquire() and dquot_release() and thus dquot_commit() could have created / removed quota structures from the file. These days dquot_commit() only updates usage counters / limits in quota structure and thus there's no need to write quota info. This also fixes an issue with journaling filesystem which didn't reserve enough space in the transaction for write of quota info (it could have been dirty at the time of dquot_commit() because of a race with other operation changing it). Reported-and-tested-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Artem Bityutskiy authored
commit 7da6443a upstream. This patch fixes a debugging failure with which looks like this: UBIFS error (pid 32313): dbg_check_space_info: free space changed from 6019344 to 6022654 The reason for this failure is described in the comment this patch adds to the code. But in short - 'c->freeable_cnt' may be different before and after re-mounting, and this is normal. So the debugging code should make sure that free space calculations do not depend on 'c->freeable_cnt'. A similar issue has been reported here: http://lists.infradead.org/pipermail/linux-mtd/2011-April/034647.html This patch should fix it. For the -stable guys: this patch is only relevant for kernels 2.6.30 onwards. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
-
Artem Bityutskiy authored
commit 54acbaaa upstream. Thanks to coverity which spotted that UBIFS will oops if 'kmalloc()' in 'read_pnode()' fails and we dereference a NULL 'pnode' pointer when we 'goto out'. Signed-off-by:
-
Artem Bityutskiy authored
commit 8b229c76 upstream. This fix makes the 'dbg_check_old_index()' function return immediately if debugging is disabled, instead of executing incorrect 'goto out' which causes UBIFS to: 1. Allocate memory 2. Read the flash On every commit. OK, we do not commit that often, but it is still silly to do unneeded I/O anyway. Credits to coverity for spotting this silly issue. Signed-off-by:
-
Felix Fietkau authored
commit f62d816f upstream. When the chip is still asleep when ath9k_start is called, ath9k_hw_configpcipowersave can trigger a data bus error. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Suresh Siddha authored
commit 84ac7cdb upstream. On laptops with core i5/i7, there were reports that after resume graphics workloads were performing poorly on a specific AP, while the other cpu's were ok. This was observed on a 32bit kernel specifically. Debug showed that the PAT init was not happening on that AP during resume and hence it contributing to the poor workload performance on that cpu. On this system, resume flow looked like this: 1. BP starts the resume sequence and we reinit BP's MTRR's/PAT early on using mtrr_bp_restore() 2. Resume sequence brings all AP's online 3. Resume sequence now kicks off the MTRR reinit on all the AP's. 4. For some reason, between point 2 and 3, we moved from BP to one of the AP's. My guess is that printk() during resume sequence is contributing to this. We don't see similar behavior with the 64bit kernel but there is no guarantee that at this point the remaining resume sequence (after AP's bringup) has to happen on BP. 5. set_mtrr() was assuming that we are still on BP and skipped the MTRR/PAT init on that cpu (because of 1 above) 6. But we were on an AP and this led to not reprogramming PAT on this cpu leading to bad performance. Fix this by doing unconditional mtrr_if->set_all() in set_mtrr() during MTRR/PAT init. This might be unnecessary if we are still running on BP. But it is of no harm and will guarantee that after resume, all the cpu's will be in sync with respect to the MTRR/PAT registers. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1301438292-28370-1-git-send-email-eric@anholt.net> Signed-off-by:
Eric Anholt <eric@anholt.net> Tested-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Li Zefan authored
commit 08fe4db1 upstream. root_item->flags and root_item->byte_limit are not initialized when a subvolume is created. This bug is not revealed until we added readonly snapshot support - now you mount a btrfs filesystem and you may find the subvolumes in it are readonly. To work around this problem, we steal a bit from root_item->inode_item->flags, and use it to indicate if those fields have been properly initialized. When we read a tree root from disk, we check if the bit is set, and if not we'll set the flag and initialize the two fields of the root item. Reported-by:
Andreas Philipp <philipp.andreas@gmail.com> Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Tested-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
-
Dan Rosenberg authored
commit be20250c upstream. When parsing the FAC_NATIONAL_DIGIS facilities field, it's possible for a remote host to provide more digipeaters than expected, resulting in heap corruption. Check against ROSE_MAX_DIGIS to prevent overflows, and abort facilities parsing on failure. Additionally, when parsing the FAC_CCITT_DEST_NSAP and FAC_CCITT_SRC_NSAP facilities fields, a remote host can provide a length of less than 10, resulting in an underflow in a memcpy size, causing a kernel panic due to massive heap corruption. A length of greater than 20 results in a stack overflow of the callsign array. Abort facilities parsing on these invalid length values. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Clemens Ladisch authored
commit 6ebb8a4a upstream. To make the EV1938 chip work, add a magic bit and an extra delay. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Tested-by:
Tino Schmidt <mailtinoshomepage@gmx.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Brown authored
commit 0ca03cd7 upstream. This stops code that handles widgets generically from attempting to access registers for these widgets. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Ryusuke Konishi authored
commit 34094537 upstream. From the result of a function test of mmap, mmap write to shared pages turned out to be broken for hole blocks. It doesn't write out filled blocks and the data will be lost after umount. This is due to a bug that the target file is not queued for log writer when filling hole blocks. Also, nilfs_page_mkwrite function exits normal code path even after successfully filled hole blocks due to a change of block_page_mkwrite function; just after nilfs was merged into the mainline, block_page_mkwrite() started to return VM_FAULT_LOCKED instead of zero by the patch "mm: close page_mkwrite races" (commit: b827e496). The current nilfs_page_mkwrite() is not handling this value properly. This corrects nilfs_page_mkwrite() and will resolve the data loss problem in mmap write. [This should be applied to every kernel since 2.6.30 but a fix is needed for 2.6.37 and prior kernels] Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Tested-by:
-
Dan Rosenberg authored
commit d50e7e36 upstream. Invalid nicknames containing only spaces will result in an underflow in a memcpy size calculation, subsequently destroying the heap and panicking. v2 also catches the case where the provided nickname is longer than the buffer size, which can result in controllable heap corruption. Signed-off-by:
-
Dan Rosenberg authored
commit d370af0e upstream. Length fields provided by a peer for names and attributes may be longer than the destination array sizes. Validate lengths to prevent stack buffer overflows. Signed-off-by:
-
Dan Rosenberg authored
commit c4d0c3b0 upstream. The FSGEOMETRY_V1 ioctl (and its compat equivalent) calls out to xfs_fs_geometry() with a version number of 3. This code path does not fill in the logsunit member of the passed xfs_fsop_geom_t, leading to the leaking of four bytes of uninitialized stack data to potentially unprivileged callers. v2 switches to memset() to avoid future issues if structure members change, on suggestion of Dave Chinner. Signed-off-by:
Eugene Teo <eugeneteo@kernel.org> Signed-off-by:
Alex Elder <aelder@sgi.com> Signed-off-by:
-
Roland Dreier authored
commit 243b422a upstream. Commit da48524e ("Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code") made the check on si_code too strict. There are several legitimate places where glibc wants to queue a negative si_code different from SI_QUEUE: - This was first noticed with glibc's aio implementation, which wants to queue a signal with si_code SI_ASYNCIO; the current kernel causes glibc's tst-aio4 test to fail because rt_sigqueueinfo() fails with EPERM. - Further examination of the glibc source shows that getaddrinfo_a() wants to use SI_ASYNCNL (which the kernel does not even define). The timer_create() fallback code wants to queue signals with SI_TIMER. As suggested by Oleg Nesterov <oleg@redhat.com>, loosen the check to forbid only the problematic SI_TKILL case. Reported-by:
Klaus Dittrich <kladit@arcor.de> Acked-by:
Julien Tinnes <jln@google.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Olaf Hering authored
commit 22356585 upstream. Locking is required when tweaking bits located in a shared page, use the sync_ version of bitops. Without this change vmbus_on_event() will miss events and as a result, vmbus_isr() will not schedule the receive tasklet. [Backported to 2.6.32 stable kernel by Haiyang Zhang <haiyangz@microsoft.com>] Signed-off-by:
Olaf Hering <olaf@aepfle.de> Acked-by:
Haiyang Zhang <haiyangz@microsoft.com> Acked-by:
Hank Janssen <hjanssen@microsoft.com> Signed-off-by:
-
Haiyang Zhang authored
commit c996edcf upstream. After Quick Migration, the network is not immediately operational in the current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, I added another netif_notify_peers() into a scheduled work, otherwise GARP packet will not be sent after quick migration, and cause network disconnection. Thanks to Mike Surcouf <mike@surcouf.co.uk> for reporting the bug and testing the patch. Reported-by:
Mike Surcouf <mike@surcouf.co.uk> Tested-by:
Abhishek Kane <v-abkane@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Arjan Mels authored
commit 28276a28 upstream. For isochronous packets the actual_length is the sum of the actual length of each of the packets, however between the packets might be padding, so it is not sufficient to just send the first actual_length bytes of the buffer. To fix this and simultanesouly optimize the bandwidth the content of the isochronous packets are send without the padding, the padding is restored on the receiving end. Signed-off-by:
Arjan Mels <arjan.mels@gmx.net> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Cc: Max Vozeler <max@vozeler.com> Signed-off-by:
-
Arjan Mels authored
commit 1325f85f upstream. The number_of_packets was not transmitted for RET_SUBMIT packets. The linux client used the stored number_of_packet from the submitted request. The windows userland client does not do this however and needs to know the number_of_packets to determine the size of the transmission. Signed-off-by:
-
Arjan Mels authored
commit d2dd0b07 upstream. When doing a usb port reset do a queued reset instead to prevent a deadlock: the reset will cause the driver to unbind, causing the usb_driver_lock_for_reset to stall. Signed-off-by:
-
Roberto Sassu authored
commit 1821df04 upstream. The pointer '(*auth_tok_key)' is set to NULL in case request_key() fails, in order to prevent its use by functions calling ecryptfs_keyring_auth_tok_for_sig(). Signed-off-by:
Roberto Sassu <roberto.sassu@polito.it> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Tyler Hicks authored
commit 50f198ae upstream. Unlock the page in error path of ecryptfs_write_begin(). This may happen, for example, if decryption fails while bring the page up-to-date. Signed-off-by:
-
Krishnasamy, Somasundaram authored
commit d1e12de8 upstream. During device discovery, scsi mid layer sends INQUIRY command to LUN 0. If the LUN 0 is not mapped to host, it creates a temporary scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After the REPORT_LUNS succeeds, it walks through the LUN table and adds each LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will delete the temporary scsi_device of LUN 0. When scsi devices are added to sysfs, it calls add_dev function of all the registered class interfaces. If ses driver has been registered, ses_intf_add() of ses module will be called. This function calls scsi_device_enclosure() to check the inquiry data for EncServ bit. Since inquiry was not allocated for temporary LUN 0 scsi_device, it will cause NULL pointer exception. To fix the problem, sdev->inquiry is checked for NULL before reading it. Signed-off-by:
Somasundaram Krishnasamy <Somasundaram.Krishnasamy@lsi.com> Signed-off-by:
Babu Moger <babu.moger@lsi.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
John Hughes authored
commit 877a5597 upstream. enclosure page 7 gives us the "pretty" names of the enclosure slots. Without a page 7, we can still use the enclosure code as long as we make up numeric names for the slots. Unfortunately, the current code fails to add any devices because the check for page 10 is in the wrong place if we have no page 7. Fix it so that devices show up even if the enclosure has no page 7. Signed-off-by:
-
Felix Fietkau authored
commit 8bc8aecd upstream. This field is used to determine the inactivity time. When in AP mode, hostapd uses it for kicking out inactive clients after a while. Without this patch, hostapd immediately deauthenticates a new client if it checks the inactivity time before the client sends its first data frame. Signed-off-by:
-
Dan Rosenberg authored
commit 4d00135a upstream. User-controllable indexes for voice and channel values may cause reading and writing beyond the bounds of their respective arrays, leading to potentially exploitable memory corruption. Validate these indexes. Signed-off-by:
-
Bud Brown authored
commit 1ddd5049 upstream. Under certain workloads a command may seem to get lost. IOW, the Smart Array thinks all commands have been completed but we still have commands in our completion queue. This may lead to system instability, filesystems going read-only, or even panics depending on the affected filesystem. We add an extra read to force the write to complete. Testing shows this extra read avoids the problem. Signed-off-by:
Mike Miller <mike.miller@hp.com> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit cda6587c upstream. Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi structures are already deallocated. To fix call netif_napi_del() before kfree() at myri10ge_free_slices(). Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Frederic Weisbecker authored
commit 880f5731 upstream. The maximum kilobytes of locked memory that an unprivileged user can reserve is of 512 kB = 128 pages by default, scaled to the number of onlined CPUs, which fits well with the tools that use 128 data pages by default. However tools actually use 129 pages, because they need one more for the user control page. Thus the default mlock threshold is not sufficient for the default tools needs and we always end up to evaluate the constant mlock rlimit policy, which doesn't have this scaling with the number of online CPUs. Hence, on systems that have more than 16 CPUs, we overlap the rlimit threshold and fail to mmap: $ perf record ls Error: failed to mmap with 1 (Operation not permitted) Just increase the max unprivileged mlock threshold by one page so that it supports well perf tools even after 16 CPUs. Reported-by:
Han Pingtian <phan@redhat.com> Reported-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Reported-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Takashi Iwai authored
commit a45e3d6b upstream. This patch fixes a race between snd_card_file_remove() and snd_card_disconnect(). When the card is added to shutdown_files list in snd_card_disconnect(), but it's freed in snd_card_file_remove() at the same time, the shutdown_files list gets corrupted. The list member must be freed in snd_card_file_remove() as well. Reported-and-tested-by:
Russ Dill <russ.dill@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 20b67ddd upstream. The commit 5a8cfb4e ALSA: hda - Use ALC_INIT_DEFAULT for really default initialization changed to use the default initialization method for ALC889, but this caused a regression on SPDIF output on some machines. This seems due to the COEF setup included in the default init procedure. For making SPDIF working again, the COEF-setup has to be avoided for the id 0889. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24342Signed-off-by:
-
- 27 Mar, 2011 4 commits
-
-
Greg Kroah-Hartman authored
-
Stuart Hayes authored
commit dd65c736 upstream. The dcdbas driver can do an I/O write to cause a SMI to occur. The SMI handler looks at certain registers and memory locations, so the SMI needs to happen immediately. On some systems I/O writes are posted, though, causing the SMI to happen well after the "outb" occurred, which causes random failures. Following the "outb" with an "inb" forces the write to go through even if it is posted. Signed-off-by:
Stuart Hayes <stuart_hayes@yahoo.com> Acked-by:
Doug Warzecha <douglas_warzecha@dell.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Josef Bacik authored
commit 24ff6663 upstream. While trying to track down some NFS problems with BTRFS, I kept noticing I was getting -EACCESS for no apparent reason. Eric Paris and printk() helped me figure out that it was SELinux that was giving me grief, with the following denial type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772 comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file Turns out this is because in d_obtain_alias if we can't find an alias we create one and do all the normal instantiation stuff, but we don't do the security_d_instantiate. Usually we are protected from getting a hashed dentry that hasn't yet run security_d_instantiate() by the parent's i_mutex, but obviously this isn't an option there, so in order to deal with the case that a second thread comes in and finds our new dentry before we get to run security_d_instantiate(), we go ahead and call it if we find a dentry already. Eric assures me that this is ok as the code checks to see if the dentry has been initialized already so calling security_d_instantiate() against the same dentry multiple times is ok. With this patch I'm no longer getting errant -EACCESS values. Signed-off-by:
Josef Bacik <josef@redhat.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Trond Myklebust authored
commit 246408dc upstream. If we call xs_close(), we're in one of two situations: - Autoclose, which means we don't expect to resend a request - bind+connect failed, which probably means the port is in use Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
