commit 8719027e78c77c31d338c616265caeb25887cf84 Author: Greg Kroah-Hartman Date: Wed May 2 07:53:43 2018 -0700 Linux 4.4.131 commit ea548dec031ee95bcfe849aeabd1590b903fe767 Author: Romain Izard Date: Tue Feb 23 15:54:54 2016 +0100 serial: mctrl_gpio: Add missing module license commit 82a3f87f6e80e0bf7978152021eb8938976721cb upstream. As the mctrl_gpio driver can be built as a module, it needs to have its license specified with MODULE_LICENSE. Otherwise, it cannot access required symbols exported through EXPORT_SYMBOL_GPL. Signed-off-by: Romain Izard Acked-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman Cc: Daniel Wagner Signed-off-by: Greg Kroah-Hartman commit b017e9dd4925c9e44774efb1046f93de12d4dcf4 Author: Uwe Kleine-König Date: Sun Dec 13 11:30:02 2015 +0100 serial: mctrl_gpio: export mctrl_gpio_disable_ms and mctrl_gpio_init commit 4f71a2e0a282611e55bacb60b564eaef5d16c27b upstream. To be able to make use of the mctrl-gpio helper from a module these functions must be exported. This was forgotten in the commit introducing support interrupt handling for these functions (while it was done for mctrl_gpio_enable_ms, *sigh*). Fixes: ce59e48fdbad ("serial: mctrl_gpio: implement interrupt handling") Signed-off-by: Uwe Kleine-König Cc: Daniel Wagner Signed-off-by: Greg Kroah-Hartman commit d6080794595351d35124dc1e9c2bdfa196a7d248 Author: Yazen Ghannam Date: Tue Apr 3 09:02:28 2018 -0500 x86/smpboot: Don't use mwait_play_dead() on AMD systems commit da6fa7ef67f07108a1b0cb9fd9e7fcaabd39c051 upstream. Recent AMD systems support using MWAIT for C1 state. However, MWAIT will not allow deeper cstates than C1 on current systems. play_dead() expects to use the deepest state available. The deepest state available on AMD systems is reached through SystemIO or HALT. If MWAIT is available, it is preferred over the other methods, so the CPU never reaches the deepest possible state. Don't try to use MWAIT to play_dead() on AMD systems. Instead, use CPUIDLE to enter the deepest state advertised by firmware. If CPUIDLE is not available then fallback to HALT. Signed-off-by: Yazen Ghannam Signed-off-by: Thomas Gleixner Reviewed-by: Borislav Petkov Cc: stable@vger.kernel.org Cc: Yazen Ghannam Link: https://lkml.kernel.org/r/20180403140228.58540-1-Yazen.Ghannam@amd.com Signed-off-by: Greg Kroah-Hartman commit 72b4a16e75cad1e9d20640076d9fab843fe4636e Author: Arnd Bergmann Date: Tue Apr 24 23:19:51 2018 +0200 x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds commit 1a512c0882bd311c5b5561840fcfbe4c25b8f319 upstream. A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout (as seen from user space) a few years ago: Originally, __BITS_PER_LONG was defined as 64 on x32, so we did not have padding after the 64-bit __kernel_time_t fields, After __BITS_PER_LONG got changed to 32, applications would observe extra padding. In other parts of the uapi headers we seem to have a mix of those expecting either 32 or 64 on x32 applications, so we can't easily revert the path that broke these two structures. Instead, this patch decouples x32 from the other architectures and moves it back into arch specific headers, partially reverting the even older commit 73a2d096fdf2 ("x86: remove all now-duplicate header files"). It's not clear whether this ever made any difference, since at least glibc carries its own (correct) copy of both of these header files, so possibly no application has ever observed the definitions here. Based on a suggestion from H.J. Lu, I tried out the tool from https://github.com/hjl-tools/linux-header to find other such bugs, which pointed out the same bug in statfs(), which also has a separate (correct) copy in glibc. Fixes: f4b4aae18288 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Cc: "H . J . Lu" Cc: Jeffrey Walton Cc: stable@vger.kernel.org Cc: "H. Peter Anvin" Link: https://lkml.kernel.org/r/20180424212013.3967461-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman commit 0c6679b05baec7506463b1c972ca739463536cbf Author: Ilya Dryomov Date: Tue Apr 24 19:10:55 2018 +0200 libceph: validate con->state at the top of try_write() commit 9c55ad1c214d9f8c4594ac2c3fa392c1c32431a7 upstream. ceph_con_workfn() validates con->state before calling try_read() and then try_write(). However, try_read() temporarily releases con->mutex, notably in process_message() and ceph_con_in_msg_alloc(), opening the window for ceph_con_close() to sneak in, close the connection and release con->sock. When try_write() is called on the assumption that con->state is still valid (i.e. not STANDBY or CLOSED), a NULL sock gets passed to the networking stack: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: selinux_socket_sendmsg+0x5/0x20 Make sure con->state is valid at the top of try_write() and add an explicit BUG_ON for this, similar to try_read(). Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/23706 Signed-off-by: Ilya Dryomov Reviewed-by: Jason Dillaman Signed-off-by: Greg Kroah-Hartman commit 599c76c923309bfc5aa54b593c7c52a2ce82df3e Author: Nicolin Chen Date: Sun Apr 8 16:57:35 2018 -0700 ASoC: fsl_esai: Fix divisor calculation failure at lower ratio commit c656941df9bc80f7ec65b92ca73c42f8b0b62628 upstream. When the desired ratio is less than 256, the savesub (tolerance) in the calculation would become 0. This will then fail the loop- search immediately without reporting any errors. But if the ratio is smaller enough, there is no need to calculate the tolerance because PM divisor alone is enough to get the ratio. So a simple fix could be just to set PM directly instead of going into the loop-search. Reported-by: Marek Vasut Signed-off-by: Nicolin Chen Tested-by: Marek Vasut Reviewed-by: Fabio Estevam Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 30a80ca6dbbda67b0c902448993ed6a35b52612a Author: Geert Uytterhoeven Date: Tue Apr 10 15:21:45 2018 +0200 ARM: amba: Don't read past the end of sysfs "driver_override" buffer commit d2ffed5185df9d8d9ccd150e4340e3b6f96a8381 upstream. When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count + 1 bytes for printing. Cfr. commits 4efe874aace57dba ("PCI: Don't read past the end of sysfs "driver_override" buffer") and bf563b01c2895a4b ("driver core: platform: Don't read past the end of "driver_override" buffer"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven Reviewed-by: Todd Kjos Cc: stable Signed-off-by: Greg Kroah-Hartman commit 7488404d3bab4eccb590c80c8827520394444630 Author: Geert Uytterhoeven Date: Tue Apr 10 15:21:44 2018 +0200 ARM: amba: Fix race condition with driver_override commit 6a7228d90d42bcacfe38786756ba62762b91c20a upstream. The driver_override implementation is susceptible to a race condition when different threads are reading vs storing a different driver override. Add locking to avoid this race condition. Cfr. commits 6265539776a0810b ("driver core: platform: fix race condition with driver_override") and 9561475db680f714 ("PCI: Fix race condition with driver_override"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven Reviewed-by: Todd Kjos Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 0448fd9403b4d77bd4aebc4e892db871d74850c8 Author: Geert Uytterhoeven Date: Tue Apr 10 15:21:43 2018 +0200 ARM: amba: Make driver_override output consistent with other buses commit 5f53624662eaac89598641cee6cd54fc192572d9 upstream. For AMBA devices with unconfigured driver override, the "driver_override" sysfs virtual file is empty, while it contains "(null)" for platform and PCI devices. Make AMBA consistent with other buses by dropping the test for a NULL pointer. Note that contrary to popular belief, sprintf() handles NULL pointers fine; they are printed as "(null)". Signed-off-by: Geert Uytterhoeven Cc: stable Reviewed-by: Todd Kjos Signed-off-by: Greg Kroah-Hartman commit 634602948de7dd0e04a0160f7d24eaad2eaa2b01 Author: Mahesh Rajashekhara Date: Tue Apr 17 17:03:12 2018 +0530 scsi: sd: Defer spinning up drive while SANITIZE is in progress commit 505aa4b6a8834a2300971c5220c380c3271ebde3 upstream. A drive being sanitized will return NOT READY / ASC 0x4 / ASCQ 0x1b ("LOGICAL UNIT NOT READY. SANITIZE IN PROGRESS"). Prevent spinning up the drive until this condition clears. [mkp: tweaked commit message] Signed-off-by: Mahesh Rajashekhara Cc: Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit abb841c5e943316bbf74ddb27d188813b3cba0d9 Author: Dmitry Vyukov Date: Wed Apr 11 17:22:43 2018 +0200 kobject: don't use WARN for registration failures commit 3e14c6abbfb5c94506edda9d8e2c145d79375798 upstream. This WARNING proved to be noisy. The function still returns an error and callers should handle it. That's how most of kernel code works. Downgrade the WARNING to pr_err() and leave WARNINGs for kernel bugs. Signed-off-by: Dmitry Vyukov Reported-by: syzbot+209c0f67f99fec8eb14b@syzkaller.appspotmail.com Reported-by: syzbot+7fb6d9525a4528104e05@syzkaller.appspotmail.com Reported-by: syzbot+2e63711063e2d8f9ea27@syzkaller.appspotmail.com Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit fc1584670f289d3cc9e2c17c0d6ba3a24ae5b785 Author: Joakim Tjernlund Date: Thu Mar 1 14:39:41 2018 +0100 mtd: cfi: cmdset_0002: Do not allow read/write to suspend erase block. commit 7b70eb14392a7cf505f9b358d06c33b5af73d1e7 upstream. Currently it is possible to read and/or write to suspend EB's. Writing /dev/mtdX or /dev/mtdblockX from several processes may break the flash state machine. Taken from cfi_cmdset_0001 driver. Signed-off-by: Joakim Tjernlund Cc: Reviewed-by: Richard Weinberger Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit d519eb768c1e17f1494d539eafdc6c4f0ba318b2 Author: Joakim Tjernlund Date: Thu Mar 1 14:39:40 2018 +0100 mtd: cfi: cmdset_0001: Workaround Micron Erase suspend bug. commit 46a16a2283f9e678a4e26829175e0c37a5191860 upstream. Some Micron chips does not work well wrt Erase suspend for boot blocks. This avoids the issue by not allowing Erase suspend for the boot blocks for the 28F00AP30(1GBit) chip. Signed-off-by: Joakim Tjernlund Cc: Reviewed-by: Richard Weinberger Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 869a31dfe4187038fe3b6033e70141a5e5739ada Author: Joakim Tjernlund Date: Thu Mar 1 14:39:39 2018 +0100 mtd: cfi: cmdset_0001: Do not allow read/write to suspend erase block. commit 6510bbc88e3258631831ade49033537081950605 upstream. Currently it is possible to read and/or write to suspend EB's. Writing /dev/mtdX or /dev/mtdblockX from several processes may break the flash state machine. Signed-off-by: Joakim Tjernlund Cc: Reviewed-by: Richard Weinberger Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 13169025cf309886a73c9b4a75fac8505162be98 Author: Kailang Yang Date: Wed Apr 25 15:31:52 2018 +0800 ALSA: hda/realtek - Add some fixes for ALC233 commit ea04a1dbf8b1d6af759d58e705636fde48583f8f upstream. Fill COEF to change EAPD to verb control. Assigned codec type. This is an additional fix over 92f974df3460 ("ALSA: hda/realtek - New vendor ID for ALC233"). [ More notes: according to Kailang, the chip is 10ec:0235 bonding for ALC233b, which is equivalent with ALC255. It's only used for Lenovo. The chip needs no alc_process_coef_fw() for headset unlike ALC255. ] Signed-off-by: Kailang Yang Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bd54c1122356e73d2421097e82768b57a7f8b478 Author: Takashi Iwai Date: Tue Apr 24 07:50:50 2018 +0200 ALSA: hda: Hardening for potential Spectre v1 commit 69fa6f19b95597618ab30438a27b67ad93daa7c7 upstream. As recently Smatch suggested, one place in HD-audio hwdep ioctl codes may expand the array directly from the user-space value with speculation: sound/pci/hda/hda_local.h:467 get_wcaps() warn: potential spectre issue 'codec->wcaps' As get_wcaps() itself is a fairly frequently called inline function, and there is only one single call with a user-space value, we replace only the latter one to open-code locally with array_index_nospec() hardening in this patch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8cff710ea7d3ae35bdc799ef0f09639ffa459965 Author: Takashi Iwai Date: Tue Apr 24 07:31:54 2018 +0200 ALSA: seq: oss: Hardening for potential Spectre v1 commit 8d218dd8116695ecda7164f97631c069938aa22e upstream. As Smatch recently suggested, a few places in OSS sequencer codes may expand the array directly from the user-space value with speculation, namely there are a significant amount of references to either info->ch[] or dp->synths[] array: sound/core/seq/oss/seq_oss_event.c:315 note_on_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_event.c:362 note_off_event() warn: potential spectre issue 'info->ch' (local cap) sound/core/seq/oss/seq_oss_synth.c:470 snd_seq_oss_synth_load_patch() warn: potential spectre issue 'dp->synths' (local cap) sound/core/seq/oss/seq_oss_event.c:293 note_on_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_event.c:353 note_off_event() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:506 snd_seq_oss_synth_sysex() warn: potential spectre issue 'dp->synths' sound/core/seq/oss/seq_oss_synth.c:580 snd_seq_oss_synth_ioctl() warn: potential spectre issue 'dp->synths' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. We may put array_index_nospec() at each place, but here we take a different approach: - For dp->synths[], change the helpers to retrieve seq_oss_synthinfo pointer directly instead of the array expansion at each place - For info->ch[], harden in a normal way, as there are only a couple of places As a result, the existing helper, snd_seq_oss_synth_is_valid() is replaced with snd_seq_oss_synth_info(). Also, we cover MIDI device where a similar array expansion is done, too, although it wasn't reported by Smatch. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37d11f6e286d975be4a21b02f159ff0594a266f5 Author: Takashi Iwai Date: Tue Apr 24 07:26:59 2018 +0200 ALSA: seq: oss: Fix unbalanced use lock for synth MIDI device commit f5e94b4c6ebdabe0f602d796e0430180927521a0 upstream. When get_synthdev() is called for a MIDI device, it returns the fixed midi_synth_dev without the use refcounting. OTOH, the caller is supposed to unreference unconditionally after the usage, so this would lead to unbalanced refcount. This patch corrects the behavior and keep up the refcount balance also for the MIDI synth device. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 10a249ca58c99e0980383fbc4ec7be7506283b30 Author: David Henningsson Date: Sat Apr 21 14:57:40 2018 +0200 ALSA: core: Report audio_tstamp in snd_pcm_sync_ptr commit f853dcaae2f5bbe021161e421bd1576845bae8f6 upstream. It looks like a simple mistake that this struct member was forgotten. Audio_tstamp isn't used much, and on some archs (such as x86) this ioctl is not used by default, so that might be the reason why this has slipped for so long. Fixes: 4eeaaeaea1ce ("ALSA: core: add hooks for audio timestamps") Signed-off-by: David Henningsson Reviewed-by: Takashi Sakamoto Cc: # v3.8+ Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 210392f6093fa65483a25a77d4397f1654c067bd Author: Takashi Iwai Date: Tue Apr 24 07:45:56 2018 +0200 ALSA: control: Hardening for potential Spectre v1 commit 088e861edffb84879cf0c0d1b02eda078c3a0ffe upstream. As recently Smatch suggested, a few places in ALSA control core codes may expand the array directly from the user-space value with speculation: sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd' sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd' sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. In this patch, we put array_index_nospec() to the common snd_ctl_get_ioff*() helpers instead of each caller. These helpers are also referred from some drivers, too, and basically all usages are to calculate the array index from the user-space value, hence it's better to cover there. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4984b8bb89fc7d0f0415b4a48fc07333f7b7bbca Author: Takashi Iwai Date: Tue Apr 24 08:04:41 2018 +0200 ALSA: rme9652: Hardening for potential Spectre v1 commit f526afcd8f71945c23ce581d7864ace93de8a4f7 upstream. As recently Smatch suggested, one place in RME9652 driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652->channel_map' (local cap) This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7625e9fd5fa9862bce433a36a42d7364e4a6ba3f Author: Takashi Iwai Date: Tue Apr 24 08:03:14 2018 +0200 ALSA: hdspm: Hardening for potential Spectre v1 commit 10513142a7114d251670361ad40cba2c61403406 upstream. As recently Smatch suggested, a couple of places in HDSP MADI driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_out' (local cap) sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_in' (local cap) This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 257e7b73ffb602eebc940f6bd5415355d32d293c Author: Takashi Iwai Date: Tue Apr 24 08:01:48 2018 +0200 ALSA: asihpi: Hardening for potential Spectre v1 commit f9d94b57e30fd1575b4935045b32d738668aa74b upstream. As recently Smatch suggested, a couple of places in ASIHPI driver may expand the array directly from the user-space value with speculation: sound/pci/asihpi/hpimsginit.c:70 hpi_init_response() warn: potential spectre issue 'res_size' (local cap) sound/pci/asihpi/hpioctl.c:189 asihpi_hpi_ioctl() warn: potential spectre issue 'adapters' This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0f3234318b2817683433d6cc9d1c9d98d9770aa3 Author: Takashi Iwai Date: Tue Apr 24 07:56:07 2018 +0200 ALSA: opl3: Hardening for potential Spectre v1 commit 7f054a5bee0987f1e2d4e59daea462421c76f2cb upstream. As recently Smatch suggested, one place in OPL3 driver may expand the array directly from the user-space value with speculation: sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap' This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2 Reported-by: Dan Carpenter Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7717f4f8de215aaad8dca8cd2575f30ad282a082 Author: Tetsuo Handa Date: Wed Apr 25 20:12:31 2018 +0900 tty: Use __GFP_NOFAIL for tty_ldisc_get() commit bcdd0ca8cb8730573afebcaae4138f8f4c8eaa20 upstream. syzbot is reporting crashes triggered by memory allocation fault injection at tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we have tried commit 5362544bebe85071 ("tty: don't panic on OOM in tty_set_ldisc()"). But we reverted that attempt by commit a8983d01f9b7d600 ("Revert "tty: don't panic on OOM in tty_set_ldisc()"") due to reproducible crash. We should spend resource for finding and fixing race condition bugs rather than complicate error paths for 2 * sizeof(void *) bytes allocation failure. [1] https://syzkaller.appspot.com/bug?id=489d33fa386453859ead58ff5171d43772b13aa3 Signed-off-by: Tetsuo Handa Reported-by: syzbot Cc: Michal Hocko Cc: Vegard Nossum Cc: Dmitry Vyukov Cc: Jiri Slaby Cc: Peter Hurley Cc: One Thousand Gnomes Cc: Linus Torvalds Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit c37a5d3c70cc07f77a5805e69ab46841f7c1c839 Author: Tony Lindgren Date: Sat Apr 7 10:19:51 2018 -0700 tty: n_gsm: Fix DLCI handling for ADM mode if debug & 2 is not set commit b2d89ad9c9682e795ed6eeb9ed455789ad6cedf1 upstream. At least on droid 4 with control channel in ADM mode, there is no response to Modem Status Command (MSC). Currently gsmtty_modem_update() expects to have data in dlci->modem_rx unless debug & 2 is set. This means that on droid 4, things only work if debug & 2 is set. Let's fix the issue by ignoring empty dlci->modem_rx for ADM mode. In the AMD mode, CMD_MSC will never respond and gsm_process_modem() won't get called to set dlci->modem_rx. And according to ts_127010v140000p.pdf, MSC is only relevant if basic option is chosen, so let's test for that too. Fixes: ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for control dlci") Cc: linux-serial@vger.kernel.org Cc: Alan Cox Cc: Dan Williams Cc: Jiri Prchal Cc: Jiri Slaby Cc: Marcel Partap Cc: Merlijn Wajer Cc: Michael Nazzareno Trimarchi Cc: Michael Scott Cc: Pavel Machek Cc: Peter Hurley Cc: Russ Gorby Cc: Sascha Hauer Cc: Sebastian Reichel Signed-off-by: Tony Lindgren Cc: stable Signed-off-by: Greg Kroah-Hartman commit 9c389e2be2741da9cba7c572c3e2ab47ed445cce Author: Tony Lindgren Date: Sat Apr 7 10:19:50 2018 -0700 tty: n_gsm: Fix long delays with control frame timeouts in ADM mode commit e9ec22547986dd32c5c70da78107ce35dbff1344 upstream. Commit ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for control dlci") added support for DLCI to stay in Asynchronous Disconnected Mode (ADM). But we still get long delays waiting for commands to other DLCI to complete: --> 5) C: SABM(P) Q> 0) C: UIH(F) Q> 0) C: UIH(F) Q> 0) C: UIH(F) ... This happens because gsm_control_send() sets cretries timer to T2 that is by default set to 34. This will cause resend for T2 times for the control frame. In ADM mode, we will never get a response so the control frame, so retries are just delaying all the commands. Let's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM mode for the control DLCI. Then we can use that in gsm_control_send() to set retries to 1. This means the control frame will be sent once allowing the other end at an opportunity to switch from ADM to ABM mode. Note that retries will be decremented in gsm_control_retransmit() so we don't want to set it to 0 here. Fixes: ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for control dlci") Cc: linux-serial@vger.kernel.org Cc: Alan Cox Cc: Dan Williams Cc: Jiri Prchal Cc: Jiri Slaby Cc: Marcel Partap Cc: Merlijn Wajer Cc: Michael Nazzareno Trimarchi Cc: Michael Scott Cc: Pavel Machek Cc: Peter Hurley Cc: Russ Gorby Cc: Sascha Hauer Cc: Sebastian Reichel Signed-off-by: Tony Lindgren Cc: stable Signed-off-by: Greg Kroah-Hartman commit ed7d4b0c4aaa64190be153f3813540e263a201a2 Author: Tetsuo Handa Date: Thu Apr 5 19:40:16 2018 +0900 tty: Don't call panic() at tty_ldisc_init() commit 903f9db10f18f735e62ba447147b6c434b6af003 upstream. syzbot is reporting kernel panic [1] triggered by memory allocation failure at tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get() and caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init() does not need to call panic() when tty_ldisc_get() failed. [1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187 Signed-off-by: Tetsuo Handa Reported-by: syzbot Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: stable Signed-off-by: Greg Kroah-Hartman commit 7aa90727fda6943274224bc8dde19d346b60ee3f Author: Gerd Hoffmann Date: Tue Apr 3 11:59:04 2018 +0200 drm/virtio: fix vq wait_event condition commit d02d270014f70dcab0117776b81a37b6fca745ae upstream. Wait until we have enough space in the virt queue to actually queue up our request. Avoids the guest spinning in case we have a non-zero amount of free entries but not enough for the request. Cc: stable@vger.kernel.org Reported-by: Alain Magloire Signed-off-by: Gerd Hoffmann Reviewed-by: Dave Airlie Link: http://patchwork.freedesktop.org/patch/msgid/20180403095904.11152-1-kraxel@redhat.com Signed-off-by: Sean Paul Signed-off-by: Greg Kroah-Hartman commit dd807a784fd36f4136516d5858efb6473dda422c Author: Michael S. Tsirkin Date: Fri Apr 20 20:24:23 2018 +0300 virtio_console: free buffers after reset commit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b upstream. Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose” buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers until device unplug. Of course this means we might get an interrupt for a vq without an attached port now. Handle that by discarding the consumed buffer. Reported-by: Tiwei Bie Fixes: b3258ff1d6 ("virtio: Decrement avail idx on buffer detach") Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit a4fc9c518e70c6e1c9c897a99b028795235d83ca Author: Michael S. Tsirkin Date: Fri Apr 20 20:22:40 2018 +0300 virtio: add ability to iterate over vqs commit 24a7e4d20783c0514850f24a5c41ede46ab058f0 upstream. For cleanup it's helpful to be able to simply scan all vqs and discard all data. Add an iterator to do that. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 311a886f34311e575f7f911ebdbcbba9f05a498e Author: Takashi Iwai Date: Tue Apr 24 11:11:48 2018 +0200 ALSA: usb-audio: Skip broken EU on Dell dock USB-audio commit 1d8d6428d1da642ddd75b0be2d1bb1123ff8e017 upstream. The Dell Dock USB-audio device with 0bda:4014 is behaving notoriously bad, and we have already applied some workaround to avoid the firmware hiccup. Yet we still need to skip one thing, the Extension Unit at ID 4, which doesn't react correctly to the mixer ctl access. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1090658 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d2a2cc40f2413643bc0a15fe102365a3c466bb82 Author: Ravi Chandra Sadineni Date: Fri Apr 20 11:08:21 2018 -0700 USB: Increment wakeup count on remote wakeup. commit 83a62c51ba7b3c0bf45150c4eac7aefc6c785e94 upstream. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by: Ravi Chandra Sadineni Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman commit 46aba9fa5b7c79631b6a8e5dbb86d9db7882f9be Author: Kamil Lulko Date: Thu Apr 19 16:54:02 2018 -0700 usb: core: Add quirk for HP v222w 16GB Mini commit 3180dabe08e3653bf0a838553905d88f3773f29c upstream. Add DELAY_INIT quirk to fix the following problem with HP v222w 16GB Mini: usb 1-3: unable to read config index 0 descriptor/start: -110 usb 1-3: can't read configurations, error -110 usb 1-3: can't set config #1, error -110 Signed-off-by: Kamil Lulko Signed-off-by: Kuppuswamy Sathyanarayanan Cc: stable Signed-off-by: Greg Kroah-Hartman commit d6ccb61e3d86174bf182913bad26fe6e1ede3659 Author: Kyle Roeschley Date: Mon Apr 9 10:23:55 2018 -0500 USB: serial: cp210x: add ID for NI USB serial console commit 1e23aace21515a8f7615a1de016c0ea8d4e0cc6e upstream. Added the USB VID and PID for the USB serial console on some National Instruments devices. Signed-off-by: Kyle Roeschley Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8713dc52928d8b0df4ac21396ab794917b7b7d4b Author: Vasyl Vavrychuk Date: Wed Apr 11 17:05:13 2018 +0300 USB: serial: ftdi_sio: use jtag quirk for Arrow USB Blaster commit 470b5d6f0cf4674be2d1ec94e54283a1770b6a1a upstream. Arrow USB Blaster integrated on MAX1000 board uses the same vendor ID (0x0403) and product ID (0x6010) as the "original" FTDI device. This patch avoids picking up by ftdi_sio of the first interface of this USB device. After that this device can be used by Arrow user-space JTAG driver. Signed-off-by: Vasyl Vavrychuk Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0964d65e05ea80a6464629b20a16e49373f14a44 Author: Collin May Date: Sat Apr 7 14:32:48 2018 -0700 USB: serial: simple: add libtransistor console commit fe710508b6ba9d28730f3021fed70e7043433b2e upstream. Add simple driver for libtransistor USB console. This device is implemented in software: https://github.com/reswitched/libtransistor/blob/development/lib/usb_serial.c Signed-off-by: Collin May Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c4e4036903ac3c6cd9cba06cd0dffb9a9aa4b069 Author: Shuah Khan Date: Mon Apr 2 14:52:32 2018 -0600 usbip: vhci_hcd: Fix usb device and sockfd leaks commit 9020a7efe537856eb3e826ebebdf38a5d07a7857 upstream. vhci_hcd fails to do reset to put usb device and sockfd in the module remove/stop paths. Fix the leak. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman commit 50d26a47c13e6d7c96b6e250593ec2d1f4123258 Author: Shuah Khan Date: Thu Apr 5 16:29:04 2018 -0600 usbip: usbip_host: fix to hold parent lock for device_attach() calls commit 4bfb141bc01312a817d36627cc47c93f801c216d upstream. usbip_host calls device_attach() without holding dev->parent lock. Fix it. Signed-off-by: Shuah Khan Cc: stable Signed-off-by: Greg Kroah-Hartman commit 629433b4f9bad7da26a30e84e6eeb59e3ef41a16 Author: Lukas Czerner Date: Tue Apr 24 11:31:44 2018 -0400 ext4: fix bitmap position validation commit 22be37acce25d66ecf6403fc8f44df9c5ded2372 upstream. Currently in ext4_valid_block_bitmap() we expect the bitmap to be positioned anywhere between 0 and s_blocksize clusters, but that's wrong because the bitmap can be placed anywhere in the block group. This causes false positives when validating bitmaps on perfectly valid file system layouts. Fix it by checking whether the bitmap is within the group boundary. The problem can be reproduced using the following mkfs -t ext3 -E stride=256 /dev/vdb1 mount /dev/vdb1 /mnt/test cd /mnt/test wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.3.tar.xz tar xf linux-4.16.3.tar.xz This will result in the warnings in the logs EXT4-fs error (device vdb1): ext4_validate_block_bitmap:399: comm tar: bg 84: block 2774529: invalid block bitmap [ Changed slightly for clarity and to not drop a overflow test -- TYT ] Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reported-by: Ilya Dryomov Fixes: 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ea057aed06d8f13d931652bc4faa604ac0c50aa2 Author: Theodore Ts'o Date: Mon Mar 26 23:54:10 2018 -0400 ext4: add validity checks for bitmap block numbers commit 7dac4a1726a9c64a517d595c40e95e2d0d135f6f upstream. An privileged attacker can cause a crash by mounting a crafted ext4 image which triggers a out-of-bounds read in the function ext4_valid_block_bitmap() in fs/ext4/balloc.c. This issue has been assigned CVE-2018-1093. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199181 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1560782 Reported-by: Wen Xu Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 47757f587b676902a6b4a9f4023eb02b71fbf281 Author: Theodore Ts'o Date: Wed Apr 18 11:49:31 2018 -0400 ext4: set h_journal if there is a failure starting a reserved handle commit b2569260d55228b617bd82aba6d0db2faeeb4116 upstream. If ext4 tries to start a reserved handle via jbd2_journal_start_reserved(), and the journal has been aborted, this can result in a NULL pointer dereference. This is because the fields h_journal and h_transaction in the handle structure share the same memory, via a union, so jbd2_journal_start_reserved() will clear h_journal before calling start_this_handle(). If this function fails due to an aborted handle, h_journal will still be NULL, and the call to jbd2_journal_free_reserved() will pass a NULL journal to sub_reserve_credits(). This can be reproduced by running "kvm-xfstests -c dioread_nolock generic/475". Cc: stable@kernel.org # 3.11 Fixes: 8f7d89f36829b ("jbd2: transaction reservation support") Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Reviewed-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit de3a60fb7486516b9f2adce567bef10c894563af Author: Eric Biggers Date: Thu Apr 12 11:48:09 2018 -0400 ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS commit 349fa7d6e1935f49bf4161c4900711b2989180a9 upstream. During the "insert range" fallocate operation, extents starting at the range offset are shifted "right" (to a higher file offset) by the range length. But, as shown by syzbot, it's not validated that this doesn't cause extents to be shifted beyond EXT_MAX_BLOCKS. In that case ->ee_block can wrap around, corrupting the extent tree. Fix it by returning an error if the space between the end of the last extent and EXT4_MAX_BLOCKS is smaller than the range being inserted. This bug can be reproduced by running the following commands when the current directory is on an ext4 filesystem with a 4k block size: fallocate -l 8192 file fallocate --keep-size -o 0xfffffffe000 -l 4096 -n file fallocate --insert-range -l 8192 file Then after unmounting the filesystem, e2fsck reports corruption. Reported-by: syzbot+06c885be0edcdaeab40c@syzkaller.appspotmail.com Fixes: 331573febb6a ("ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman