xavi/android_kernel_m2note/sound, branch ng-7.1.2

ALSA: pcm: Fix possible OOB access in PCM oss plugins

2019-09-11T12:26:36+00:00

commit ca0214ee2802dd47239a4e39fb21c5b00ef61b22 upstream. The PCM OSS emulation converts and transfers the data on the fly via "plugins". The data is converted over the dynamically allocated buffer for each plugin, and recently syzkaller caught OOB in this flow. Although the bisection by syzbot pointed out to the commit 65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer allocations"), this is merely a commit to replace vmalloc() with kvmalloc(), hence it can't be the cause. The further debug action revealed that this happens in the case where a slave PCM doesn't support only the stereo channels while the OSS stream is set up for a mono channel. Below is a brief explanation: At each OSS parameter change, the driver sets up the PCM hw_params again in snd_pcm_oss_change_params_lock(). This is also the place where plugins are created and local buffers are allocated. The problem is that the plugins are created before the final hw_params is determined. Namely, two snd_pcm_hw_param_near() calls for setting the period size and periods may influence on the final result of channels, rates, etc, too, while the current code has already created plugins beforehand with the premature values. So, the plugin believes that channels=1, while the actual I/O is with channels=2, which makes the driver reading/writing over the allocated buffer size. The fix is simply to move the plugin allocation code after the final hw_params call. Change-Id: Iba66743ab3e8152be10104432758f6994941a10d Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

ALSA: seq: oss: Fix Spectre v1 vulnerability

2019-09-11T12:26:36+00:00

commit c709f14f0616482b67f9fbcb965e1493a03ff30b upstream. dev is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap) Fix this by sanitizing dev before using it to index dp->synths. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Change-Id: Iee6ea225b165fec2d01a09c5d24eea22099a3a53 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: rawmidi: Fix potential Spectre v1 vulnerability

2019-09-11T12:26:36+00:00

commit 2b1d9c8f87235f593826b9cf46ec10247741fff9 upstream. info->stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap) Fix this by sanitizing info->stream before using it to index rmidi->streams. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ Change-Id: I2c8b93b82ad4374027a03dc4c73fdf74eee696e6 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

ALSA: pcm: Fix potential Spectre v1 vulnerability

2019-05-02T16:09:38+00:00

commit 94ffb030b6d31ec840bb811be455dd2e26a4f43e upstream. stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/pcm.c:140 snd_pcm_control_ioctl() warn: potential spectre issue 'pcm->streams' [r] (local cap) Fix this by sanitizing stream before using it to index pcm->streams Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Change-Id: I5fd73f88a116ada553b9f2495674fdc01be6b661 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings

ALSA: pcm: Don't suspend stream in unrecoverable PCM state

2019-05-02T16:09:25+00:00

commit 113ce08109f8e3b091399e7cc32486df1cff48e7 upstream. Currently PCM core sets each opened stream forcibly to SUSPENDED state via snd_pcm_suspend_all() call, and the user-space is responsible for re-triggering the resume manually either via snd_pcm_resume() or prepare call. The scheme works fine usually, but there are corner cases where the stream can't be resumed by that call: the streams still in OPEN state before finishing hw_params. When they are suspended, user-space cannot perform resume or prepare because they haven't been set up yet. The only possible recovery is to re-open the device, which isn't nice at all. Similarly, when a stream is in DISCONNECTED state, it makes no sense to change it to SUSPENDED state. Ditto for in SETUP state; which you can re-prepare directly. So, this patch addresses these issues by filtering the PCM streams to be suspended by checking the PCM state. When a stream is in either OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend action is skipped. To be noted, this problem was originally reported for the PCM runtime PM on HD-audio. And, the runtime PM problem itself was already addressed (although not intended) by the code refactoring commits 3d21ef0b49f8 ("ALSA: pcm: Suspend streams globally via device type PM ops") and 17bc4815de58 ("ALSA: pci: Remove superfluous snd_pcm_suspend*() calls"). These commits eliminated the snd_pcm_suspend*() calls from the runtime PM suspend callback code path, hence the racy OPEN state won't appear while runtime PM. (FWIW, the race window is between snd_pcm_open_substream() and the first power up in azx_pcm_open().) Although the runtime PM issue was already "fixed", the same problem is still present for the system PM, hence this patch is still needed. And for stable trees, this patch alone should suffice for fixing the runtime PM problem, too. Change-Id: I60531a00278ab5d4a04b04012417f53610b131db Reported-and-tested-by: Jon Hunter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

Revert "GCC: Fix up for gcc 5+"

2018-11-29T23:02:49+00:00

This reverts commit ff505baaf412985af758d5820cd620ed9f1a7e05.

Replace with globally

2018-11-29T16:49:05+00:00

This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*' sed -i -e "s!$PATT!#include !" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Moyster

sound: core: fix warning: this 'if' clause does not guard...

2018-11-29T12:51:22+00:00

[-Wmisleading-indentation] in function 'snd_timer_user_read' /home/oyster/Github/android_kernel_m2note/sound/core/timer.c: In function 'snd_timer_user_read': /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1986:4: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (copy_to_user(buffer, &tu->tqueue[qhead], ^~ /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1989:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' err = -EFAULT; ^~~ /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1991:4: warning: this 'if' clause does not guard... [-Wmisleading-indentation] if (copy_to_user(buffer, &tu->queue[qhead], ^~ /home/oyster/Github/android_kernel_m2note/sound/core/timer.c:1994:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' err = -EFAULT; ^~~

GCC: Fix up for gcc 5+

2018-11-29T11:38:19+00:00

Signed-off-by: mydongistiny Signed-off-by: Mister Oyster

usb: replace %p with %pK

2018-11-27T15:09:55+00:00

Format specifier %p can leak kernel addresses while not valuing the kptr_restrict system settings. When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0's. Debugging Note : &pK prints only Zeros as address. If you need actual address information, write 0 to kptr_restrict. echo 0 > /proc/sys/kernel/kptr_restrict CRs-fixed: 1052849 Change-Id: I0e98145730380ea983fa8f46a28d15dd6c2c31df Signed-off-by: Manu Gautam Signed-off-by: Yasir Malik Signed-off-by: Kevin F. Haggerty