--- /dev/null
+From 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 Mon Sep 17 00:00:00 2001
+From: Andrew Morton <akpm@linux-foundation.org>
+Date: Tue, 10 Apr 2018 16:34:41 -0700
+Subject: fs/reiserfs/journal.c: add missing resierfs_warning() arg
+
+From: Andrew Morton <akpm@linux-foundation.org>
+
+commit 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 upstream.
+
+One use of the reiserfs_warning() macro in journal_init_dev() is missing
+a parameter, causing the following warning:
+
+ REISERFS warning (device loop0): journal_init_dev: Cannot open '%s': %i journal_init_dev:
+
+This also causes a WARN_ONCE() warning in the vsprintf code, and then a
+panic if panic_on_warn is set.
+
+ Please remove unsupported %/ in format string
+ WARNING: CPU: 1 PID: 4480 at lib/vsprintf.c:2138 format_decode+0x77f/0x830 lib/vsprintf.c:2138
+ Kernel panic - not syncing: panic_on_warn set ...
+
+Just add another string argument to the macro invocation.
+
+Addresses https://syzkaller.appspot.com/bug?id=0627d4551fdc39bf1ef5d82cd9eef587047f7718
+
+Link: http://lkml.kernel.org/r/d678ebe1-6f54-8090-df4c-b9affad62293@infradead.org
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reported-by: <syzbot+6bd77b88c1977c03f584@syzkaller.appspotmail.com>
+Tested-by: Randy Dunlap <rdunlap@infradead.org>
+Acked-by: Jeff Mahoney <jeffm@suse.com>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Jan Kara <jack@suse.com>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ fs/reiserfs/journal.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/reiserfs/journal.c
++++ b/fs/reiserfs/journal.c
+@@ -2640,7 +2640,7 @@ static int journal_init_dev(struct super
+ if (IS_ERR(journal->j_dev_bd)) {
+ result = PTR_ERR(journal->j_dev_bd);
+ journal->j_dev_bd = NULL;
+- reiserfs_warning(super,
++ reiserfs_warning(super, "sh-457",
+ "journal_init_dev: Cannot open '%s': %i",
+ jdev_name, result);
+ return result;
--- /dev/null
+From 3f05317d9889ab75c7190dcd39491d2a97921984 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 13 Apr 2018 15:35:30 -0700
+Subject: ipc/shm: fix use-after-free of shm file via remap_file_pages()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 3f05317d9889ab75c7190dcd39491d2a97921984 upstream.
+
+syzbot reported a use-after-free of shm_file_data(file)->file->f_op in
+shm_get_unmapped_area(), called via sys_remap_file_pages().
+
+Unfortunately it couldn't generate a reproducer, but I found a bug which
+I think caused it. When remap_file_pages() is passed a full System V
+shared memory segment, the memory is first unmapped, then a new map is
+created using the ->vm_file. Between these steps, the shm ID can be
+removed and reused for a new shm segment. But, shm_mmap() only checks
+whether the ID is currently valid before calling the underlying file's
+->mmap(); it doesn't check whether it was reused. Thus it can use the
+wrong underlying file, one that was already freed.
+
+Fix this by making the "outer" shm file (the one that gets put in
+->vm_file) hold a reference to the real shm file, and by making
+__shm_open() require that the file associated with the shm ID matches
+the one associated with the "outer" file.
+
+Taking the reference to the real shm file is needed to fully solve the
+problem, since otherwise sfd->file could point to a freed file, which
+then could be reallocated for the reused shm ID, causing the wrong shm
+segment to be mapped (and without the required permission checks).
+
+Commit 1ac0b6dec656 ("ipc/shm: handle removed segments gracefully in
+shm_mmap()") almost fixed this bug, but it didn't go far enough because
+it didn't consider the case where the shm ID is reused.
+
+The following program usually reproduces this bug:
+
+ #include <stdlib.h>
+ #include <sys/shm.h>
+ #include <sys/syscall.h>
+ #include <unistd.h>
+
+ int main()
+ {
+ int is_parent = (fork() != 0);
+ srand(getpid());
+ for (;;) {
+ int id = shmget(0xF00F, 4096, IPC_CREAT|0700);
+ if (is_parent) {
+ void *addr = shmat(id, NULL, 0);
+ usleep(rand() % 50);
+ while (!syscall(__NR_remap_file_pages, addr, 4096, 0, 0, 0));
+ } else {
+ usleep(rand() % 50);
+ shmctl(id, IPC_RMID, NULL);
+ }
+ }
+ }
+
+It causes the following NULL pointer dereference due to a 'struct file'
+being used while it's being freed. (I couldn't actually get a KASAN
+use-after-free splat like in the syzbot report. But I think it's
+possible with this bug; it would just take a more extraordinary race...)
+
+ BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
+ PGD 0 P4D 0
+ Oops: 0000 [#1] SMP NOPTI
+ CPU: 9 PID: 258 Comm: syz_ipc Not tainted 4.16.0-05140-gf8cf2f16a7c95 #189
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
+ RIP: 0010:d_inode include/linux/dcache.h:519 [inline]
+ RIP: 0010:touch_atime+0x25/0xd0 fs/inode.c:1724
+ [...]
+ Call Trace:
+ file_accessed include/linux/fs.h:2063 [inline]
+ shmem_mmap+0x25/0x40 mm/shmem.c:2149
+ call_mmap include/linux/fs.h:1789 [inline]
+ shm_mmap+0x34/0x80 ipc/shm.c:465
+ call_mmap include/linux/fs.h:1789 [inline]
+ mmap_region+0x309/0x5b0 mm/mmap.c:1712
+ do_mmap+0x294/0x4a0 mm/mmap.c:1483
+ do_mmap_pgoff include/linux/mm.h:2235 [inline]
+ SYSC_remap_file_pages mm/mmap.c:2853 [inline]
+ SyS_remap_file_pages+0x232/0x310 mm/mmap.c:2769
+ do_syscall_64+0x64/0x1a0 arch/x86/entry/common.c:287
+ entry_SYSCALL_64_after_hwframe+0x42/0xb7
+
+[ebiggers@google.com: add comment]
+ Link: http://lkml.kernel.org/r/20180410192850.235835-1-ebiggers3@gmail.com
+Link: http://lkml.kernel.org/r/20180409043039.28915-1-ebiggers3@gmail.com
+Reported-by: syzbot+d11f321e7f1923157eac80aa990b446596f46439@syzkaller.appspotmail.com
+Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Acked-by: Davidlohr Bueso <dbueso@suse.de>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: "Eric W . Biederman" <ebiederm@xmission.com>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ ipc/shm.c | 23 ++++++++++++++++++++---
+ 1 file changed, 20 insertions(+), 3 deletions(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -198,6 +198,12 @@ static int __shm_open(struct vm_area_str
+ if (IS_ERR(shp))
+ return PTR_ERR(shp);
+
++ if (shp->shm_file != sfd->file) {
++ /* ID was reused */
++ shm_unlock(shp);
++ return -EINVAL;
++ }
++
+ shp->shm_atim = get_seconds();
+ shp->shm_lprid = task_tgid_vnr(current);
+ shp->shm_nattch++;
+@@ -425,8 +431,9 @@ static int shm_mmap(struct file *file, s
+ int ret;
+
+ /*
+- * In case of remap_file_pages() emulation, the file can represent
+- * removed IPC ID: propogate shm_lock() error to caller.
++ * In case of remap_file_pages() emulation, the file can represent an
++ * IPC ID that was removed, and possibly even reused by another shm
++ * segment already. Propagate this case as an error to caller.
+ */
+ ret =__shm_open(vma);
+ if (ret)
+@@ -450,6 +457,7 @@ static int shm_release(struct inode *ino
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ put_ipc_ns(sfd->ns);
++ fput(sfd->file);
+ shm_file_data(file) = NULL;
+ kfree(sfd);
+ return 0;
+@@ -1212,7 +1220,16 @@ long do_shmat(int shmid, char __user *sh
+ file->f_mapping = shp->shm_file->f_mapping;
+ sfd->id = shp->shm_perm.id;
+ sfd->ns = get_ipc_ns(ns);
+- sfd->file = shp->shm_file;
++ /*
++ * We need to take a reference to the real shm file to prevent the
++ * pointer from becoming stale in cases where the lifetime of the outer
++ * file extends beyond that of the shm segment. It's not usually
++ * possible, but it can happen during remap_file_pages() emulation as
++ * that unmaps the memory, then does ->mmap() via file reference only.
++ * We'll deny the ->mmap() if the shm segment was since removed, but to
++ * detect shm ID reuse we need to compare the file pointers.
++ */
++ sfd->file = get_file(shp->shm_file);
+ sfd->vm_ops = NULL;
+
+ err = security_mmap_file(file, prot, flags);
--- /dev/null
+From a9f2a846f0503e7d729f552e3ccfe2279010fe94 Mon Sep 17 00:00:00 2001
+From: Vlastimil Babka <vbabka@suse.cz>
+Date: Fri, 13 Apr 2018 15:35:38 -0700
+Subject: mm, slab: reschedule cache_reap() on the same CPU
+
+From: Vlastimil Babka <vbabka@suse.cz>
+
+commit a9f2a846f0503e7d729f552e3ccfe2279010fe94 upstream.
+
+cache_reap() is initially scheduled in start_cpu_timer() via
+schedule_delayed_work_on(). But then the next iterations are scheduled
+via schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND.
+
+Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND
+work on wq_unbound_cpumask CPUs") there is no guarantee the future
+iterations will run on the originally intended cpu, although it's still
+preferred. I was able to demonstrate this with
+/sys/module/workqueue/parameters/debug_force_rr_cpu. IIUC, it may also
+happen due to migrating timers in nohz context. As a result, some cpu's
+would be calling cache_reap() more frequently and others never.
+
+This patch uses schedule_delayed_work_on() with the current cpu when
+scheduling the next iteration.
+
+Link: http://lkml.kernel.org/r/20180411070007.32225-1-vbabka@suse.cz
+Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs")
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Acked-by: Pekka Enberg <penberg@kernel.org>
+Acked-by: Christoph Lameter <cl@linux.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Lai Jiangshan <jiangshanlai@gmail.com>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Stephen Boyd <sboyd@kernel.org>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ mm/slab.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/slab.c
++++ b/mm/slab.c
+@@ -4096,7 +4096,8 @@ next:
+ next_reap_node();
+ out:
+ /* Set up the next iteration */
+- schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
++ schedule_delayed_work_on(smp_processor_id(), work,
++ round_jiffies_relative(REAPTIMEOUT_AC));
+ }
+
+ #ifdef CONFIG_SLABINFO
--- /dev/null
+From 60bb83b81169820c691fbfa33a6a4aef32aa4b0b Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 13 Apr 2018 15:35:13 -0700
+Subject: resource: fix integer overflow at reallocation
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 60bb83b81169820c691fbfa33a6a4aef32aa4b0b upstream.
+
+We've got a bug report indicating a kernel panic at booting on an x86-32
+system, and it turned out to be the invalid PCI resource assigned after
+reallocation. __find_resource() first aligns the resource start address
+and resets the end address with start+size-1 accordingly, then checks
+whether it's contained. Here the end address may overflow the integer,
+although resource_contains() still returns true because the function
+validates only start and end address. So this ends up with returning an
+invalid resource (start > end).
+
+There was already an attempt to cover such a problem in the commit
+47ea91b4052d ("Resource: fix wrong resource window calculation"), but
+this case is an overseen one.
+
+This patch adds the validity check of the newly calculated resource for
+avoiding the integer overflow problem.
+
+Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739
+Link: http://lkml.kernel.org/r/s5hpo37d5l8.wl-tiwai@suse.de
+Fixes: 23c570a67448 ("resource: ability to resize an allocated resource")
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Reported-by: Michael Henders <hendersm@shaw.ca>
+Tested-by: Michael Henders <hendersm@shaw.ca>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Ram Pai <linuxram@us.ibm.com>
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: <stable@vger.kernel.org>
+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>
+
+---
+ kernel/resource.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/resource.c
++++ b/kernel/resource.c
+@@ -633,7 +633,8 @@ static int __find_resource(struct resour
+ alloc.start = constraint->alignf(constraint->alignf_data, &avail,
+ size, constraint->align);
+ alloc.end = alloc.start + size - 1;
+- if (resource_contains(&avail, &alloc)) {
++ if (alloc.start <= alloc.end &&
++ resource_contains(&avail, &alloc)) {
+ new->start = alloc.start;
+ new->end = alloc.end;
+ return 0;
lan78xx-correctly-indicate-invalid-otp.patch
arm64-futex-mask-__user-pointers-prior-to-dereference.patch
revert-net-phy-micrel-restore-led_mode-and-clk_sel-on.patch
+tty-make-n_tty_read-always-abort-if-hangup-is-in-progress.patch
+ubifs-check-ubifs_wbuf_sync-return-code.patch
+ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch
+ubi-fix-error-for-write-access.patch
+ubi-reject-mlc-nand.patch
+fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch
+resource-fix-integer-overflow-at-reallocation.patch
+ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch
+mm-slab-reschedule-cache_reap-on-the-same-cpu.patch
+usb-musb-gadget-misplaced-out-of-bounds-check.patch
+usb-gadget-udc-core-update-usb_ep_queue-documentation.patch
--- /dev/null
+From 28b0f8a6962a24ed21737578f3b1b07424635c9e Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 13 Feb 2018 07:38:08 -0800
+Subject: tty: make n_tty_read() always abort if hangup is in progress
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 28b0f8a6962a24ed21737578f3b1b07424635c9e upstream.
+
+A tty is hung up by __tty_hangup() setting file->f_op to
+hung_up_tty_fops, which is skipped on ttys whose write operation isn't
+tty_write(). This means that, for example, /dev/console whose write
+op is redirected_tty_write() is never actually marked hung up.
+
+Because n_tty_read() uses the hung up status to decide whether to
+abort the waiting readers, the lack of hung-up marking can lead to the
+following scenario.
+
+ 1. A session contains two processes. The leader and its child. The
+ child ignores SIGHUP.
+
+ 2. The leader exits and starts disassociating from the controlling
+ terminal (/dev/console).
+
+ 3. __tty_hangup() skips setting f_op to hung_up_tty_fops.
+
+ 4. SIGHUP is delivered and ignored.
+
+ 5. tty_ldisc_hangup() is invoked. It wakes up the waits which should
+ clear the read lockers of tty->ldisc_sem.
+
+ 6. The reader wakes up but because tty_hung_up_p() is false, it
+ doesn't abort and goes back to sleep while read-holding
+ tty->ldisc_sem.
+
+ 7. The leader progresses to tty_ldisc_lock() in tty_ldisc_hangup()
+ and is now stuck in D sleep indefinitely waiting for
+ tty->ldisc_sem.
+
+The following is Alan's explanation on why some ttys aren't hung up.
+
+ http://lkml.kernel.org/r/20171101170908.6ad08580@alans-desktop
+
+ 1. It broke the serial consoles because they would hang up and close
+ down the hardware. With tty_port that *should* be fixable properly
+ for any cases remaining.
+
+ 2. The console layer was (and still is) completely broken and doens't
+ refcount properly. So if you turn on console hangups it breaks (as
+ indeed does freeing consoles and half a dozen other things).
+
+As neither can be fixed quickly, this patch works around the problem
+by introducing a new flag, TTY_HUPPING, which is used solely to tell
+n_tty_read() that hang-up is in progress for the console and the
+readers should be aborted regardless of the hung-up status of the
+device.
+
+The following is a sample hung task warning caused by this issue.
+
+ INFO: task agetty:2662 blocked for more than 120 seconds.
+ Not tainted 4.11.3-dbg-tty-lockup-02478-gfd6c7ee-dirty #28
+ "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+ 0 2662 1 0x00000086
+ Call Trace:
+ __schedule+0x267/0x890
+ schedule+0x36/0x80
+ schedule_timeout+0x23c/0x2e0
+ ldsem_down_write+0xce/0x1f6
+ tty_ldisc_lock+0x16/0x30
+ tty_ldisc_hangup+0xb3/0x1b0
+ __tty_hangup+0x300/0x410
+ disassociate_ctty+0x6c/0x290
+ do_exit+0x7ef/0xb00
+ do_group_exit+0x3f/0xa0
+ get_signal+0x1b3/0x5d0
+ do_signal+0x28/0x660
+ exit_to_usermode_loop+0x46/0x86
+ do_syscall_64+0x9c/0xb0
+ entry_SYSCALL64_slow_path+0x25/0x25
+
+The following is the repro. Run "$PROG /dev/console". The parent
+process hangs in D state.
+
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <sys/wait.h>
+ #include <sys/ioctl.h>
+ #include <fcntl.h>
+ #include <unistd.h>
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <errno.h>
+ #include <signal.h>
+ #include <time.h>
+ #include <termios.h>
+
+ int main(int argc, char **argv)
+ {
+ struct sigaction sact = { .sa_handler = SIG_IGN };
+ struct timespec ts1s = { .tv_sec = 1 };
+ pid_t pid;
+ int fd;
+
+ if (argc < 2) {
+ fprintf(stderr, "test-hung-tty /dev/$TTY\n");
+ return 1;
+ }
+
+ /* fork a child to ensure that it isn't already the session leader */
+ pid = fork();
+ if (pid < 0) {
+ perror("fork");
+ return 1;
+ }
+
+ if (pid > 0) {
+ /* top parent, wait for everyone */
+ while (waitpid(-1, NULL, 0) >= 0)
+ ;
+ if (errno != ECHILD)
+ perror("waitpid");
+ return 0;
+ }
+
+ /* new session, start a new session and set the controlling tty */
+ if (setsid() < 0) {
+ perror("setsid");
+ return 1;
+ }
+
+ fd = open(argv[1], O_RDWR);
+ if (fd < 0) {
+ perror("open");
+ return 1;
+ }
+
+ if (ioctl(fd, TIOCSCTTY, 1) < 0) {
+ perror("ioctl");
+ return 1;
+ }
+
+ /* fork a child, sleep a bit and exit */
+ pid = fork();
+ if (pid < 0) {
+ perror("fork");
+ return 1;
+ }
+
+ if (pid > 0) {
+ nanosleep(&ts1s, NULL);
+ printf("Session leader exiting\n");
+ exit(0);
+ }
+
+ /*
+ * The child ignores SIGHUP and keeps reading from the controlling
+ * tty. Because SIGHUP is ignored, the child doesn't get killed on
+ * parent exit and the bug in n_tty makes the read(2) block the
+ * parent's control terminal hangup attempt. The parent ends up in
+ * D sleep until the child is explicitly killed.
+ */
+ sigaction(SIGHUP, &sact, NULL);
+ printf("Child reading tty\n");
+ while (1) {
+ char buf[1024];
+
+ if (read(fd, buf, sizeof(buf)) < 0) {
+ perror("read");
+ return 1;
+ }
+ }
+
+ return 0;
+ }
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: Alan Cox <alan@llwyncelyn.cymru>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/n_tty.c | 6 ++++++
+ drivers/tty/tty_io.c | 9 +++++++++
+ include/linux/tty.h | 1 +
+ 3 files changed, 16 insertions(+)
+
+--- a/drivers/tty/n_tty.c
++++ b/drivers/tty/n_tty.c
+@@ -2182,6 +2182,12 @@ static ssize_t n_tty_read(struct tty_str
+ }
+ if (tty_hung_up_p(file))
+ break;
++ /*
++ * Abort readers for ttys which never actually
++ * get hung up. See __tty_hangup().
++ */
++ if (test_bit(TTY_HUPPING, &tty->flags))
++ break;
+ if (!timeout)
+ break;
+ if (file->f_flags & O_NONBLOCK) {
+--- a/drivers/tty/tty_io.c
++++ b/drivers/tty/tty_io.c
+@@ -709,6 +709,14 @@ static void __tty_hangup(struct tty_stru
+ return;
+ }
+
++ /*
++ * Some console devices aren't actually hung up for technical and
++ * historical reasons, which can lead to indefinite interruptible
++ * sleep in n_tty_read(). The following explicitly tells
++ * n_tty_read() to abort readers.
++ */
++ set_bit(TTY_HUPPING, &tty->flags);
++
+ /* inuse_filps is protected by the single tty lock,
+ this really needs to change if we want to flush the
+ workqueue with the lock held */
+@@ -763,6 +771,7 @@ static void __tty_hangup(struct tty_stru
+ * from the ldisc side, which is now guaranteed.
+ */
+ set_bit(TTY_HUPPED, &tty->flags);
++ clear_bit(TTY_HUPPING, &tty->flags);
+ tty_unlock(tty);
+
+ if (f)
+--- a/include/linux/tty.h
++++ b/include/linux/tty.h
+@@ -355,6 +355,7 @@ struct tty_file_private {
+ #define TTY_PTY_LOCK 16 /* pty private */
+ #define TTY_NO_WRITE_SPLIT 17 /* Preserve write boundaries to driver */
+ #define TTY_HUPPED 18 /* Post driver->hangup() */
++#define TTY_HUPPING 19 /* Hangup in progress */
+ #define TTY_LDISC_HALTED 22 /* Line discipline is halted */
+
+ /* Values for tty->flow_change */
--- /dev/null
+From 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Wed, 17 Jan 2018 23:15:57 +0100
+Subject: ubi: fastmap: Don't flush fastmap work on detach
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 upstream.
+
+At this point UBI volumes have already been free()'ed and fastmap can no
+longer access these data structures.
+
+Reported-by: Martin Townsend <mtownsend1973@gmail.com>
+Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
+Cc: stable@vger.kernel.org
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/fastmap-wl.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/mtd/ubi/fastmap-wl.c
++++ b/drivers/mtd/ubi/fastmap-wl.c
+@@ -362,7 +362,6 @@ static void ubi_fastmap_close(struct ubi
+ {
+ int i;
+
+- flush_work(&ubi->fm_work);
+ return_unused_pool_pebs(ubi, &ubi->fm_pool);
+ return_unused_pool_pebs(ubi, &ubi->fm_wl_pool);
+
--- /dev/null
+From 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d Mon Sep 17 00:00:00 2001
+From: Romain Izard <romain.izard.pro@gmail.com>
+Date: Mon, 29 Jan 2018 11:18:20 +0100
+Subject: ubi: Fix error for write access
+
+From: Romain Izard <romain.izard.pro@gmail.com>
+
+commit 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d upstream.
+
+When opening a device with write access, ubiblock_open returns an error
+code. Currently, this error code is -EPERM, but this is not the right
+value.
+
+The open function for other block devices returns -EROFS when opening
+read-only devices with FMODE_WRITE set. When used with dm-verity, the
+veritysetup userspace tool is expecting EROFS, and refuses to use the
+ubiblock device.
+
+Use -EROFS for ubiblock as well. As a result, veritysetup accepts the
+ubiblock device as valid.
+
+Cc: stable@vger.kernel.org
+Fixes: 9d54c8a33eec (UBI: R/O block driver on top of UBI volumes)
+Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/block.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/ubi/block.c
++++ b/drivers/mtd/ubi/block.c
+@@ -244,7 +244,7 @@ static int ubiblock_open(struct block_de
+ * in any case.
+ */
+ if (mode & FMODE_WRITE) {
+- ret = -EPERM;
++ ret = -EROFS;
+ goto out_unlock;
+ }
+
--- /dev/null
+From b5094b7f135be34630e3ea8a98fa215715d0f29d Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Sat, 3 Mar 2018 11:45:54 +0100
+Subject: ubi: Reject MLC NAND
+
+From: Richard Weinberger <richard@nod.at>
+
+commit b5094b7f135be34630e3ea8a98fa215715d0f29d upstream.
+
+While UBI and UBIFS seem to work at first sight with MLC NAND, you will
+most likely lose all your data upon a power-cut or due to read/write
+disturb.
+In order to protect users from bad surprises, refuse to attach to MLC
+NAND.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/build.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/mtd/ubi/build.c
++++ b/drivers/mtd/ubi/build.c
+@@ -894,6 +894,17 @@ int ubi_attach_mtd_dev(struct mtd_info *
+ return -EINVAL;
+ }
+
++ /*
++ * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes.
++ * MLC NAND is different and needs special care, otherwise UBI or UBIFS
++ * will die soon and you will lose all your data.
++ */
++ if (mtd->type == MTD_MLCNANDFLASH) {
++ pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
++ mtd->index);
++ return -EINVAL;
++ }
++
+ if (ubi_num == UBI_DEV_NUM_AUTO) {
+ /* Search for an empty slot in the @ubi_devices array */
+ for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
--- /dev/null
+From aac17948a7ce01fb60b9ee6cf902967a47b3ce26 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Wed, 17 Jan 2018 19:12:42 +0100
+Subject: ubifs: Check ubifs_wbuf_sync() return code
+
+From: Richard Weinberger <richard@nod.at>
+
+commit aac17948a7ce01fb60b9ee6cf902967a47b3ce26 upstream.
+
+If ubifs_wbuf_sync() fails we must not write a master node with the
+dirty marker cleared.
+Otherwise it is possible that in case of an IO error while syncing we
+mark the filesystem as clean and UBIFS refuses to recover upon next
+mount.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ubifs/super.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/fs/ubifs/super.c
++++ b/fs/ubifs/super.c
+@@ -1728,8 +1728,11 @@ static void ubifs_remount_ro(struct ubif
+
+ dbg_save_space_info(c);
+
+- for (i = 0; i < c->jhead_cnt; i++)
+- ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ for (i = 0; i < c->jhead_cnt; i++) {
++ err = ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ if (err)
++ ubifs_ro_mode(c, err);
++ }
+
+ c->mst_node->flags &= ~cpu_to_le32(UBIFS_MST_DIRTY);
+ c->mst_node->flags |= cpu_to_le32(UBIFS_MST_NO_ORPHS);
+@@ -1795,8 +1798,11 @@ static void ubifs_put_super(struct super
+ int err;
+
+ /* Synchronize write-buffers */
+- for (i = 0; i < c->jhead_cnt; i++)
+- ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ for (i = 0; i < c->jhead_cnt; i++) {
++ err = ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ if (err)
++ ubifs_ro_mode(c, err);
++ }
+
+ /*
+ * We are being cleanly unmounted which means the
--- /dev/null
+From eaa358c7790338d83bb6a31258bdc077de120414 Mon Sep 17 00:00:00 2001
+From: Felipe Balbi <felipe.balbi@linux.intel.com>
+Date: Mon, 26 Mar 2018 13:14:46 +0300
+Subject: usb: gadget: udc: core: update usb_ep_queue() documentation
+
+From: Felipe Balbi <felipe.balbi@linux.intel.com>
+
+commit eaa358c7790338d83bb6a31258bdc077de120414 upstream.
+
+Mention that ->complete() should never be called from within
+usb_ep_queue().
+
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/gadget/udc/core.c
++++ b/drivers/usb/gadget/udc/core.c
+@@ -248,6 +248,9 @@ EXPORT_SYMBOL_GPL(usb_ep_free_request);
+ * arranges to poll once per interval, and the gadget driver usually will
+ * have queued some data to transfer at that time.
+ *
++ * Note that @req's ->complete() callback must never be called from
++ * within usb_ep_queue() as that can create deadlock situations.
++ *
+ * Returns zero, or a negative error code. Endpoints that are not enabled
+ * report errors; errors will also be
+ * reported when the usb peripheral is disconnected.
--- /dev/null
+From af6f8529098aeb0e56a68671b450cf74e7a64fcd Mon Sep 17 00:00:00 2001
+From: Heinrich Schuchardt <xypron.glpk@gmx.de>
+Date: Thu, 29 Mar 2018 10:48:28 -0500
+Subject: usb: musb: gadget: misplaced out of bounds check
+
+From: Heinrich Schuchardt <xypron.glpk@gmx.de>
+
+commit af6f8529098aeb0e56a68671b450cf74e7a64fcd upstream.
+
+musb->endpoints[] has array size MUSB_C_NUM_EPS.
+We must check array bounds before accessing the array and not afterwards.
+
+Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
+Signed-off-by: Bin Liu <b-liu@ti.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/musb/musb_gadget_ep0.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/musb/musb_gadget_ep0.c
++++ b/drivers/usb/musb/musb_gadget_ep0.c
+@@ -114,15 +114,19 @@ static int service_tx_status_request(
+ }
+
+ is_in = epnum & USB_DIR_IN;
+- if (is_in) {
+- epnum &= 0x0f;
++ epnum &= 0x0f;
++ if (epnum >= MUSB_C_NUM_EPS) {
++ handled = -EINVAL;
++ break;
++ }
++
++ if (is_in)
+ ep = &musb->endpoints[epnum].ep_in;
+- } else {
++ else
+ ep = &musb->endpoints[epnum].ep_out;
+- }
+ regs = musb->endpoints[epnum].regs;
+
+- if (epnum >= MUSB_C_NUM_EPS || !ep->desc) {
++ if (!ep->desc) {
+ handled = -EINVAL;
+ break;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
