- Apr 22, 2011
-
-
Greg Kroah-Hartman authored
-
Linus Torvalds authored
commit 1b1f693d upstream. As reported by Thomas Pollet, the rdma page counting can overflow. We get the rdma sizes in 64-bit unsigned entities, but then limit it to UINT_MAX bytes and shift them down to pages (so with a possible "+1" for an unaligned address). So each individual page count fits comfortably in an 'unsigned int' (not even close to overflowing into signed), but as they are added up, they might end up resulting in a signed return value. Which would be wrong. Catch the case of tot_pages turning negative, and return the appropriate error code. Reported-by:
Thomas Pollet <thomas.pollet@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Andy Grover <andy.grover@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [v2: nr is unsigned in the old code] Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kees Cook authored
commit 5b919f83 upstream. Commit fe10ae53 adds a memset() to clear the structure being sent back to userspace, but accidentally used the wrong size. Reported-by:
Brad Spengler <spender@grsecurity.net> Signed-off-by:
Kees Cook <kees.cook@canonical.com> Signed-off-by:
-
Hans Rosenfeld authored
commit 07a7795c upstream. A bug in the family-model-stepping matching code caused the presence of errata to go undetected when OSVW was not used. This causes hangs on some K8 systems because the E400 workaround is not enabled. Signed-off-by:
Hans Rosenfeld <hans.rosenfeld@amd.com> LKML-Reference: <1282141190-930137-1-git-send-email-hans.rosenfeld@amd.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Dmitry Torokhov authored
commit dfa49c4a upstream. When parsing exponent-expressed intervals we subtract 1 from the value and then expect it to match with original + 1, which is highly unlikely, and we end with frequent spew: usb 3-4: ep 0x83 - rounding interval to 512 microframes Also, parsing interval for fullspeed isochronous endpoints was incorrect - according to USB spec they use exponent-based intervals (but xHCI spec claims frame-based intervals). I trust USB spec more, especially since USB core agrees with it. This should be queued for stable kernels back to 2.6.31. Reviewed-by:
Micah Elizabeth Scott <micah@vmware.com> Signed-off-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Dmitry Torokhov authored
commit 5a6c2f3f upstream. Macro arguments used in expressions need to be enclosed in parenthesis to avoid unpleasant surprises. This should be queued for kernels back to 2.6.31 Signed-off-by:
-
Dmitry Torokhov authored
commit 2868a2b1 upstream. Isochronous and interrupt SuperSpeed endpoints use the same mechanisms for decoding bInterval values as HighSpeed ones so adjust the code accordingly. Also bandwidth reservation for SuperSpeed matches highspeed, not low/full speed. Signed-off-by:
-
Alan Stern authored
commit 94ae4976 upstream. This patch (as1458) fixes a problem affecting ultra-reliable systems: When hardware failover of an EHCI controller occurs, the data structures do not get released correctly. This is because the routine responsible for removing unused QHs from the async schedule assumes the controller is running properly (the frame counter is used in determining how long the QH has been idle) -- but when a failover causes the controller to be electronically disconnected from the PCI bus, obviously it stops running. The solution is simple: Allow scan_async() to remove a QH from the async schedule if it has been idle for long enough _or_ if the controller is stopped. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-Tested-by:
Dan Duval <dan.duval@stratus.com> Signed-off-by:
-
Linus Torvalds authored
commit d8bdc59f upstream. Rather than pass in some random truncated offset to the pid-related functions, check that the offset is in range up-front. This is just cleanup, the previous commit fixed the real problem. Signed-off-by:
-
Linus Torvalds authored
commit c78193e9 upstream. next_pidmap() just quietly accepted whatever 'last' pid that was passed in, which is not all that safe when one of the users is /proc. Admittedly the proc code should do some sanity checking on the range (and that will be the next commit), but that doesn't mean that the helper functions should just do that pidmap pointer arithmetic without checking the range of its arguments. So clamp 'last' to PID_MAX_LIMIT. The fact that we then do "last+1" doesn't really matter, the for-loop does check against the end of the pidmap array properly (it's only the actual pointer arithmetic overflow case we need to worry about, and going one bit beyond isn't going to overflow). [ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ] Reported-by:
Tavis Ormandy <taviso@cmpxchg8b.com> Analyzed-by:
Robert Święcki <robert@swiecki.net> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
-
Marius B. Kotsbak authored
commit 80f9df3e upstream. Bind only modem AT command endpoint to option. Signed-off-by:
Marius B. Kotsbak <marius@kotsbak.com> Signed-off-by:
-
Enrico Mioso authored
commit c6991b6f upstream. This patch, adds to the option driver the Onda Communication (http://www.ondacommunication.com ) vendor id, and the MT825UP modem device id. Note that many variants of this same device are being release here in Italy (at least one or two per telephony operator). These devices are perfectly equivalent except for some predefined settings (which can be changed of course). It should be noted that most ONDA devices are allready supported (they used other vendor's ids in the past). The patch seems working fine here, and the rest of the driver seems uninfluenced. Signed-off-by:
Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by:
-
Paul Friedrich authored
commit c53c2fab upstream. usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720 and HO730 Signed-off-by:
-
Johan Hovold authored
commit 11a31d84 upstream. Add PID 0x0103 for serial port of the OCT DK201 docking station. Reported-by:
Jan Hoogenraad <jan@hoogenraad.net> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Christian Simon authored
commit 5a9443f0 upstream. I added new ProdutIds for two devices from CTI GmbH Leipzig. Signed-off-by:
Christian Simon <simon@swine.de> Signed-off-by:
-
Joerg Roedel authored
commit 5bbc097d upstream. This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS forgets to do is (or is just too old). Letting these errors enabled can cause a sync-flood on the CPU causing a reboot. The AMD BKDG recommends disabling GART TLB Wlk Error completely. This patch is the fix for https://bugzilla.kernel.org/show_bug.cgi?id=33012 on my machine. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Link: http://lkml.kernel.org/r/20110415131152.GJ18463@8bytes.org Tested-by:
Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Boris Ostrovsky authored
commit b87cf80a upstream. Support for Always Running APIC timer (ARAT) was introduced in commit db954b58. This feature allows us to avoid switching timers from LAPIC to something else (e.g. HPET) and go into timer broadcasts when entering deep C-states. AMD processors don't provide a CPUID bit for that feature but they also keep APIC timers running in deep C-states (except for cases when the processor is affected by erratum 400). Therefore we should set ARAT feature bit on AMD CPUs. Tested-by:
Borislav Petkov <borislav.petkov@amd.com> Acked-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Acked-by:
Mark Langsdorf <mark.langsdorf@amd.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@amd.com> LKML-Reference: <1300205624-4813-1-git-send-email-ostr@amd64.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Hans Rosenfeld authored
commit 9d8888c2 upstream. Remove check_c1e_idle() and use the new AMD errata checking framework instead. Signed-off-by:
-
Hans Rosenfeld authored
commit d78d671d upstream. Errata are defined using the AMD_LEGACY_ERRATUM() or AMD_OSVW_ERRATUM() macros. The latter is intended for newer errata that have an OSVW id assigned, which it takes as first argument. Both take a variable number of family-specific model-stepping ranges created by AMD_MODEL_RANGE(). Iff an erratum has an OSVW id, OSVW is available on the CPU, and the OSVW id is known to the hardware, it is used to determine whether an erratum is present. Otherwise, the model-stepping ranges are matched against the current CPU to find out whether the erratum applies. For certain special errata, the code using this framework might have to conduct further checks to make sure an erratum is really (not) present. Signed-off-by:
-
Artem Bityutskiy authored
commit 78530bf7 upstream. This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an file on R/O-mounter file-system. We (the UBIFS authors) incorrectly thought that VFS would not propagate 'fsync()' down to the file-system if it is read-only, but this is not the case. It is easy to exploit this bug using the following simple perl script: use strict; use File::Sync qw(fsync sync); die "File path is not specified" if not defined $ARGV[0]; my $path = $ARGV[0]; open FILE, "<", "$path" or die "Cannot open $path: $!"; fsync(\*FILE) or die "cannot fsync $path: $!"; close FILE or die "Cannot close $path: $!"; Thanks to Reuben Dowle <Reuben.Dowle@navico.com> for reporting about this issue. Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Reported-by:
Reuben Dowle <Reuben.Dowle@navico.com> Signed-off-by:
-
Randy Dunlap authored
commit d00ebeac upstream. Drop Chris Wright from STABLE maintainers. He hasn't done STABLE release work for quite some time. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Acked-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Bob Liu authored
commit b836aec5 upstream. On no-mmu arch, there is a memleak during shmem test. The cause of this memleak is ramfs_nommu_expand_for_mapping() added page refcount to 2 which makes iput() can't free that pages. The simple test file is like this: int main(void) { int i; key_t k = ftok("/etc", 42); for ( i=0; i<100; ++i) { int id = shmget(k, 10000, 0644|IPC_CREAT); if (id == -1) { printf("shmget error\n"); } if(shmctl(id, IPC_RMID, NULL ) == -1) { printf("shm rm error\n"); return -1; } } printf("run ok...\n"); return 0; } And the result: root:/> free total used free shared buffers Mem: 60320 17912 42408 0 0 -/+ buffers: 17912 42408 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 19096 41224 0 0 -/+ buffers: 19096 41224 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 20296 40024 0 0 -/+ buffers: 20296 40024 ... After this patch the test result is:(no memleak anymore) root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 root:/> shmem run ok... root:/> free total used free shared buffers Mem: 60320 16668 43652 0 0 -/+ buffers: 16668 43652 Signed-off-by:
Bob Liu <lliubbo@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Jeff Mahoney authored
commit c1d036c4 upstream. ia64_mca_cpu_init has a void *data local variable that is assigned the value from either __get_free_pages() or mca_bootmem(). The problem is that __get_free_pages returns an unsigned long and mca_bootmem, via alloc_bootmem(), returns a void *. format_mca_init_stack takes the void *, and it's also used with __pa(), but that casts it to long anyway. This results in the following build warning: arch/ia64/kernel/mca.c:1898: warning: assignment makes pointer from integer without a cast Cast the return of __get_free_pages to a void * to avoid the warning. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Jeff Mahoney authored
commit b4a6b343 upstream. The prototype for sn_pci_provider->{dma_map,dma_map_consistent} expects an unsigned long instead of a u64. Signed-off-by:
-
Jan Beulich authored
commit e938c287 upstream. 'simple' would have required specifying current frame address and return address location manually, but that's obviously not the case (and not necessary) here. Signed-off-by:
Jan Beulich <jbeulich@novell.com> LKML-Reference: <4D6D1082020000780003454C@vpn.id2.novell.com> Signed-off-by:
-
Jiri Slaby authored
commit 468c3f92 upstream. Currently, for N 5800 XM I get: cdc_phonet: probe of 1-6:1.10 failed with error -22 It's because phonet_header is empty. Extra altsetting looks like there: E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd .$....$..$....$. E 00 . I don't see the header used anywhere so just check if the phonet descriptor is there, not the structure itself. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Cc: David S. Miller <davem@davemloft.net> Acked-by:
Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 8c559d30 upstream. Don't allow everybody to dump sensitive information about filesystems. Signed-off-by:
Vasiliy Kulikov <segoon@openwall.com> Signed-off-by:
-
Vasiliy Kulikov authored
commit 14ddc318 upstream. Don't allow everybody to change video settings. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Acked-by:
Luca Risolia <luca.risolia@studio.unibo.it> Signed-off-by:
-
Jeff Layton authored
commit 70945643 upstream. Currently, we skip doing the is_path_accessible check in cifs_mount if there is no prefixpath. I have a report of at least one server however that allows a TREE_CONNECT to a share that has a DFS referral at its root. The reporter in this case was using a UNC that had no prefixpath, so the is_path_accessible check was not triggered and the box later hit a BUG() because we were chasing a DFS referral on the root dentry for the mount. This patch fixes this by removing the check for a zero-length prefixpath. That should make the is_path_accessible check be done in this situation and should allow the client to chase the DFS referral at mount time instead. Reported-and-Tested-by:
Yogesh Sharma <ysharma@cymer.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
- Apr 15, 2011
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit bd378dd6 (originally commit 1b1f693d upstream). I messed it up in backporting it to the .32-stable kernel, so revert it for now and try it again the next review cycle. Cc: Thomas Pollet <thomas.pollet@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andy Grover <andy.grover@oracle.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
- Apr 14, 2011
-
-
Greg Kroah-Hartman authored
-
Alex Elder authored
commit af24ee9e upstream. Commit 493f3358 added this call to xfs_fs_geometry() in order to avoid passing kernel stack data back to user space: + memset(geo, 0, sizeof(*geo)); Unfortunately, one of the callers of that function passes the address of a smaller data type, cast to fit the type that xfs_fs_geometry() requires. As a result, this can happen: Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: f87aca93 Pid: 262, comm: xfs_fsr Not tainted 2.6.38-rc6-493f3358+ #1 Call Trace: [<c12991ac>] ? panic+0x50/0x150 [<c102ed71>] ? __stack_chk_fail+0x10/0x18 [<f87aca93>] ? xfs_ioc_fsgeometry_v1+0x56/0x5d [xfs] Fix this by fixing that one caller to pass the right type and then copy out the subset it is interested in. Note: This patch is an alternative to one originally proposed by Eric Sandeen. Reported-by:
Jeffrey Hundstad <jeffrey.hundstad@mnsu.edu> Signed-off-by:
Alex Elder <aelder@sgi.com> Reviewed-by:
Eric Sandeen <sandeen@redhat.com> Tested-by:
-
Linus Torvalds authored
commit 1b1f693d upstream. As reported by Thomas Pollet, the rdma page counting can overflow. We get the rdma sizes in 64-bit unsigned entities, but then limit it to UINT_MAX bytes and shift them down to pages (so with a possible "+1" for an unaligned address). So each individual page count fits comfortably in an 'unsigned int' (not even close to overflowing into signed), but as they are added up, they might end up resulting in a signed return value. Which would be wrong. Catch the case of tot_pages turning negative, and return the appropriate error code. Reported-by:
-
Oleg Nesterov authored
commit 114279be upstream. Note: this patch targets 2.6.37 and tries to be as simple as possible. That is why it adds more copy-and-paste horror into fs/compat.c and uglifies fs/exec.c, this will be cleanuped later. compat_copy_strings() plays with bprm->vma/mm directly and thus has two problems: it lacks the RLIMIT_STACK check and argv/envp memory is not visible to oom killer. Export acct_arg_size() and get_arg_page(), change compat_copy_strings() to use get_arg_page(), change compat_do_execve() to do acct_arg_size(0) as do_execve() does. Add the fatal_signal_pending/cond_resched checks into compat_count() and compat_copy_strings(), this matches the code in fs/exec.c and certainly makes sense. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Moritz Muehlenhoff <jmm@debian.org> Signed-off-by:
-
Oleg Nesterov authored
commit 3c77f845 upstream. Brad Spengler published a local memory-allocation DoS that evades the OOM-killer (though not the virtual memory RLIMIT): http://www.grsecurity.net/~spender/64bit_dos.c execve()->copy_strings() can allocate a lot of memory, but this is not visible to oom-killer, nobody can see the nascent bprm->mm and take it into account. With this patch get_arg_page() increments current's MM_ANONPAGES counter every time we allocate the new page for argv/envp. When do_execve() succeds or fails, we change this counter back. Technically this is not 100% correct, we can't know if the new page is swapped out and turn MM_ANONPAGES into MM_SWAPENTS, but I don't think this really matters and everything becomes correct once exec changes ->mm or fails. Reported-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
Dan Rosenberg authored
commit 9f260e0e upstream. Since the socket address is just being used as a unique identifier, its inode number is an alternative that does not leak potentially sensitive information. CC-ing stable because MITRE has assigned CVE-2010-4565 to the issue. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Acked-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Dan Rosenberg authored
commit fdac1e06 upstream. If the user-provided len is less than the expected offset, the IRLMP_ENUMDEVICES getsockopt will do a copy_to_user() with a very large size value. While this isn't be a security issue on x86 because it will get caught by the access_ok() check, it may leak large amounts of kernel heap on other architectures. In any event, this patch fixes it. Signed-off-by:
-
David S. Miller authored
commit 4e085e76 upstream. Unconditional use of skb->dev won't work here, try to fetch the econet device via skb_dst()->dev instead. Suggested by Eric Dumazet. Reported-by:
Nelson Elhage <nelhage@ksplice.com> Tested-by:
-
Nelson Elhage authored
commit 22e76c84 upstream. We were using nlmsg_find_attr() to look up the bytecode by attribute when auditing, but then just using the first attribute when actually running bytecode. So, if we received a message with two attribute elements, where only the second had type INET_DIAG_REQ_BYTECODE, we would validate and run different bytecode strings. Fix this by consistently using nlmsg_find_attr everywhere. Signed-off-by:
Thomas Graf <tgraf@infradead.org> Signed-off-by:
-
