From: Greg Kroah-Hartman Date: Thu, 19 Apr 2018 15:30:49 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.9.95~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c37c7831c16b2b235df046e0ff6f02af18cf8bbd;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.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 resource-fix-integer-overflow-at-reallocation.patch tty-make-n_tty_read-always-abort-if-hangup-is-in-progress.patch ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch ubi-fix-error-for-write-access.patch ubi-reject-mlc-nand.patch ubifs-check-ubifs_wbuf_sync-return-code.patch usb-gadget-udc-core-update-usb_ep_queue-documentation.patch usb-musb-gadget-misplaced-out-of-bounds-check.patch --- diff --git a/queue-4.9/fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch b/queue-4.9/fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch new file mode 100644 index 00000000000..b315650ec97 --- /dev/null +++ b/queue-4.9/fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch @@ -0,0 +1,52 @@ +From 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Tue, 10 Apr 2018 16:34:41 -0700 +Subject: fs/reiserfs/journal.c: add missing resierfs_warning() arg + +From: Andrew Morton + +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 +Reported-by: +Tested-by: Randy Dunlap +Acked-by: Jeff Mahoney +Cc: Alexander Viro +Cc: Jan Kara +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.9/ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch b/queue-4.9/ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch new file mode 100644 index 00000000000..db2cd6357ed --- /dev/null +++ b/queue-4.9/ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch @@ -0,0 +1,158 @@ +From 3f05317d9889ab75c7190dcd39491d2a97921984 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +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 + +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 + #include + #include + #include + + 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 +Acked-by: Kirill A. Shutemov +Acked-by: Davidlohr Bueso +Cc: Manfred Spraul +Cc: "Eric W . Biederman" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.9/mm-slab-reschedule-cache_reap-on-the-same-cpu.patch b/queue-4.9/mm-slab-reschedule-cache_reap-on-the-same-cpu.patch new file mode 100644 index 00000000000..dade95cdf68 --- /dev/null +++ b/queue-4.9/mm-slab-reschedule-cache_reap-on-the-same-cpu.patch @@ -0,0 +1,57 @@ +From a9f2a846f0503e7d729f552e3ccfe2279010fe94 Mon Sep 17 00:00:00 2001 +From: Vlastimil Babka +Date: Fri, 13 Apr 2018 15:35:38 -0700 +Subject: mm, slab: reschedule cache_reap() on the same CPU + +From: Vlastimil Babka + +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 +Acked-by: Pekka Enberg +Acked-by: Christoph Lameter +Cc: Joonsoo Kim +Cc: David Rientjes +Cc: Tejun Heo +Cc: Lai Jiangshan +Cc: John Stultz +Cc: Thomas Gleixner +Cc: Stephen Boyd +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.9/resource-fix-integer-overflow-at-reallocation.patch b/queue-4.9/resource-fix-integer-overflow-at-reallocation.patch new file mode 100644 index 00000000000..082e41745dc --- /dev/null +++ b/queue-4.9/resource-fix-integer-overflow-at-reallocation.patch @@ -0,0 +1,55 @@ +From 60bb83b81169820c691fbfa33a6a4aef32aa4b0b Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 13 Apr 2018 15:35:13 -0700 +Subject: resource: fix integer overflow at reallocation + +From: Takashi Iwai + +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 +Reported-by: Michael Henders +Tested-by: Michael Henders +Reviewed-by: Andrew Morton +Cc: Ram Pai +Cc: Bjorn Helgaas +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.9/series b/queue-4.9/series index 032264f5323..52cc688f4ba 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -66,3 +66,14 @@ vhost-fix-vhost_vq_access_ok-log-check.patch 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 diff --git a/queue-4.9/tty-make-n_tty_read-always-abort-if-hangup-is-in-progress.patch b/queue-4.9/tty-make-n_tty_read-always-abort-if-hangup-is-in-progress.patch new file mode 100644 index 00000000000..ac2b0b3643e --- /dev/null +++ b/queue-4.9/tty-make-n_tty_read-always-abort-if-hangup-is-in-progress.patch @@ -0,0 +1,236 @@ +From 28b0f8a6962a24ed21737578f3b1b07424635c9e Mon Sep 17 00:00:00 2001 +From: Tejun Heo +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 + +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 + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + + 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 +Cc: Alan Cox +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-4.9/ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch b/queue-4.9/ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch new file mode 100644 index 00000000000..c6277046789 --- /dev/null +++ b/queue-4.9/ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch @@ -0,0 +1,32 @@ +From 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Wed, 17 Jan 2018 23:15:57 +0100 +Subject: ubi: fastmap: Don't flush fastmap work on detach + +From: Richard Weinberger + +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 +Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system") +Cc: stable@vger.kernel.org +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.9/ubi-fix-error-for-write-access.patch b/queue-4.9/ubi-fix-error-for-write-access.patch new file mode 100644 index 00000000000..8f6c4a1e9c6 --- /dev/null +++ b/queue-4.9/ubi-fix-error-for-write-access.patch @@ -0,0 +1,42 @@ +From 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d Mon Sep 17 00:00:00 2001 +From: Romain Izard +Date: Mon, 29 Jan 2018 11:18:20 +0100 +Subject: ubi: Fix error for write access + +From: Romain Izard + +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 +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.9/ubi-reject-mlc-nand.patch b/queue-4.9/ubi-reject-mlc-nand.patch new file mode 100644 index 00000000000..9cf0ccf066e --- /dev/null +++ b/queue-4.9/ubi-reject-mlc-nand.patch @@ -0,0 +1,45 @@ +From b5094b7f135be34630e3ea8a98fa215715d0f29d Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Sat, 3 Mar 2018 11:45:54 +0100 +Subject: ubi: Reject MLC NAND + +From: Richard Weinberger + +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 +Acked-by: Boris Brezillon +Acked-by: Artem Bityutskiy +Signed-off-by: Greg Kroah-Hartman + +--- + 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++) diff --git a/queue-4.9/ubifs-check-ubifs_wbuf_sync-return-code.patch b/queue-4.9/ubifs-check-ubifs_wbuf_sync-return-code.patch new file mode 100644 index 00000000000..810b01eef3e --- /dev/null +++ b/queue-4.9/ubifs-check-ubifs_wbuf_sync-return-code.patch @@ -0,0 +1,54 @@ +From aac17948a7ce01fb60b9ee6cf902967a47b3ce26 Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Wed, 17 Jan 2018 19:12:42 +0100 +Subject: ubifs: Check ubifs_wbuf_sync() return code + +From: Richard Weinberger + +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: +Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.9/usb-gadget-udc-core-update-usb_ep_queue-documentation.patch b/queue-4.9/usb-gadget-udc-core-update-usb_ep_queue-documentation.patch new file mode 100644 index 00000000000..65d18968f72 --- /dev/null +++ b/queue-4.9/usb-gadget-udc-core-update-usb_ep_queue-documentation.patch @@ -0,0 +1,32 @@ +From eaa358c7790338d83bb6a31258bdc077de120414 Mon Sep 17 00:00:00 2001 +From: Felipe Balbi +Date: Mon, 26 Mar 2018 13:14:46 +0300 +Subject: usb: gadget: udc: core: update usb_ep_queue() documentation + +From: Felipe Balbi + +commit eaa358c7790338d83bb6a31258bdc077de120414 upstream. + +Mention that ->complete() should never be called from within +usb_ep_queue(). + +Signed-off-by: Felipe Balbi +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + 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. diff --git a/queue-4.9/usb-musb-gadget-misplaced-out-of-bounds-check.patch b/queue-4.9/usb-musb-gadget-misplaced-out-of-bounds-check.patch new file mode 100644 index 00000000000..f0c9448dafe --- /dev/null +++ b/queue-4.9/usb-musb-gadget-misplaced-out-of-bounds-check.patch @@ -0,0 +1,48 @@ +From af6f8529098aeb0e56a68671b450cf74e7a64fcd Mon Sep 17 00:00:00 2001 +From: Heinrich Schuchardt +Date: Thu, 29 Mar 2018 10:48:28 -0500 +Subject: usb: musb: gadget: misplaced out of bounds check + +From: Heinrich Schuchardt + +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 +Signed-off-by: Bin Liu +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + }