- 11 Jan, 2013 40 commits
-
-
NeilBrown authored
commit f259613a upstream. In rare circumstances, nfs_clone_server() of a v2 or v3 server can get an error between setting server->destory (to nfs_destroy_server), and calling nfs_start_lockd (which will set server->nlm_host). If this happens, nfs_clone_server will call nfs_free_server which will call nfs_destroy_server and thence nlmclnt_done(NULL). This causes the NULL to be dereferenced. So add a guard to only call nlmclnt_done() if ->nlm_host is not NULL. The other guards there are irrelevant as nlm_host can only be non-NULL if one of these flags are set - so remove those tests. (Thanks to Trond for this suggestion). This is suitable for any stable kernel since 2.6.25. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jeff Layton authored
commit 67fad106 upstream. Eryu provided a test program that would segfault when attempting to read past the EOF on file that was opened O_DIRECT. The buffer given to the read() call was on the stack, and when he attempted to read past it it would scribble over the rest of the stack page. If we hit the end of the file on a DIO READ request, then we don't want to zero out the rest of the buffer. These aren't pagecache pages after all, and there's no guarantee that the buffers that were passed in represent entire pages. Reported-by:
Eryu Guan <eguan@redhat.com> Cc: Fred Isaman <iisaman@netapp.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Sven Wegener authored
commit 7d3e91a8 upstream. Commit 1f1ea6c2 "NFSv4: Fix buffer overflow checking in __nfs4_get_acl_uncached" accidently dropped the checking for too small result buffer length. If someone uses getxattr on "system.nfs4_acl" on an NFSv4 mount supporting ACLs, the ACL has not been cached and the buffer suplied is too short, we still copy the complete ACL, resulting in kernel and user space memory corruption. Signed-off-by:
Sven Wegener <sven.wegener@stealer.net> Signed-off-by:
-
Jeff Layton authored
commit 81d9bce5 upstream. Jian reported that the following sequence would leave "testfile" with corrupt data: # mount localhost:/export /mnt/nfs/ -o vers=3 # echo abc > /mnt/nfs/testfile; echo def >> /export/testfile; echo ghi >> /mnt/nfs/testfile # cat -v /export/testfile abc ^@^@^@^@ghi While there's no locking involved here, the operations are serialized, so CTO should prevent corruption. The first write to the file is fine and writes 4 bytes. The file is then extended on the server. When it's reopened a GETATTR is issued and the size change is noticed. This causes NFS_INO_INVALID_DATA to be set on the file. Because the file is opened for write only, nfs_want_read_modify_write() returns 0 to nfs_write_begin(). nfs_updatepage then calls nfs_write_pageuptodate() to see if it should extend the nfs_page to cover the whole page. NFS_INO_INVALID_DATA is still set on the file at that point, but that flag is ignored and nfs_pageuptodate erroneously extends the write to cover the whole page, with the write done on the server side filled in with zeroes. This patch just has that function check for NFS_INO_INVALID_DATA in addition to NFS_INO_REVAL_PAGECACHE. This fixes the bug, but looking over the code, I wonder if we might have a similar bug in nfs_revalidate_size(). The difference between those two flags is very subtle, so it seems like we ought to be checking for NFS_INO_INVALID_DATA in most of the places that we look for NFS_INO_REVAL_PAGECACHE. I believe this is regression introduced by commit 8d197a56. The code did check for NFS_INO_INVALID_DATA prior to that patch. Original bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=885743Reported-by:
Jian Li <jiali@redhat.com> Signed-off-by:
-
Bryan Schumaker authored
commit 6bdb5f21 upstream. If I mount an NFS v4.1 server to a single client multiple times and then run xfstests over each mountpoint I usually get the client into a state where recovery deadlocks. The server informs the client of a cb_path_down sequence error, the client then does a bind_connection_to_session and checks the status of the lease. I found that bind_connection_to_session sets the NFS4_SESSION_DRAINING flag on the client, but this flag is never unset before nfs4_check_lease() reaches nfs4_proc_sequence(). This causes the client to deadlock, halting all NFS activity to the server. nfs4_proc_sequence() is only called by the state manager, so I can change it to run in privileged mode to bypass the NFS4_SESSION_DRAINING check and avoid the deadlock. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 4f5f64cf upstream. At one point acpi_device_set_id() checks if acpi_device_hid(device) returns NULL, but that never happens, so system bus devices with an empty list of PNP IDs are given the dummy HID ("device") instead of the "system bus HID" ("LNXSYBUS"). Fix the code to use the right check. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Aaron Lu authored
commit 0d0cdb02 upstream. Commit 66fa7f21 "libata-acpi: improve ACPI disabling" introdcued the behaviour of disabling ATA ACPI if ata_acpi_on_devcfg failed the 2nd time, but commit 30dcf76a dropped this behaviour and this caused problem for Dimitris Damigos, where his laptop can not resume correctly. The bugzilla page for it is: https://bugzilla.kernel.org/show_bug.cgi?id=49331 The problem is, ata_dev_push_id will fail the 2nd time it is invoked, and due to disabling ACPI code is dropped, ata_acpi_on_devcfg which calls ata_dev_push_id will keep failing and eventually made the device disabled. This patch restores the original behaviour, if acpi failed the 2nd time, disable acpi functionality for the device(and we do not event need to add a debug message for this as it is still there ;-). Reported-by:
Dimitris Damigos <damigos@freemail.gr> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Zhang Rui authored
commit 0ac1b1d7 upstream. The current acpisleep DMI checks only run when CONFIG_SUSPEND is set. And this may break hibernation on some platforms when CONFIG_SUSPEND is cleared. Move acpisleep DMI check into #ifdef CONFIG_ACPI_SLEEP instead. [rjw: Added acpi_sleep_dmi_check() and rebased on top of earlier patches adding entries to acpisleep_dmi_table[].] References: https://bugzilla.kernel.org/show_bug.cgi?id=45921Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit e79cc615 upstream. I think this is wrong since 72c973dd ("usb: gadget: add usb_endpoint_descriptor to struct usb_ep"). If we fail to allocate an ep or bail out early we shouldn't check for the descriptor which is assigned at ep_enable() time. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Tatyana Brokhman <tlinder@codeaurora.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 0f9df939 upstream. The "video->minor = -1" assigment is done in V4L2 by video_register_device() so it is removed here. Now. uvc_function_bind() calls in error case uvc_function_unbind() for cleanup. The problem is that uvc_function_unbind() frees the uvc struct and uvc_bind_config() does as well in error case of usb_add_function(). Removing kfree() in usb_add_function() would make the patch smaller but it would look odd because the new allocated memory is not cleaned up. However it is not guaranteed that if we call usb_add_function() we also get to the bind function. Therefore the patch extracts the conditional cleanup from uvc_function_unbind() applies to uvc_function_bind(). uvc_function_unbind() now contains only the complete cleanup which is required once everything has been registrated. Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit fad8deb2 upstream. The descriptor list for FS speed was not NULL terminated. This patch fixes this. While here one of the twe two bAlternateSetting assignments for the BOT interface. Both assign 0, one is enough. Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit d0eca719 upstream. Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit d185039f upstream. The HS descriptors are only created if HS is supported by the UDC but we never free them. Signed-off-by:
-
Lothar Waßmann authored
commit 98c35534 upstream. The pointer to a platform_device struct must not be dereferenced after the device has been unregistered. This bug produces a crash when unloading the ci13xxx kernel module compiled with CONFIG_PAGE_POISONING enabled. Signed-off-by:
Lothar Waßmann <LW@KARO-electronics.de> Acked-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
-
Christian Lamparter authored
commit 4010fe21 upstream. This patch adds USBIDs for: - DrayTek Vigor 530 - Zoom 4410a It also adds a note about Gemtek WUBI-100GW and SparkLAN WL-682 USBID conflict [WUBI-100GW is a ISL3886+NET2280 (LM86 firmare) solution, whereas WL-682 is a ISL3887 (LM87 firmware)] device. Source: <http://www.wikidevi.com/wiki/Intersil/p54/usb/windows> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Tomasz Guszkowski authored
commit 3194b7fc upstream. Added USB ID for T-Com Sinus 154 data II. Signed-off-by:
Tomasz Guszkowski <tsg@o2.pl> Acked-by:
-
Jussi Kivilinna authored
commit 4c3de592 upstream. Incorrect use of usb_alloc_coherent memory as input buffer to usb_control_msg can cause problems in arch DMA code, for example kernel BUG at 'arch/arm/include/asm/dma-mapping.h:321' on ARM (linux-3.4). Change _usb_writeN_sync use kmalloc'd buffer instead. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Dan Williams authored
commit 0370acd4 upstream. Signed-off-by:
Dan Williams <dcbw@redhat.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Henningsson authored
commit 6d3cd5d4 upstream. The mute LED is in this case connected to the Mic1 VREF. The machine also exposes the following string in BIOS: "HP_Mute_LED_0_A", so if more machines are coming, it probably makes sense to try to do something more generic, like for the IDT codec. BugLink: https://bugs.launchpad.net/bugs/1096789Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 8ae5865e upstream. Fix the quirk entry for HP Pavilion dv7 in order to make the bass speaker working. Reported-and-tested-by:
Tomas Pospisek <tpo2@sourcepole.ch> Signed-off-by:
-
Takashi Iwai authored
commit b78562b1 upstream. The workaround to force VREF50 for dallas/hp model with ALC861VD was introduced in commit 8fdcb6fe, but it contained wrong pincap override bits. This patch fixes to exclude VREF80 pincap bit correctly. Signed-off-by:
-
Takashi Iwai authored
commit 6169b673 upstream. We've seen the broken HDMI *video* output on some machines with GM965, and the debugging session pointed that the culprit is the disabled audio output pins. Toggling these pins dynamically on demand caused flickering of HDMI TV. This patch changes the behavior to keep the pin ON constantly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421Signed-off-by:
-
Takashi Iwai authored
commit 63a077e2 upstream. Acer Aspire One 522 has the infamous digital mic unit that needs the phase inversion fixup for stereo. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=715737Signed-off-by:
-
Takashi Iwai authored
commit 6eb827d2 upstream. The runtime_idle callback is the right place to check the suspend capability, but currently we do it wrongly in the runtime_suspend callback. This leads to a kernel error message like: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11 and the runtime PM core would even repeat the attempts. Reported-and-tested-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Takashi Iwai authored
commit f5f16541 upstream. The commit [88a8516a: ALSA: usbaudio: implement USB autosuspend] added the support of autopm for USB MIDI output, but it didn't take the MIDI input into account. This patch adds the following for fixing the autopm: - Manage the URB start at the first MIDI input stream open, instead of the time of instance creation - Move autopm code to the common substream_open() - Make snd_usbmidi_input_start/_stop() more robust and add the running state check Reviewd-by:
Clemens Ladisch <clemens@ladisch.de> Tested-by:
-
Takashi Iwai authored
commit 59866da9 upstream. Add a similar protection against the disconnection race and the invalid use of usb instance after disconnection, as well as we've done for the USB audio PCM. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51201Reviewd-by:
-
Hugh Dickins authored
commit f2a07f40 upstream. Recently I suggested using "mount -o remount,mpol=local /tmp" in NUMA mempolicy testing. Very nasty. Reading /proc/mounts, /proc/pid/mounts or /proc/pid/mountinfo may then corrupt one bit of kernel memory, often in a page table (causing "Bad swap" or "Bad page map" warning or "Bad pagetable" oops), sometimes in a vm_area_struct or rbnode or somewhere worse. "mpol=prefer" and "mpol=prefer:Node" are equally toxic. Recent NUMA enhancements are not to blame: this dates back to 2.6.35, when commit e17f74af "mempolicy: don't call mpol_set_nodemask() when no_context" skipped mpol_parse_str()'s call to mpol_set_nodemask(), which used to initialize v.preferred_node, or set MPOL_F_LOCAL in flags. With slab poisoning, you can then rely on mpol_to_str() to set the bit for node 0x6b6b, probably in the next page above the caller's stack. mpol_parse_str() is only called from shmem_parse_options(): no_context is always true, so call it unused for now, and remove !no_context code. Set v.nodes or v.preferred_node or MPOL_F_LOCAL as mpol_to_str() might expect. Then mpol_to_str() can ignore its no_context argument also, the mpol being appropriately initialized whether contextualized or not. Rename its no_context unused too, and let subsequent patch remove them (that's not needed for stable backporting, which would involve rejects). I don't understand why MPOL_LOCAL is described as a pseudo-policy: it's a reasonable policy which suffers from a confusing implementation in terms of MPOL_PREFERRED with MPOL_F_LOCAL. I believe this would be much more robust if MPOL_LOCAL were recognized in switch statements throughout, MPOL_F_LOCAL deleted, and MPOL_PREFERRED use the (possibly empty) nodes mask like everyone else, instead of its preferred_node variant (I presume an optimization from the days before MPOL_LOCAL). But that would take me too long to get right and fully tested. Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christoffer Dall authored
commit ad4b3fb7 upstream. Unfortunately with !CONFIG_PAGEFLAGS_EXTENDED, (!PageHead) is false, and (PageHead) is true, for tail pages. If this is indeed the intended behavior, which I doubt because it breaks cache cleaning on some ARM systems, then the nomenclature is highly problematic. This patch makes sure PageHead is only true for head pages and PageTail is only true for tail pages, and neither is true for non-compound pages. [ This buglet seems ancient - seems to have been introduced back in Apr 2008 in commit 6a1e7f77: "pageflags: convert to the use of new macros". And the reason nobody noticed is because the PageHead() tests are almost all about just sanity-checking, and only used on pages that are actual page heads. The fact that the old code returned true for tail pages too was thus not really noticeable. - Linus ] Signed-off-by:
Christoffer Dall <cdall@cs.columbia.edu> Acked-by:
Andrea Arcangeli <aarcange@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Will Deacon <Will.Deacon@arm.com> Cc: Steve Capper <Steve.Capper@arm.com> Cc: Christoph Lameter <cl@linux.com> Signed-off-by:
-
Sonny Rao authored
commit c8b74c2f upstream. The system uses global_dirtyable_memory() to calculate number of dirtyable pages/pages that can be allocated to the page cache. A bug causes an underflow thus making the page count look like a big unsigned number. This in turn confuses the dirty writeback throttling to aggressively write back pages as they become dirty (usually 1 page at a time). This generally only affects systems with highmem because the underflowed count gets subtracted from the global count of dirtyable memory. The problem was introduced with v3.2-4896-gab8fabd4 Fix is to ensure we don't get an underflowed total of either highmem or global dirtyable memory. Signed-off-by:
Sonny Rao <sonnyrao@chromium.org> Signed-off-by:
Puneet Kumar <puneetster@chromium.org> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Tested-by:
Damien Wyart <damien.wyart@free.fr> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Will Deacon authored
commit b92b1b89 upstream. Virtio devices may attempt to add descriptors to a virtqueue from atomic context using GFP_ATOMIC allocation. This is problematic because such allocations can fall outside of the lowmem mapping, causing virt_to_phys to report bogus physical addresses which are subsequently passed to userspace via the buffers for the virtual device. This patch masks out __GFP_HIGH and __GFP_HIGHMEM from the requested flags when allocating descriptors for a virtqueue. If an atomic allocation is requested and later fails, we will return -ENOSPC which will be handled by the driver. Signed-off-by:
Will Deacon <will.deacon@arm.com> Cc: Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Will Deacon authored
commit b9cdc88d upstream. When using a virtio transport, the 9p net device may pass the physical address of a kernel buffer to userspace via a scatterlist inside a virtqueue. If the kernel buffer is mapped outside of the linear mapping (e.g. highmem), then virt_to_page will return a bogus value and we will populate the scatterlist with junk. This patch uses kmap_to_page when populating the page array for a kernel buffer. Signed-off-by:
-
Will Deacon authored
commit f0263d2d upstream. Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace. This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules. Signed-off-by:
-
Ondrej Zary authored
commit ad686524 upstream. Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to enable A20 line but resume code assumes that KBC was used. The laptop will not resume from S3 otherwise but powers off after a while and then powers on again stuck with a blank screen. Fix it by enabling A20 using KBC in i8042_platform_init for x86. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=12878Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Rafael J. Wysocki <rjw@sisk.pl> Link: http://lkml.kernel.org/r/201212112218.06551.linux@rainbow-software.orgSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Will Deacon authored
commit 304ef4e8 upstream. To allow debuggers to unwind through signal frames, we create a fake stack unwinding prologue containing the link register and frame pointer of the interrupted context. The signal frame is then offset by 16 bytes to make room for the two saved registers which are pushed onto the frame of the *interrupted* context, rather than placed directly above the signal stack. This doesn't work when an alternative signal stack is set up for a SEGV handler, which is raised in response to RLIMIT_STACK being reached. In this case, we try to push the unwinding prologue onto the full stack and subsequently take a fault which we fail to resolve, causing setup_return to return -EFAULT and handle_signal to force_sigsegv on the current task. This patch fixes the problem by including the unwinding prologue as part of the rt_sigframe definition, which is populated during setup_sigframe, ensuring that it always ends up on the signal stack. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Catalin Marinas authored
commit 33eaa58f upstream. The AArch64 Linux port relies on the mm code to wrprotect clean ptes. This however is not the case with newly created ptes and PAGE_SHARED(_EXEC) is writable but !dirty. Signed-off-by:
-
Kees Cook authored
commit b66c5984 upstream. If a series of scripts are executed, each triggering module loading via unprintable bytes in the script header, kernel stack contents can leak into the command line. Normally execution of binfmt_script and binfmt_misc happens recursively. However, when modules are enabled, and unprintable bytes exist in the bprm->buf, execution will restart after attempting to load matching binfmt modules. Unfortunately, the logic in binfmt_script and binfmt_misc does not expect to get restarted. They leave bprm->interp pointing to their local stack. This means on restart bprm->interp is left pointing into unused stack memory which can then be copied into the userspace argv areas. After additional study, it seems that both recursion and restart remains the desirable way to handle exec with scripts, misc, and modules. As such, we need to protect the changes to interp. This changes the logic to require allocation for any changes to the bprm->interp. To avoid adding a new kmalloc to every exec, the default value is left as-is. Only when passing through binfmt_script or binfmt_misc does an allocation take place. For a proof of concept, see DoTest.sh from: http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: halfdog <me@halfdog.net> Cc: P J P <ppandit@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Robin Holt authored
commit 891348ca upstream. We found a user code which was raising a divide-by-zero trap. That trap would lead to XPC connections between system-partitions being torn down due to the die_chain notifier callouts it received. This also revealed a different issue where multiple callers into xpc_die_deactivate() would all attempt to do the disconnect in parallel which would sometimes lock up but often overwhelm the console on very large machines as each would print at least one line of output at the end of the deactivate. I reviewed all the users of the die_chain notifier and changed the code to ignore the notifier callouts for reasons which will not actually lead to a system to continue on to call die(). [akpm@linux-foundation.org: fix ia64] Signed-off-by:
Robin Holt <holt@sgi.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alan Cox authored
commit cdc87c5a upstream. TEST_ALPHA() is broken and always returns 0. [akpm@linux-foundation.org: return false for '@' as well, per Bjorn] Signed-off-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Felix Fietkau authored
commit 78f18df4 upstream. ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for tx packets passed to the driver from mac80211 Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Larry Finger authored
commit 576d28a7 upstream. Recent versions of udev cause synchronous firmware loading from the probe routine to fail because the request to user space times out. The original fix for b43legacy (commit a3ea2c76) moved the firmware load from the probe routine to a work queue, but it still used synchronous firmware loading. This method is OK when b43legacy is built as a module; however, it fails when the driver is compiled into the kernel. This version changes the code to load the initial firmware file using request_firmware_nowait(). A completion event is used to hold the work queue until that file is available. The remaining firmware files are read synchronously. Signed-off-by:
-
