summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-11-29ALSA: compress: fix drain calls blocking other compress functionsVinod Koul
commit 917f4b5cba78980a527098a910d94139d3e82c8d upstream. The drain and drain_notify callback were blocked by low level driver untill the draining was complete. Due to this being invoked with big fat mutex held, others ops like reading timestamp, calling pause, drop were blocked. So to fix this we add a new snd_compr_drain_notify() API. This would be required to be invoked by low level driver when drain or partial drain has been completed by the DSP. Thus we make the drain and partial_drain callback as non blocking and driver returns immediately after notifying DSP. The waiting is done while relasing the lock so that other ops can go ahead. Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ALSA: 6fire: Fix probe of multiple cardsTakashi Iwai
commit 9b389a8a022110b4bc055a19b888283544d9eba6 upstream. The probe code of snd-usb-6fire driver overrides the devices[] pointer wrongly without checking whether it's already occupied or not. This would screw up the device disconnection later. Spotted by coverity CID 141423. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29exec/ptrace: fix get_dumpable() incorrect testsKees Cook
commit d049f74f2dbe71354d43d393ac3a188947811348 upstream. The get_dumpable() return value is not boolean. Most users of the function actually want to be testing for non-SUID_DUMP_USER(1) rather than SUID_DUMP_DISABLE(0). The SUID_DUMP_ROOT(2) is also considered a protected state. Almost all places did this correctly, excepting the two places fixed in this patch. Wrong logic: if (dumpable == SUID_DUMP_DISABLE) { /* be protective */ } or if (dumpable == 0) { /* be protective */ } or if (!dumpable) { /* be protective */ } Correct logic: if (dumpable != SUID_DUMP_USER) { /* be protective */ } or if (dumpable != 1) { /* be protective */ } Without this patch, if the system had set the sysctl fs/suid_dumpable=2, a user was able to ptrace attach to processes that had dropped privileges to that user. (This may have been partially mitigated if Yama was enabled.) The macros have been moved into the file that declares get/set_dumpable(), which means things like the ia64 code can see them too. CVE-2013-2929 Reported-by: Vasily Kulikov <segoon@openwall.com> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29Revert "ima: policy for RAMFS"Mimi Zohar
commit 08de59eb144d7c41351a467442f898d720f0f15f upstream. This reverts commit 4c2c392763a682354fac65b6a569adec4e4b5387. Everything in the initramfs should be measured and appraised, but until the initramfs has extended attribute support, at least measured. Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29Bluetooth: revert: "Bluetooth: Add missing reset_resume dev_pm_ops"Hans de Goede
commit b1a8014471b01dd862de9f91bbbff1296afac42d upstream. Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These devices default to hid mode for BIOS use. This means that after having been reset they will revert to HID mode, and are no longer usable as a HCI. Therefor it is a very bad idea to just blindly make reset_resume point to the regular resume handler. Note that the btusb driver has no clue how to switch these devices from hid to hci mode, this is done in userspace through udev rules, so the proper way to deal with this is to not have a reset-resume handler and instead let the usb-system re-enumerate the device, and re-run the udev rules. I must also note, that the commit message for the commit causing this problem has a very weak motivation for the change: "Add missing reset_resume dev_pm_ops. Missing reset_resume results in the following message after power management device test. This change sets reset_resume to btusb_resume(). [ 2506.936134] btusb 1-1.5:1.0: no reset_resume for driver btusb? [ 2506.936137] btusb 1-1.5:1.1: no reset_resume for driver btusb?" Making a change solely to silence a warning while also changing important behavior (normal resume handling versus re-enumeration) requires a commit message with a proper explanation why it is safe to do so, which clearly lacks here, and unsurprisingly it turns out to not be safe to make this change. Reverting the commit in question fixes bt no longer working on my Dell E6430 after a suspend/resume, and I believe it likely also fixes the following bugs: https://bugzilla.redhat.com/show_bug.cgi?id=988481 https://bugzilla.redhat.com/show_bug.cgi?id=1010649 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1213239 This reverts commit 502f769662978a2fe99d0caed5e53e3006107381. Cc: Shuah Khan <shuah.kh@samsung.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29rt2x00: fix HT TX descriptor settings regressionStanislaw Gruszka
commit 3d8bfe141be8e5c21261fc63da8e7964d44f2645 upstream. Since: commit 36323f817af0376c78612cfdab714b0feb05fea5 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>
2013-11-29rt2x00: rt2800lib: fix VGC adjustment for RT5592Gabor Juhos
commit 0beb1bbf19c72f17809e42b8f33522a55c2cc18c upstream. In commit 3d81535ea5940446510a8a5cee1c6ad23c90c753 (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: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29rt2x00: check if device is still available on rt2x00mac_flush()Stanislaw Gruszka
commit 5671ab05cf2a579218985ef56595387932d78ee4 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: Stanislaw Gruszka <stf_xl@wp.pl> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29rt2x00: fix a crash bug in the HT descriptor handling fixFelix Fietkau
commit b4089d6d8e71a7293e2192025dfa507a04f661c4 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: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29Drivers: hv: vmbus: Fix a bug in channel rescind codeK. Y. Srinivasan
commit 565ce6422ff92f5af71e4d5a09f78215433b2695 upstream. Rescind of subchannels were not being correctly handled. Fix the bug. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29lkdtm: isolate stack corruption testKees Cook
commit 629c66a22c21b692b6e58b9c1d8fa56a60ccb52d upstream. When tests were added to lkdtm that grew the stack frame, the stack corruption test stopped working. This isolates the test in its own function, and forces it not to be inlined. Signed-off-by: Kees Cook <keescook@chromium.org> Fixes: cc33c537c12f ("lkdtm: add "EXEC_*" triggers") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29staging: comedi: avoid memleak for subdevice privateIan Abbott
commit 67aa4acbc97f6a55b328e4e2305ef19cbe949d85 upstream. `comedi_alloc_spriv()` allocates private storage for a comedi subdevice and sets the `SRF_FREE_SPRIV` flag in the `runflags` member of the subdevice to allow the private storage to be automatically freed when the comedi device is being cleaned up. Unfortunately, the flag gets clobbered by `do_cmd_ioctl()` which calls `comedi_set_subdevice_runflags()` with a mask value `~0` and only the `SRF_USER` and `SRF_RUNNING` flags set, all the other SRF flags being cleared. Change the calls to `comedi_set_subdevice_runflags()` that currently use a mask value of `~0` to use a more relevant mask value. For `do_cmd_ioctl()`, the relevant SRF flags are `SRF_USER`, `SRF_ERROR` and `SRF_RUNNING`. (At one time, `SRF_RT` would be included in that set of flags, but it is no longer used.) For `comedi_alloc_spriv()` replace the call to `comedi_set_subdevice_runflags()` with a simple OR-assignment to avoid unnecessary use of a spin-lock. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29staging: r8188eu: Set device type to wlanLarry Finger
commit 0d1206be229697f897f00822bc142e66da731417 upstream. The latest version of NetworkManager does not recognize the device as wireless without this change. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29Staging: zram: Fix access of NULL pointerRashika Kheria
commit 46a51c80216cb891f271ad021f59009f34677499 upstream. This patch fixes the bug in reset_store caused by accessing NULL pointer. The bdev gets its value from bdget_disk() which could fail when memory pressure is severe and hence can return NULL because allocation of inode in bdget could fail. Hence, this patch introduces a check for bdev to prevent reference to a NULL pointer in the later part of the code. It also removes unnecessary check of bdev for fsync_bdev(). Acked-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Acked-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ACPI / hotplug: Do not execute "insert in progress" _OSTRafael J. Wysocki
commit 176a88d79d6b5aebabaff16734e8b3107efcaaad 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ACPI / hotplug: Fix handle_root_bridge_removal()Rafael J. Wysocki
commit 2441191a19039002b2c454a261fb45986df15184 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ACPI / video: Quirk initial backlight level 0Aaron Lu
commit 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 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=63111 Reported-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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ACPI / EC: Ensure lock is acquired before accessing ec struct membersPuneet Kumar
commit 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb upstream. A bug was introduced by commit b76b51ba0cef ('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: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup') References: http://crbug.com/319019 Signed-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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29perf/ftrace: Fix paranoid level for enabling function tracerSteven Rostedt
commit 12ae030d54ef250706da5642fc7697cc60ad0df7 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: Vince Weaver <vincent.weaver@maine.edu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> CVE: CVE-2013-2930 Fixes: ced39002f5ea ("ftrace, perf: Add support to use function tracepoint in perf") Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29sched, idle: Fix the idle polling state logicPeter Zijlstra
commit ea8117478918a4734586d35ff530721b682425be 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.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ARM: OMAP2+: hwmod: check for module address space during initSuman Anna
commit 6423d6df1440a8acfc2f375d7cbc4cd66c2e6910 upstream. The hwmod init sequence involves initializing and idling all the hwmods during bootup. If a module class has sysconfig, the init sequence utilizes the module register base for performing any sysc configuration. The module address space is being removed from hwmod database and retrieved from the <reg> property of the corresponding DT node. If a hwmod does not have its corresponding DT node defined and the memory address space is not defined in the corresponding omap_hwmod_ocp_if, then the module register target address space would be NULL and any sysc programming would result in a NULL pointer dereference and a kernel boot hang. Handle this scenario by checking for a valid module address space during the _init of each hwmod, and leaving it in the registered state if no module register address base is defined in either of the hwmod data or the DT data. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> [paul@pwsan.com: use -ENXIO rather than -ENOMEM to indicate a missing address space error; fixed checkpatch.pl problem] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29thinkpad_acpi: Fix build error when CONFIG_SND_MAX_CARDS > 32Takashi Iwai
commit cab6661344f14a09d7aecdf821a40f68ef9b18cc upstream. SNDRV_CARDS can be specified via Kconfig since 3.11 kernel, so this can be over 32bit integer range, which leads to a build error. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29drm/nvc0-/gr: fix a number of missing explicit array terminators...Ben Skeggs
commit 13d2b35a065399fb447c84e80368927e5f8bf086 upstream. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29staging: ashmem: Fix ASHMEM_PURGE_ALL_CACHES return valueJohn Stultz
commit 5957324045ba2c127c9401fa3ac61ac52e043ca8 upstream. Hopefully this isn't too late for 3.12. In commit 7dc19d5aff (convert shrinkers to new count/scan API) the return value to PURGE_ALL_CACHES was dropped, causing -EPERM to always be returned. This patch re-adds the ret assignment, setting it to the the ashmem_shrink_count(), which is the lru_count. (Sorry this was missed in the review!) Fixes: 7dc19d5affd7 ("convert shrinkers to new count/scan API") Cc: Colin Cross <ccross@android.com> Cc: Android Kernel Team <kernel-team@android.com> Cc: Glauber Costa <glommer@openvz.org> Reported-by: YongQin Liu <yongqin.liu@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Acked-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29drm: shmobile: Add dependency on BACKLIGHT_CLASS_DEVICELaurent Pinchart
commit 0a5a5499ad886dde4a032203d01e324cfe593f99 upstream. The driver registers a backlight device and thus requires BACKLIGHT_CLASS_DEVICE to be selected to avoid compilation breakages. Reported-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ipc,shm: fix shm_file deletion racesGreg Thelen
commit a399b29dfbaaaf91162b2dc5a5875dd51bbfa2a1 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: c2c737a0461e ("ipc,shm: shorten critical region for shmat") Fixes: 2caacaa82a51 ("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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29ipc,shm: correct error return value in shmctl (SHM_UNLOCK)Jesper Nilsson
commit 3a72660b07d86d60457ca32080b1ce8c2b628ee2 upstream. Commit 2caacaa82a51 ("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: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29alx: Reset phy speed after resumehahnjo
commit b54629e226d196e802abdd30c5e34f2a47cddcf2 upstream. This fixes bug 62491 (https://bugzilla.kernel.org/show_bug.cgi?id=62491). After resuming some users got the following error flooding the kernel log: alx 0000:02:00.0: invalid PHY speed/duplex: 0xffff Signed-off-by: Jonas Hahnfeld <linux@hahnjo.de> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: hahnjo <linux@hahnjo.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29can: c_can: Fix RX message handling, handle lost message before EOBMarkus Pargmann
commit 5d0f801a2ccec3b1fdabc3392c8d99ed0413d216 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29crypto: s390 - Fix aes-cbc IV corruptionHerbert Xu
commit f262f0f5cad0c9eca61d1d383e3b67b57dcbe5ea 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29crypto: ansi_cprng - Fix off by one error in non-block size requestNeil Horman
commit 714b33d15130cbb5ab426456d4e3de842d6c5b8a 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: Herbert Xu <herbert@gondor.apana.org.au> Cc: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29Btrfs: relocate csums properly with prealloc extentsJosef Bacik
commit 4577b014d1bc3db386da3246f625888fc48083a9 upstream. A user reported a problem where they were getting csum errors when running a balance and running systemd's journal. This is because systemd is awesome and fallocate()'s its log space and writes into it. Unfortunately we assume that when we read in all the csums for an extent that they are sequential starting at the bytenr we care about. This obviously isn't the case for prealloc extents, where we could have written to the middle of the prealloc extent only, which means the csum would be for the bytenr in the middle of our range and not the front of our range. Fix this by offsetting the new bytenr we are logging to based on the original bytenr the csum was for. With this patch I no longer see the csum errors I was seeing. Thanks, Reported-by: Chris Murphy <lists@colorremedies.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29can: kvaser_usb: fix usb endpoints detectionOlivier Sobrie
commit 896e23bd04ea50a146dffd342e2f96180f0812a5 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: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29USB: mos7840: fix tiocmget error handlingJohan Hovold
commit a91ccd26e75235d86248d018fe3779732bcafd8d 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fieldsEric Sandeen
commit 10e6e65dfcedff63275c3d649d329c044caa8e26 upstream. Today, if xfs_sb_read_verify encounters a v4 superblock with junk past v4 fields which includes data in sb_crc, it will be treated as a failing checksum and a significant corruption. There are known prior bugs which leave junk at the end of the V4 superblock; we don't need to actually fail the verification in this case if other checks pan out ok. So if this is a secondary superblock, and the primary superblock doesn't indicate that this is a V5 filesystem, don't treat this as an actual checksum failure. We should probably check the garbage condition as we do in xfs_repair, and possibly warn about it or self-heal, but that's a different scope of work. Stable folks: This can go back to v3.10, which is what introduced the sb CRC checking that is tripped up by old, stale, incorrect V4 superblocks w/ unzeroed bits. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Acked-by: Dave Chinner <david@fromorbit.com> Reviewed-by: Mark Tinguely <tinguely@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29aacraid: prevent invalid pointer dereferenceMahesh Rajashekhara
commit b4789b8e6be3151a955ade74872822f30e8cd914 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: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29libertas: potential oops in debugfsDan Carpenter
commit a497e47d4aec37aaf8f13509f3ef3d1f6a717d88 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: Nico Golde <nico@ngolde.de> Reported-by: Fabian Yamaguchi <fabs@goesec.de> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-29prepend_path() needs to reinitialize dentry/vfsmount/mnt on restartsAl Viro
commit ede4cebce16f5643c61aedd6d88d9070a1d23a68 upstream. ... and equivalent is needed in 3.12; it's broken there as well Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Reported-by: Michael Marineau <michael.marineau@coreos.com> Tested-by: Waiman Long <Waiman.Long@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20Linux 3.12.1Greg Kroah-Hartman
2013-11-20usbcore: set lpm_capable field for LPM capable root hubsXenia Ragiadakou
commit 9df89d85b407690afa46ddfbccc80bec6869971d 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20backlight: atmel-pwm-bl: fix deferred probe from __initJohan Hovold
commit 9d3fde86b15303decea632c929fbf1f3ae4501f2 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 <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20misc: atmel_pwm: add deferred-probing supportJohan Hovold
commit 5c6d6fd1564138ad048564e48639f842714a90c6 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: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20tracing: Fix potential out-of-bounds in trace_get_user()Steven Rostedt
commit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb 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.home Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20ALSA: hda - hdmi: Fix reported channel map on common default layoutsAnssi Hannula
commit 56cac413dd6d43af8355f5d1f90a199b540f73fc 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20USB: add new zte 3g-dongle's pid to option.cRui li
commit 0636fc507a976cdc40f21bdbcce6f0b98ff1dfe9 upstream. Signed-off-by: Rui li <li.rui27@zte.com.cn> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20hyperv-fb: add pci stubGerd Hoffmann
commit 7ad9684721606efbfb9b347346816e1e6baff8bb upstream. This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer driver will bind to the pci device then, so linux kernel and userspace know there is a proper kernel driver for the device active. lspci shows this for example: [root@dhcp231 ~]# lspci -vs8 00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f8000000 (32-bit, non-prefetchable) [size=64M] Expansion ROM at <unassigned> [disabled] Kernel driver in use: hyperv_fb Another effect is that the xorg vesa driver will not attach to the device and thus the Xorg server will automatically use the fbdev driver instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20ipv6: reset dst.expires value when clearing expire flagHannes Frederic Sowa
[ Upstream commit 01ba16d6ec85a1ec4669c75513a76b61ec53ee50 ] On receiving a packet too big icmp error we update the expire value by calling rt6_update_expires. This function uses dst_set_expires which is implemented that it can only reduce the expiration value of the dst entry. If we insert new routing non-expiry information into the ipv6 fib where we already have a matching rt6_info we only clear the RTF_EXPIRES flag in rt6i_flags and leave the dst.expires value as is. When new mtu information arrives for that cached dst_entry we again call dst_set_expires. This time it won't update the dst.expire value because we left the dst.expire value intact from the last update. So dst_set_expires won't touch dst.expires. Fix this by resetting dst.expires when clearing the RTF_EXPIRE flag. dst_set_expires checks for a zero expiration and updates the dst.expires. In the past this (not updating dst.expires) was necessary because dst.expire was placed in a union with the dst_entry *from reference and rt6_clean_expires did assign NULL to it. This split happend in ecd9883724b78cc72ed92c98bcb1a46c764fff21 ("ipv6: fix race condition regarding dst->expires and dst->from"). Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Reported-by: Valentijn Sessink <valentyn@blub.net> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Acked-by: Eric Dumazet <edumazet@google.com> Tested-by: Valentijn Sessink <valentyn@blub.net> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20ipv6: ip6_dst_check needs to check for expired dst_entriesHannes Frederic Sowa
[ Upstream commit e3bc10bd95d7fcc3f2ac690c6ff22833ea6781d6 ] On receiving a packet too big icmp error we check if our current cached dst_entry in the socket is still valid. This validation check did not care about the expiration of the (cached) route. The error path I traced down: The socket receives a packet too big mtu notification. It still has a valid dst_entry and thus issues the ip6_rt_pmtu_update on this dst_entry, setting RTF_EXPIRE and updates the dst.expiration value (which could fail because of not up-to-date expiration values, see previous patch). In some seldom cases we race with a) the ip6_fib gc or b) another routing lookup which would result in a recreation of the cached rt6_info from its parent non-cached rt6_info. While copying the rt6_info we reinitialize the metrics store by copying it over from the parent thus invalidating the just installed pmtu update (both dsts use the same key to the inetpeer storage). The dst_entry with the just invalidated metrics data would just get its RTF_EXPIRES flag cleared and would continue to stay valid for the socket. We should have not issued the pmtu update on the already expired dst_entry in the first placed. By checking the expiration on the dst entry and doing a relookup in case it is out of date we close the race because we would install a new rt6_info into the fib before we issue the pmtu update, thus closing this race. Not reliably updating the dst.expire value was fixed by the patch "ipv6: reset dst.expires value when clearing expire flag". Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Reported-by: Valentijn Sessink <valentyn@blub.net> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Tested-by: Valentijn Sessink <valentyn@blub.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20tcp: do not rearm RTO when future data are sackedYuchung Cheng
[ Upstream commit 2f715c1dde6e1760f3101358dc26f8c9489be0bf ] Patch ed08495c3 "tcp: use RTT from SACK for RTO" always re-arms RTO upon obtaining a RTT sample from newly sacked data. But technically RTO should only be re-armed when the data sent before the last (re)transmission of write queue head are (s)acked. Otherwise the RTO may continue to extend during loss recovery on data sent in the future. Note that RTTs from ACK or timestamps do not have this problem, as the RTT source must be from data sent before. The new RTO re-arm policy is 1) Always re-arm RTO if SND.UNA is advanced 2) Re-arm RTO if sack RTT is available, provided the sacked data was sent before the last time write_queue_head was sent. Signed-off-by: Larry Brakmo <brakmo@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-11-20tcp: only take RTT from timestamps if new data is ackedYuchung Cheng
[ Upstream commit 2909d874f34eae157aecab0af27c6dc4a1751f8f ] Patch ed08495c3 "tcp: use RTT from SACK for RTO" has a bug that it does not check if the ACK acknowledge new data before taking the RTT sample from TCP timestamps. This patch adds the check back as required by the RFC. Signed-off-by: Yuchung Cheng <ycheng@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v0.10.2 at 2024-10-02 17:29:19 (GMT)