- 29 Nov, 2013 28 commits
-
-
Stanislaw Gruszka authored
commit 3d8bfe14 upstream. Since: commit 36323f81 Author: Thomas Huehn <thomas@net.t-labs.tu-berlin.de> Date: Mon Jul 23 21:33:42 2012 +0200 mac80211: move TX station pointer and restructure TX we do not pass sta pointer to rt2x00queue_create_tx_descriptor_ht(), hence we do not correctly set station WCID and AMPDU density parameters. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Gabor Juhos authored
commit 0beb1bbf upstream. In commit 3d81535e (rt2800: 5592: add chip specific vgc calculations) the rt2800_link_tuner function has been modified to adjust VGC level for the RT5592 chipset. On the RT5592 chipset, the VGC level must be adjusted only if rssi is greater than -65. However the current code adjusts the VGC value by 0x10 regardless of the actual chipset if the rssi value is between -80 and -65. Fix the broken behaviour by reordering the if-else statements. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
Stanislaw Gruszka authored
commit 5671ab05 upstream. Fix random kernel panic with below messages when remove dongle. [ 2212.355447] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250 [ 2212.355527] IP: [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.355599] PGD 0 [ 2212.355626] Oops: 0000 [#1] SMP [ 2212.355664] Modules linked in: rt2800usb rt2x00usb rt2800lib crc_ccitt rt2x00lib mac80211 cfg80211 tun arc4 fuse rfcomm bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb uvcvideo bluetooth snd_hwdep x86_pkg_temp_thermal snd_seq coretemp aesni_intel aes_x86_64 snd_seq_device glue_helper snd_pcm ablk_helper videobuf2_vmalloc sdhci_pci videobuf2_memops videobuf2_core sdhci videodev mmc_core serio_raw snd_page_alloc microcode i2c_i801 snd_timer hid_multitouch thinkpad_acpi lpc_ich mfd_core snd tpm_tis wmi tpm tpm_bios soundcore acpi_cpufreq i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: cfg80211] [ 2212.356224] CPU: 0 PID: 34 Comm: khubd Not tainted 3.12.0-rc3-wl+ #3 [ 2212.356268] Hardware name: LENOVO 3444CUU/3444CUU, BIOS G6ET93WW (2.53 ) 02/04/2013 [ 2212.356319] task: ffff880212f687c0 ti: ffff880212f66000 task.ti: ffff880212f66000 [ 2212.356392] RIP: 0010:[<ffffffffa02667f2>] [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.356481] RSP: 0018:ffff880212f67750 EFLAGS: 00010202 [ 2212.356519] RAX: 000000000000000c RBX: 000000000000000c RCX: 0000000000000293 [ 2212.356568] RDX: ffff8801f4dc219a RSI: 0000000000000000 RDI: 0000000000000240 [ 2212.356617] RBP: ffff880212f67778 R08: ffffffffa02667e0 R09: 0000000000000002 [ 2212.356665] R10: 0001f95254ab4b40 R11: ffff880212f675be R12: ffff8801f4dc2150 [ 2212.356712] R13: 0000000000000000 R14: ffffffffa02667e0 R15: 000000000000000d [ 2212.356761] FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000 [ 2212.356813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2212.356852] CR2: 0000000000000250 CR3: 0000000001a0c000 CR4: 00000000001407f0 [ 2212.356899] Stack: [ 2212.356917] 000000000000000c ffff8801f4dc2150 0000000000000000 ffffffffa02667e0 [ 2212.356980] 000000000000000d ffff880212f677b8 ffffffffa03a31ad ffff8801f4dc219a [ 2212.357038] ffff8801f4dc2150 0000000000000000 ffff8800b93217a0 ffff8801f49bc800 [ 2212.357099] Call Trace: [ 2212.357122] [<ffffffffa02667e0>] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb] [ 2212.357174] [<ffffffffa03a31ad>] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib] [ 2212.357244] [<ffffffffa026701c>] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb] [ 2212.357314] [<ffffffffa03a3682>] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib] [ 2212.357386] [<ffffffffa03a2930>] rt2x00mac_flush+0x30/0x70 [rt2x00lib] [ 2212.357470] [<ffffffffa04edded>] ieee80211_flush_queues+0xbd/0x140 [mac80211] [ 2212.357555] [<ffffffffa0502e52>] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211] [ 2212.357645] [<ffffffffa0506da3>] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211] [ 2212.357718] [<ffffffff8108b17c>] ? try_to_wake_up+0xec/0x290 [ 2212.357788] [<ffffffffa04dbd18>] ieee80211_deauth+0x18/0x20 [mac80211] [ 2212.357872] [<ffffffffa0418ddc>] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211] [ 2212.357913] [<ffffffffa041907c>] cfg80211_mlme_down+0x5c/0x60 [cfg80211] [ 2212.357962] [<ffffffffa041cd18>] cfg80211_disconnect+0x188/0x1a0 [cfg80211] [ 2212.358014] [<ffffffffa04013bc>] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211] [ 2212.358067] [<ffffffffa03f8954>] cfg80211_leave+0xc4/0xe0 [cfg80211] [ 2212.358124] [<ffffffffa03f8d1b>] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211] [ 2212.358177] [<ffffffff815140f8>] ? inetdev_event+0x38/0x510 [ 2212.358217] [<ffffffff81085a94>] ? __wake_up+0x44/0x50 [ 2212.358254] [<ffffffff8155995c>] notifier_call_chain+0x4c/0x70 [ 2212.358293] [<ffffffff81081156>] raw_notifier_call_chain+0x16/0x20 [ 2212.358361] [<ffffffff814b6dd5>] call_netdevice_notifiers_info+0x35/0x60 [ 2212.358429] [<ffffffff814b6ec9>] __dev_close_many+0x49/0xd0 [ 2212.358487] [<ffffffff814b7028>] dev_close_many+0x88/0x100 [ 2212.358546] [<ffffffff814b8150>] rollback_registered_many+0xb0/0x220 [ 2212.358612] [<ffffffff814b8319>] unregister_netdevice_many+0x19/0x60 [ 2212.358694] [<ffffffffa04d8eb2>] ieee80211_remove_interfaces+0x112/0x190 [mac80211] [ 2212.358791] [<ffffffffa04c585f>] ieee80211_unregister_hw+0x4f/0x100 [mac80211] [ 2212.361994] [<ffffffffa03a1221>] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib] [ 2212.365240] [<ffffffffa0266e2e>] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb] [ 2212.368470] [<ffffffff81419ce4>] usb_unbind_interface+0x64/0x1c0 [ 2212.371734] [<ffffffff813b446f>] __device_release_driver+0x7f/0xf0 [ 2212.374999] [<ffffffff813b4503>] device_release_driver+0x23/0x30 [ 2212.378131] [<ffffffff813b3c98>] bus_remove_device+0x108/0x180 [ 2212.381358] [<ffffffff813b0565>] device_del+0x135/0x1d0 [ 2212.384454] [<ffffffff81417760>] usb_disable_device+0xb0/0x270 [ 2212.387451] [<ffffffff8140d9cd>] usb_disconnect+0xad/0x1d0 [ 2212.390294] [<ffffffff8140f6cd>] hub_thread+0x63d/0x1660 [ 2212.393034] [<ffffffff8107c860>] ? wake_up_atomic_t+0x30/0x30 [ 2212.395728] [<ffffffff8140f090>] ? hub_port_debounce+0x130/0x130 [ 2212.398412] [<ffffffff8107baa0>] kthread+0xc0/0xd0 [ 2212.401058] [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40 [ 2212.403639] [<ffffffff8155de3c>] ret_from_fork+0x7c/0xb0 [ 2212.406193] [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40 [ 2212.408732] Code: 24 58 08 00 00 bf 80 00 00 00 e8 3a c3 e0 e0 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 47 10 48 89 fb 4c 8b 6f 28 4c 8b 20 49 8b 04 24 4c 8b 30 [ 2212.414671] RIP [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb] [ 2212.417646] RSP <ffff880212f67750> [ 2212.420547] CR2: 0000000000000250 [ 2212.441024] ---[ end trace 5442918f33832bce ]--- Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
-
Felix Fietkau authored
commit b4089d6d upstream. Commit "rt2x00: fix HT TX descriptor settings regression" assumes that the control parameter to rt2x00mac_tx is always non-NULL. There is an internal call in rt2x00lib_bc_buffer_iter where NULL is passed. Fix the resulting crash by adding an initialized dummy on-stack ieee80211_tx_control struct. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Acked-by:
-
Rafael J. Wysocki authored
commit 176a88d7 upstream. According to the ACPI spec (5.0, Section 6.3.5), the "Device insertion in progress (pending)" (0x80) _OST status code is reserved for the "Insertion Processing" (0x200) source event which is "a result of an OSPM action". Specifically, it is not a notification, so that status code should not be used during notification processing, which unfortunately is done by acpi_scan_bus_device_check(). For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST status evaluation from there (it was a mistake to put it in there in the first place). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 2441191a upstream. It is required to do get_device() on the struct acpi_device in question before passing it to acpi_bus_hot_remove_device() through acpi_os_hotplug_execute(), because acpi_bus_hot_remove_device() calls acpi_scan_hot_remove() that does put_device() on that object. The ACPI PCI root removal routine, handle_root_bridge_removal(), doesn't do that, which may lead to premature freeing of the device object or to executing put_device() on an object that has been freed already. Fix this problem by making handle_root_bridge_removal() use get_device() as appropriate. Signed-off-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
-
Aaron Lu authored
commit 2c62333a upstream. Some firmware doesn't initialize initial backlight level to a proper value and _BQC will return 0 on first time evaluation. We used to be able to detect such incorrect value with our code logic, as value 0 normally isn't a valid value in _BCL. But with the introduction of Win8, firmware begins to fill _BCL with values from 0 to 100, now 0 becomes a valid value but that value will make user's screen black. This patch test initial _BQC for value 0, if such a value is returned, do not use it. References: https://bugzilla.kernel.org/show_bug.cgi?id=64031 References: https://bugzilla.kernel.org/show_bug.cgi?id=61231 References: https://bugzilla.kernel.org/show_bug.cgi?id=63111Reported-by:
Qingshuai Tian <qingshuai.tian@intel.com> Tested-by: Aaron Lu <aaron.lu@intel.com> # on "Idealpad u330p" Reported-and-tested-by: <erno@iki.fi> # on "Acer Aspire V5-573G" Reported-and-tested-by: Kirill Tkhai <tkhai@yandex.ru> # on "HP 250 G1" Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
-
Puneet Kumar authored
commit 36b15875 upstream. A bug was introduced by commit b76b51ba ('ACPI / EC: Add more debug info and trivial code cleanup') that erroneously caused the struct member to be accessed before acquiring the required lock. This change fixes it by ensuring the lock acquisition is done first. Found by Aaron Durbin <adurbin@chromium.org> Fixes: b76b51ba ('ACPI / EC: Add more debug info and trivial code cleanup') References: http://crbug.com/319019Signed-off-by:
Puneet Kumar <puneetster@chromium.org> Reviewed-by:
Aaron Durbin <adurbin@chromium.org> [olof: Commit message reworded a bit] Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Steven Rostedt authored
commit 12ae030d upstream. The current default perf paranoid level is "1" which has "perf_paranoid_kernel()" return false, and giving any operations that use it, access to normal users. Unfortunately, this includes function tracing and normal users should not be allowed to enable function tracing by default. The proper level is defined at "-1" (full perf access), which "perf_paranoid_tracepoint_raw()" will only give access to. Use that check instead for enabling function tracing. Reported-by:
Dave Jones <davej@redhat.com> Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Bjorn Helgaas authored
commit 6d3a1741 upstream. Previously we allowed callers to access Slot Capabilities, Status, and Control for Root Ports even if the Root Port did not implement a slot. This seems dubious because the spec only requires these registers if a slot is implemented. It's true that even Root Ports without slots must have *space* for these slot registers, because the Root Capabilities, Status, and Control registers are after the slot registers in the capability. However, for a v1 PCIe Capability, the *semantics* of the slot registers are undefined unless a slot is implemented. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-By:
Jiang Liu <jiang.liu@huawei.com> Acked-by:
Myron Stowe <myron.stowe@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
commit c8b303d0 upstream. Previously we relied on the PCIe r3.0, sec 7.8, spec language that says "For Functions that do not implement the [Link, Slot, Root] registers, these spaces must be hardwired to 0b," which means that for v2 PCIe capabilities, we don't need to check the device type at all. But it's simpler if we don't need to check the capability version at all, and I think the spec is explicit enough about which registers are required for which types that we can remove the version checks. Signed-off-by:
-
Bjorn Helgaas authored
commit d3694d4f upstream. Every PCIe device has a link, except Root Complex Integrated Endpoints and Root Complex Event Collectors. Previously we didn't give access to PCIe capability link-related registers for Upstream Ports, Downstream Ports, and Bridges, so attempts to read PCI_EXP_LNKCTL incorrectly returned zero. See PCIe spec r3.0, sec 7.8 and 1.3.2.3. Reference: http://lkml.kernel.org/r/979A8436335E3744ADCD3A9F2A2B68A52AD136BE@SJEXCHMB10.corp.ad.broadcom.comReported-by:
Yuval Mintz <yuvalmin@broadcom.com> Signed-off-by:
-
Peter Zijlstra authored
commit ea811747 upstream. Mike reported that commit 7d1a9417 ("x86: Use generic idle loop") regressed several workloads and caused excessive reschedule interrupts. The patch in question failed to notice that the x86 code had an inverted sense of the polling state versus the new generic code (x86: default polling, generic: default !polling). Fix the two prominent x86 mwait based idle drivers and introduce a few new generic polling helpers (fixing the wrong smp_mb__after_clear_bit usage). Also switch the idle routines to using tif_need_resched() which is an immediate TIF_NEED_RESCHED test as opposed to need_resched which will end up being slightly different. Reported-by:
Mike Galbraith <bitbucket@online.de> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: lenb@kernel.org Cc: tglx@linutronix.de Link: http://lkml.kernel.org/n/tip-nc03imb0etuefmzybzj7sprf@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Andy Adamson authored
commit f1ff0c27 upstream. The NFS layer needs to know when a key has expired. This change also returns -EKEYEXPIRED to the application, and the informative "Key has expired" error message is displayed. The user then knows that credential renewal is required. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Ilia Mirkin authored
commit 02d69294 upstream. Commits 0a9e2b95 (drm/nvd0/disp: move HDA codec setup to core) and a4feaf4e (drm/nva3/disp: move hda codec handling to core) moved code around but neglected to fill data up to 0x60 as before. This caused /proc/asound/cardN/eld#3.0 to show eld_valid as 0. With this patch, that file is again populated with the correct data. See https://bugs.freedesktop.org/show_bug.cgi?id=67051Reported-and-tested-by:
Alex <alupu01@gmail.com> Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Emil Velikov authored
commit 9a7046d5 upstream. Unused and irrelavant since the code move of DP training/linkcontrol interrupt Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Greg Thelen authored
commit a399b29d upstream. When IPC_RMID races with other shm operations there's potential for use-after-free of the shm object's associated file (shm_file). Here's the race before this patch: TASK 1 TASK 2 ------ ------ shm_rmid() ipc_lock_object() shmctl() shp = shm_obtain_object_check() shm_destroy() shum_unlock() fput(shp->shm_file) ipc_lock_object() shmem_lock(shp->shm_file) <OOPS> The oops is caused because shm_destroy() calls fput() after dropping the ipc_lock. fput() clears the file's f_inode, f_path.dentry, and f_path.mnt, which causes various NULL pointer references in task 2. I reliably see the oops in task 2 if with shmlock, shmu This patch fixes the races by: 1) set shm_file=NULL in shm_destroy() while holding ipc_object_lock(). 2) modify at risk operations to check shm_file while holding ipc_object_lock(). Example workloads, which each trigger oops... Workload 1: while true; do id=$(shmget 1 4096) shm_rmid $id & shmlock $id & wait done The oops stack shows accessing NULL f_inode due to racing fput: _raw_spin_lock shmem_lock SyS_shmctl Workload 2: while true; do id=$(shmget 1 4096) shmat $id 4096 & shm_rmid $id & wait done The oops stack is similar to workload 1 due to NULL f_inode: touch_atime shmem_mmap shm_mmap mmap_region do_mmap_pgoff do_shmat SyS_shmat Workload 3: while true; do id=$(shmget 1 4096) shmlock $id shm_rmid $id & shmunlock $id & wait done The oops stack shows second fput tripping on an NULL f_inode. The first fput() completed via from shm_destroy(), but a racing thread did a get_file() and queued this fput(): locks_remove_flock __fput ____fput task_work_run do_notify_resume int_signal Fixes: c2c737a0 ("ipc,shm: shorten critical region for shmat") Fixes: 2caacaa8 ("ipc,shm: shorten critical region for shmctl") Signed-off-by:
Greg Thelen <gthelen@google.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Rik van Riel <riel@redhat.com> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jesper Nilsson authored
commit 3a72660b upstream. Commit 2caacaa8 ("ipc,shm: shorten critical region for shmctl") restructured the ipc shm to shorten critical region, but introduced a path where the return value could be -EPERM, even if the operation actually was performed. Before the commit, the err return value was reset by the return value from security_shm_shmctl() after the if (!ns_capable(...)) statement. Now, we still exit the if statement with err set to -EPERM, and in the case of SHM_UNLOCK, it is not reset at all, and used as the return value from shmctl. To fix this, we only set err when errors occur, leaving the fallthrough case alone. Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Rik van Riel <riel@redhat.com> Cc: Michel Lespinasse <walken@google.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Markus Pargmann authored
commit 5d0f801a upstream. If we handle end of block messages with higher priority than a lost message, we can run into an endless interrupt loop. This is reproducable with a am335x processor and "cansequence -r" at 1Mbit. As soon as we loose a packet we can't escape from an interrupt loop. This patch fixes the problem by handling lost packets before EOB packets. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Herbert Xu authored
commit f262f0f5 upstream. The cbc-aes-s390 algorithm incorrectly places the IV in the tfm data structure. As the tfm is shared between multiple threads, this introduces a possibility of data corruption. This patch fixes this by moving the parameter block containing the IV and key onto the stack (the block is 48 bytes long). The same bug exists elsewhere in the s390 crypto system and they will be fixed in subsequent patches. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Neil Horman authored
commit 714b33d1 upstream. Stephan Mueller reported to me recently a error in random number generation in the ansi cprng. If several small requests are made that are less than the instances block size, the remainder for loop code doesn't increment rand_data_valid in the last iteration, meaning that the last bytes in the rand_data buffer gets reused on the subsequent smaller-than-a-block request for random data. The fix is pretty easy, just re-code the for loop to make sure that rand_data_valid gets incremented appropriately Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Reported-by:
Stephan Mueller <stephan.mueller@atsec.com> CC: Stephan Mueller <stephan.mueller@atsec.com> CC: Petr Matousek <pmatouse@redhat.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Olivier Sobrie authored
commit 896e23bd upstream. Some devices, like the Kvaser Memorator Professional, have several bulk in endpoints. Only the first one found must be used by the driver. The same holds for the bulk out endpoint. The official Kvaser driver (leaf) was used as reference for this patch. Signed-off-by:
Olivier Sobrie <olivier@sobrie.be> Signed-off-by:
-
Johan Hovold authored
commit a91ccd26 upstream. Make sure to return errors from tiocmget rather than rely on uninitialised stack data. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Bob Moore authored
commit 4be4be8f upstream. This change fixes a problem where a Store operation to an ArgX object that contained a reference to a field object did not complete the automatic dereference and then write to the actual field object. Instead, the object type of the field object was inadvertently changed to match the type of the source operand. The new behavior will actually write to the field object (buffer field or field unit), thus matching the correct ACPI-defined behavior. Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
-
Bob Moore authored
commit a50abf48 upstream. Disallow the dereference of a reference (via index) to an uninitialized package element. Provides compatibility with other ACPI implementations. ACPICA BZ 1003. References: https://bugs.acpica.org/show_bug.cgi?id=431Signed-off-by:
-
Mahesh Rajashekhara authored
commit b4789b8e upstream. It appears that driver runs into a problem here if fibsize is too small because we allocate user_srbcmd with fibsize size only but later we access it until user_srbcmd->sg.count to copy it over to srbcmd. It is not correct to test (fibsize < sizeof(*user_srbcmd)) because this structure already includes one sg element and this is not needed for commands without data. So, we would recommend to add the following (instead of test for fibsize == 0). Signed-off-by:
Mahesh Rajashekhara <Mahesh.Rajashekhara@pmcs.com> Reported-by:
Nico Golde <nico@ngolde.de> Reported-by:
Fabian Yamaguchi <fabs@goesec.de> Signed-off-by:
-
Dan Carpenter authored
commit a497e47d upstream. If we do a zero size allocation then it will oops. Also we can't be sure the user passes us a NUL terminated string so I've added a terminator. This code can only be triggered by root. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Bob Moore authored
commit 63660e05 upstream. Previously, references to these objects were resolved only to the actual FieldUnit or BufferField object. The correct behavior is to resolve these references to an actual value. The problem is that DerefOf did not resolve these objects to actual values. An "Integer" object is simple, return the value. But a field in an operation region will require a read operation. For a BufferField, the appropriate data must be extracted from the parent buffer. NOTE: It appears that this issues is present in Windows7 but not Windows8. Signed-off-by:
-
- 20 Nov, 2013 12 commits
-
-
Greg Kroah-Hartman authored
-
Dan Carpenter authored
commit 47c32ec9 upstream. The "i < " part of the "i < ARRAY_SIZE()" condition was missing. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Xenia Ragiadakou authored
commit 9df89d85 upstream. This patch sets the lpm_capable field for root hubs with LPM capabilities. Signed-off-by:
Xenia Ragiadakou <burzalodowa@gmail.com> Reported-by:
Martin MOKREJS <mmokrejs@gmail.com> Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Krzysztof Mazur authored
commit e58547eb upstream. Ignoring usb_hub_create_port_device() errors cause later NULL pointer deference when uninitialized hub->ports[i] entries are dereferenced after port memory allocation error. Signed-off-by:
Krzysztof Mazur <krzysiek@podlesie.net> Acked-by:
-
Krzysztof Mazur authored
commit d0308d4b upstream. If the hub_configure() fails after setting the hdev->maxchild the hub->ports might be NULL or point to uninitialized kzallocated memory causing NULL pointer dereference in hub_quiesce() during cleanup. Now after such error the hdev->maxchild is set to 0 to avoid cleanup of uninitialized ports. Signed-off-by:
-
Johan Hovold authored
commit 9d3fde86 upstream. Move probe out of __init section and don't use platform_driver_probe which cannot be used with deferred probing. Since commit e9354576 ("gpiolib: Defer failed gpio requests by default") this driver might return -EPROBE_DEFER if a gpio_request fails. Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Signed-off-by:
-
Johan Hovold authored
commit 5c6d6fd1 upstream. Two drivers (atmel-pwm-bl and leds-atmel-pwm) currently depend on the atmel_pwm driver to have bound to any pwm-device before their devices are probed. Support deferred probing of such devices by making sure to return -EPROBE_DEFER from pwm_channel_alloc when no pwm-device has yet been bound. Signed-off-by:
-
Matti Gottlieb authored
commit b4992662 upstream. Add some new PCI IDs to the table for 7000 & 3160 series Signed-off-by:
Matti Gottlieb <matti.gottlieb@intel.com> Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Oren Givon authored
commit 93fc6411 upstream. Add new device IDs and configurations to support all the devices. Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
-
Peter Zijlstra authored
commit bf378d34 upstream. The PPC64 people noticed a missing memory barrier and crufty old comments in the perf ring buffer code. So update all the comments and add the missing barrier. When the architecture implements local_t using atomic_long_t there will be double barriers issued; but short of introducing more conditional barrier primitives this is the best we can do. Reported-by:
Victor Kaplansky <victork@il.ibm.com> Tested-by:
-
Steven Rostedt authored
commit 057db848 upstream. Andrey reported the following report: ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3 ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3) Accessed by thread T13003: #0 ffffffff810dd2da (asan_report_error+0x32a/0x440) #1 ffffffff810dc6b0 (asan_check_region+0x30/0x40) #2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20) #3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260) #4 ffffffff812a1065 (__fput+0x155/0x360) #5 ffffffff812a12de (____fput+0x1e/0x30) #6 ffffffff8111708d (task_work_run+0x10d/0x140) #7 ffffffff810ea043 (do_exit+0x433/0x11f0) #8 ffffffff810eaee4 (do_group_exit+0x84/0x130) #9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30) #10 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Allocated by thread T5167: #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0) #1 ffffffff8128337c (__kmalloc+0xbc/0x500) #2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90) #3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0) #4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40) #5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430) #6 ffffffff8129b668 (finish_open+0x68/0xa0) #7 ffffffff812b66ac (do_last+0xb8c/0x1710) #8 ffffffff812b7350 (path_openat+0x120/0xb50) #9 ffffffff812b8884 (do_filp_open+0x54/0xb0) #10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0) #11 ffffffff8129d4b7 (SyS_open+0x37/0x50) #12 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Shadow bytes around the buggy address: ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap redzone: fa Heap kmalloc redzone: fb Freed heap region: fd Shadow gap: fe The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;' Although the crash happened in ftrace_regex_open() the real bug occurred in trace_get_user() where there's an incrementation to parser->idx without a check against the size. The way it is triggered is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop that reads the last character stores it and then breaks out because there is no more characters. Then the last character is read to determine what to do next, and the index is incremented without checking size. Then the caller of trace_get_user() usually nulls out the last character with a zero, but since the index is equal to the size, it writes a nul character after the allocated space, which can corrupt memory. Luckily, only root user has write access to this file. Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.homeReported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
-
Anssi Hannula authored
commit 56cac413 upstream. hdmi_setup_fake_chmap() is supposed to set the reported channel map when the channel map is not specified by the user. However, the function indexes channel_allocations[] with a wrong value and extracts the wrong nibble from hdmi_channel_mapping[], causing wrong channel maps to be shown. Fix those issues. Tested on Intel HDMI to correctly generate various channel maps, for example 3,4,14,15,7,8,5,6 (instead of incorrect 3,4,8,7,5,6,14,0) for standard 7.1 channel audio. (Note that the side and rear channels are reported as RL/RR and RLC/RRC, respectively, as per the CEA-861 standard, instead of the more traditional SL/SR and RL/RR.) Note that this only fixes the layouts that only contain traditional 7.1 speakers (2.0, 2.1, 4.0, 5.1, 7.1, etc.). E.g. the rear center of 6.1 is still being shown wrongly due to an issue with from_cea_slot() which will be fixed in a later patch. Signed-off-by:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
