- 14 Apr, 2011 40 commits
-
-
Borislav Petkov authored
Upstream commit: 44d60c0f The different families have a different max size for the ucode patch, adjust size checking to the family we're running on. Also, do not vzalloc the max size of the ucode but only the actual size that is passed on from the firmware loader. Cc: <stable@kernel.org> Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andreas Herrmann authored
Upstream commit: 6e18da75Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> LKML-Reference: <20091029134742.GD30802@alberich.amd.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Andy Gospodarek authored
commit 6d152e23 upstream. Like Herbert's change from a few days ago: 66c46d74 gro: Reset dev pointer on reuse this may not be necessary at this point, but we should still clean up the skb->skb_iif. If not we may end up with an invalid valid for skb->skb_iif when the skb is reused and the check is done in __netif_receive_skb. Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Brandon Philips <bphilips@suse.de> Signed-off-by:
-
Herbert Xu authored
commit 66c46d74 upstream. On older kernels the VLAN code may zero skb->dev before dropping it and causing it to be reused by GRO. Unfortunately we didn't reset skb->dev in that case which causes the next GRO user to get a bogus skb->dev pointer. This particular problem no longer happens with the current upstream kernel due to changes in VLAN processing. However, for correctness we should still reset the skb->dev pointer in the GRO reuse function in case a future user does the same thing. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jason Wessel authored
commit fb82c0ff upstream. The gdbserial protocol handler should return an empty packet instead of an error string when ever it responds to a command it does not implement. The problem cases come from a debugger client sending qTBuffer, qTStatus, qSearch, qSupported. The incorrect response from the gdbstub leads the debugger clients to not function correctly. Recent versions of gdb will not detach correctly as a result of this behavior. Backport-request-by:
Frank Pan <frankpzh@gmail.com> Signed-off-by:
Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
Dongdong Deng <dongdong.deng@windriver.com> Signed-off-by:
-
Kulikov Vasiliy authored
commit b3390cea upstream. get_user() may fail, if so return -EFAULT. Signed-off-by:
Kulikov Vasiliy <segooon@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Dan Rosenberg authored
commit b769f494 upstream. Was: [PATCH] sound/oss/midi_synth: prevent underflow, use of uninitialized value, and signedness issue The offset passed to midi_synth_load_patch() can be essentially arbitrary. If it's greater than the header length, this will result in a copy_from_user(dst, src, negative_val). While this will just return -EFAULT on x86, on other architectures this may cause memory corruption. Additionally, the length field of the sysex_info structure may not be initialized prior to its use. Finally, a signed comparison may result in an unintentionally large loop. On suggestion by Takashi Iwai, version two removes the offset argument from the load_patch callbacks entirely, which also resolves similar issues in opl3. Compile tested only. v3 adjusts comments and hopefully gets copy offsets right. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 67c5c6cb upstream. struct aunhdr has 4 padding bytes between 'pad' and 'handle' fields on x86_64. These bytes are not initialized in the variable 'ah' before sending 'ah' to the network. This leads to 4 bytes kernel stack infoleak. This bug was introduced before the git epoch. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Acked-by:
Phil Blundell <philb@gnu.org> Signed-off-by:
-
Vasiliy Kulikov authored
commit deb187e7 upstream. Don't allow everybody to change device settings. Signed-off-by:
Hartley Sweeten <hartleys@visionengravers.com> Cc: Matthieu Crapet <mcrapet@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Vasiliy Kulikov authored
commit 49d50fb1 upstream. Don't allow everybogy to write to NVRAM. Signed-off-by:
-
Vasiliy Kulikov authored
commit f8a06977 upstream. Don't allow everybody to change device hardware registers. Signed-off-by:
Linus Walleij <linus.walleij@stericsson.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 6a8ab060 upstream. Structures ip6t_replace, compat_ip6t_replace, and xt_get_revision are copied from userspace. Fields of these structs that are zero-terminated strings are not checked. When they are used as argument to a format string containing "%s" in request_module(), some sensitive information is leaked to userspace via argument of spawned modprobe process. The first bug was introduced before the git epoch; the second was introduced in 3bc3fe5e (v2.6.25-rc1); the third is introduced by 6b7d31fc (v2.6.15-rc1). To trigger the bug one should have CAP_NET_ADMIN. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Vasiliy Kulikov authored
commit 961ed183 upstream. 'buffer' string is copied from userspace. It is not checked whether it is zero terminated. This may lead to overflow inside of simple_strtoul(). Changli Gao suggested to copy not more than user supplied 'size' bytes. It was introduced before the git epoch. Files "ipt_CLUSTERIP/*" are root writable only by default, however, on some setups permissions might be relaxed to e.g. network admin user. Signed-off-by:
Changli Gao <xiaosuo@gmail.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 42eab94f upstream. Structures ipt_replace, compat_ipt_replace, and xt_get_revision are copied from userspace. Fields of these structs that are zero-terminated strings are not checked. When they are used as argument to a format string containing "%s" in request_module(), some sensitive information is leaked to userspace via argument of spawned modprobe process. The first bug was introduced before the git epoch; the second is introduced by 6b7d31fc (v2.6.15-rc1); the third is introduced by 6b7d31fc (v2.6.15-rc1). To trigger the bug one should have CAP_NET_ADMIN. Signed-off-by:
-
Vasiliy Kulikov authored
commit 78b79876 upstream. Structures ipt_replace, compat_ipt_replace, and xt_get_revision are copied from userspace. Fields of these structs that are zero-terminated strings are not checked. When they are used as argument to a format string containing "%s" in request_module(), some sensitive information is leaked to userspace via argument of spawned modprobe process. The first and the third bugs were introduced before the git epoch; the second was introduced in 2722971c (v2.6.17-rc1). To trigger the bug one should have CAP_NET_ADMIN. Signed-off-by:
-
Peter Huewe authored
commit 1309d7af upstream. This patch fixes information leakage to the userspace by initializing the data buffer to zero. Reported-by:
Peter Huewe <huewe.external@infineon.com> Signed-off-by:
Marcel Selhorst <m.selhorst@sirrix.com> [ Also removed the silly "* sizeof(u8)". If that isn't 1, we have way deeper problems than a simple multiplication can fix. - Linus ] Signed-off-by:
-
Goldwyn Rodrigues authored
commit 272b62c1 upstream. When a hole spans across page boundaries, the next write forces a read of the block. This could end up reading existing garbage data from the disk in ocfs2_map_page_blocks. This leads to non-zero holes. In order to avoid this, mark the writes as new when the holes span across page boundaries. Signed-off-by:
Goldwyn Rodrigues <rgoldwyn@suse.de> Signed-off-by:
jlbec <jlbec@evilplan.org> Signed-off-by:
-
Marc-Antoine Perennou authored
commit 63a8588d upstream. Just adding the vendor details makes it work fine. Signed-off-by:
Marc-Antoine Perennou <Marc-Antoine@Perennou.com> Signed-off-by:
Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by:
-
Vasiliy Kulikov authored
commit 43629f8f upstream. Struct ca is copied from userspace. It is not checked whether the "device" field is NULL terminated. This potentially leads to BUG() inside of alloc_netdev_mqs() and/or information leak by creating a device with a name made of contents of kernel stack. Signed-off-by:
-
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 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:
-
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:
-
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:
-
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:
-
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:
-
