Permalink
Commits on Nov 26, 2016
  1. msm: HTC: Regenerate s4/m7/t6 defconfigs for f2fs changes

    mdmower committed Nov 26, 2016
    Change-Id: Ia8419f0a006060dd00c7a5cb44aa0cd2945fd27c
  2. msm: HTC: fighter: Update board files

    mdmower committed Jul 3, 2016
    * Update from the fighter board files found in kernel:
      m7gpe-gd08e956-6.04.1700.16-Android5.1
    
    A few notes from the update:
    
    * GPIO names:
      - Cleanup whitespace and rename GPIOs to include GPIO_ or PMGPIO_
        for consistency.
    * Audio board file:
      - Use fighter-specific audio board file instead of copying ville
      - Remove headset calibration specific to ville
      - Replace top spk amp with hac amp (and new controls)
      - USB audio omitted since OTG is not supported on this device
    * Storage board file:
      - Reference board-8960-storage.c for standard
        CONFIG_MMC_MSM_SDC3_POLLING flag instead of HTC-specific flag
    * Regulator board file
      - Min/max voltages have largely been referenced from board-8960.c,
        rather than the fighter board file. Some ranges have been expanded
        to accommodate voltages requested by fighter components.
    * Use default msm8960 rtb and cache_dump pdata
    * Add cyttsp touchscreen support
    * Remove perf lock configs
    * Update headset config
      - Use for-loops over arrays
      - ifdef ONE_WIRE code
    * Add/Update Synaptics 3200 touchscreen pdata
    
    Change-Id: I54fc1957a4de7dd9d8cc43e6e8a04af02f502add
  3. msm: HTC: Remove unused voltage storage from reboot handler

    mdmower committed May 30, 2016
    Nothing reads these values anymore.
    
    Change-Id: I618a8ea88c629e5f9b776eb934ebc92f1e2d31fc
Commits on Nov 19, 2016
  1. f2fs: Squashed update from f2fs-stable

    mdmower committed Aug 19, 2016
    https://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git
    Branch: linux-3.4.y
    Up to and including:
      fscrypto: no support for v3.4
      2220ac23c3c583321276c85cbfd7f6378abd8f94
    
    Change-Id: I417b0479dcd9e9c257beb45852b70bca3630c61e
  2. f2fs: Squashed update from f2fs-stable

    mdmower committed Jun 3, 2016
    https://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git
    Branch: linux-3.4.y
    Up to and including:
      f2fs: adjust other changes
      2ba43a590c3fd78b3d05edd49aab3d2c34ae7232
    
    Change-Id: If67141f1a9d23e42bd972ad9aaef6e6aa3ac28b8
  3. f2fs: fix to update dirty page count correctly

    chaseyu authored and mdmower committed May 20, 2016
    Once we failed to merge inline data into inode page during flushing inline
    inode, we will skip invoking inode_dec_dirty_pages, which makes dirty page
    count incorrect, result in panic in ->evict_inode, Fix it.
    
    ------------[ cut here ]------------
    kernel BUG at /home/yuchao/git/devf2fs/inode.c:336!
    invalid opcode: 0000 [#1] PREEMPT SMP
    CPU: 3 PID: 10004 Comm: umount Tainted: G           O    4.6.0-rc5+ #17
    Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
    task: f0c33000 ti: c5212000 task.ti: c5212000
    EIP: 0060:[<f89aacb5>] EFLAGS: 00010202 CPU: 3
    EIP is at f2fs_evict_inode+0x85/0x490 [f2fs]
    EAX: 00000001 EBX: c4529ea0 ECX: 00000001 EDX: 00000000
    ESI: c0131000 EDI: f89dd0a0 EBP: c5213e9c ESP: c5213e78
     DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    CR0: 80050033 CR2: b75878c0 CR3: 1a36a700 CR4: 000406f0
    Stack:
     c4529ea0 c4529ef4 c5213e8c c176d45c c4529ef4 00000000 c4529ea0 c4529fac
     f89dd0a0 c5213eb0 c1204a68 c5213ed8 c452a2b4 c6680930 c5213ec0 c1204b64
     c6680d44 c6680620 c5213eec c120588d ee84b000 ee84b5c0 c5214000 ee84b5e0
    Call Trace:
     [<c176d45c>] ? _raw_spin_unlock+0x2c/0x50
     [<c1204a68>] evict+0xa8/0x170
     [<c1204b64>] dispose_list+0x34/0x50
     [<c120588d>] evict_inodes+0x10d/0x130
     [<c11ea941>] generic_shutdown_super+0x41/0xe0
     [<c1185190>] ? unregister_shrinker+0x40/0x50
     [<c1185190>] ? unregister_shrinker+0x40/0x50
     [<c11eac52>] kill_block_super+0x22/0x70
     [<f89af23e>] kill_f2fs_super+0x1e/0x20 [f2fs]
     [<c11eae1d>] deactivate_locked_super+0x3d/0x70
     [<c11eb383>] deactivate_super+0x43/0x60
     [<c1208ec9>] cleanup_mnt+0x39/0x80
     [<c1208f50>] __cleanup_mnt+0x10/0x20
     [<c107d091>] task_work_run+0x71/0x90
     [<c105725a>] exit_to_usermode_loop+0x72/0x9e
     [<c1001c7c>] do_fast_syscall_32+0x19c/0x1c0
     [<c176dd48>] sysenter_past_esp+0x45/0x74
    EIP: [<f89aacb5>] f2fs_evict_inode+0x85/0x490 [f2fs] SS:ESP 0068:c5213e78
    ---[ end trace d30536330b7fdc58 ]---
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    
    Change-Id: Iad209ae94828e8e38955459d1ea9573c9e11ede6
  4. f2fs: Squashed update of f2fs-stable

    mdmower committed May 23, 2016
    https://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-stable.git
    Branch: linux-3.4.y
    Up to and including:
      Revert "f2fs: use cryptoapi crc32 functions"
      5b2523fc731f68cb48ca3d82f3ef2952a61ae5ba
    
    Change-Id: I062d186a7525d6a2ac431f811e5ca550c41ecf0f
Commits on Nov 13, 2016
  1. ion: disable system contig heap

    Liam Mark authored and mdmower committed Oct 12, 2016
    A malicious application can take advantage of the ION contig heap to
    create a specific memory chunk size to exercise a rowhammer attack on the
    physical hardware.
    So remove support for the ION contig heap.
    
    Change-Id: I9cb454cebb74df291479cecc3533d2c684363f77
    Signed-off-by: Liam Mark <lmark@codeaurora.org>
    Signed-off-by: Prakash Gupta <guptap@codeaurora.org>
  2. HID: core: prevent out-of-bound readings

    Benjamin Tissoires authored and mdmower committed Jan 19, 2016
    Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
    out-of-bound readings.
    
    The fields are allocated up to MAX_USAGE, meaning that potentially, we do
    not have enough fields to fit the incoming values.
    Add checks and silence KASAN.
    
    Change-Id: I11d44957b450a3eda258c05f9e833c71a079e83c
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
  3. BACKPORT: tty: Prevent ldisc drivers from re-using stale tty fields

    peterhurley authored and mdmower committed Nov 27, 2015
    (cherry picked from commit dd42bf1197144ede075a9d4793123f7689e164bc)
    
    Line discipline drivers may mistakenly misuse ldisc-related fields
    when initializing. For example, a failure to initialize tty->receive_room
    in the N_GIGASET_M101 line discipline was recently found and fixed [1].
    Now, the N_X25 line discipline has been discovered accessing the previous
    line discipline's already-freed private data [2].
    
    Harden the ldisc interface against misuse by initializing revelant
    tty fields before instancing the new line discipline.
    
    [1]
        commit fd98e9419d8d622a4de91f76b306af6aa627aa9c
        Author: Tilman Schmidt <tilman@imap.cc>
        Date:   Tue Jul 14 00:37:13 2015 +0200
    
        isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
    
    [2] Report from Sasha Levin <sasha.levin@oracle.com>
        [  634.336761] ==================================================================
        [  634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
        [  634.339558] Read of size 4 by task syzkaller_execu/8981
        [  634.340359] =============================================================================
        [  634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
        ...
        [  634.405018] Call Trace:
        [  634.405277] dump_stack (lib/dump_stack.c:52)
        [  634.405775] print_trailer (mm/slub.c:655)
        [  634.406361] object_err (mm/slub.c:662)
        [  634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
        [  634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
        [  634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
        [  634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
        [  634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
        [  634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
        [  634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
        [  634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
        [  634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
    
    Cc: Tilman Schmidt <tilman@imap.cc>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Change-Id: Ibed6feadfb9706d478f93feec3b240aecfc64af3
    Bug: 30951112
  4. qcedev: Validate Source and Destination addresses

    AnilKumar Chimata authored and mdmower committed Aug 31, 2016
    Source and Destination addresses passed by user space apps/clients
    are validated independent of type of operation to mitigate kernel
    address space exploitation.
    
    Change-Id: If831275cdcc96cb0bf829fc62056e408accbfcca
    Signed-off-by: AnilKumar Chimata <anilc@codeaurora.org>
    (cherry picked from commit 22e2854c99f88372d68d77622c83636727e53253)
  5. BACKPORT: audit: fix a double fetch in audit_log_single_execve_arg()

    pcmoore authored and mdmower committed Sep 13, 2016
    (cherry picked from commit 43761473c254b45883a64441dd0bc85a42f3645c)
    
    There is a double fetch problem in audit_log_single_execve_arg()
    where we first check the execve(2) argumnets for any "bad" characters
    which would require hex encoding and then re-fetch the arguments for
    logging in the audit record[1].  Of course this leaves a window of
    opportunity for an unsavory application to munge with the data.
    
    This patch reworks things by only fetching the argument data once[2]
    into a buffer where it is scanned and logged into the audit
    records(s).  In addition to fixing the double fetch, this patch
    improves on the original code in a few other ways: better handling
    of large arguments which require encoding, stricter record length
    checking, and some performance improvements (completely unverified,
    but we got rid of some strlen() calls, that's got to be a good
    thing).
    
    As part of the development of this patch, I've also created a basic
    regression test for the audit-testsuite, the test can be tracked on
    GitHub at the following link:
    
     * linux-audit/audit-testsuite#25
    
    [1] If you pay careful attention, there is actually a triple fetch
    problem due to a strnlen_user() call at the top of the function.
    
    [2] This is a tiny white lie, we do make a call to strnlen_user()
    prior to fetching the argument data.  I don't like it, but due to the
    way the audit record is structured we really have no choice unless we
    copy the entire argument at once (which would require a rather
    wasteful allocation).  The good news is that with this patch the
    kernel no longer relies on this strnlen_user() value for anything
    beyond recording it in the log, we also update it with a trustworthy
    value whenever possible.
    
    Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Change-Id: I10e979e94605e3cf8d461e3e521f8f9837228aa5
    Bug: 30956807
  6. perf: Fix race in swevent hash

    Peter Zijlstra authored and mdmower committed Dec 15, 2015
    There's a race on CPU unplug where we free the swevent hash array
    while it can still have events on. This will result in a
    use-after-free which is BAD.
    
    Simply do not free the hash array on unplug. This leaves the thing
    around and no use-after-free takes place.
    
    When the last swevent dies, we do a for_each_possible_cpu() iteration
    anyway to clean these up, at which time we'll free it, so no leakage
    will occur.
    
    Change-Id: I751faf3215bbdaa6b6358f3a752bdd24126cfa0b
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    (cherry picked from commit 230cfdd3e6e7ca8fd848d37e254589b282ea7f63)
  7. ALSA: usb-audio: Fix double-free in error paths after snd_usb_add_aud…

    nefigtut authored and mdmower committed Mar 31, 2016
    …io_stream() call
    
    create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
    create_uaxx_quirk() functions allocate the audioformat object by themselves
    and free it upon error before returning. However, once the object is linked
    to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
    double-freed, eventually resulting in a memory corruption.
    
    This patch fixes these failures in the error paths by unlinking the audioformat
    object before freeing it.
    
    Based on a patch by Takashi Iwai <tiwai@suse.de>
    
    [Note for stable backports:
     this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor
     code cleanup in create_fixed_stream_quirk()')]
    
    Change-Id: I129dc4f3b0ae4cb6f790c16d24dd768c9ee06822
    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358
    Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
    Cc: <stable@vger.kernel.org> # see the note above
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
  8. ALSA: usb-audio: Minor code cleanup in create_fixed_stream_quirk()

    tiwai authored and mdmower committed Mar 15, 2016
    Just a minor code cleanup: unify the error paths.
    
    Change-Id: I31346b08ed1024819c58eff797c63bb42c283512
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
  9. sg: Fix double-free when drives detach during SG_IO

    jcalvinowens authored and mdmower committed Oct 30, 2015
    In sg_common_write(), we free the block request and return -ENODEV if
    the device is detached in the middle of the SG_IO ioctl().
    
    Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
    end up freeing rq->cmd in the already free rq object, and then free
    the object itself out from under the current user.
    
    This ends up corrupting random memory via the list_head on the rq
    object. The most common crash trace I saw is this:
    
      ------------[ cut here ]------------
      kernel BUG at block/blk-core.c:1420!
      Call Trace:
      [<ffffffff81281eab>] blk_put_request+0x5b/0x80
      [<ffffffffa0069e5b>] sg_finish_rem_req+0x6b/0x120 [sg]
      [<ffffffffa006bcb9>] sg_common_write.isra.14+0x459/0x5a0 [sg]
      [<ffffffff8125b328>] ? selinux_file_alloc_security+0x48/0x70
      [<ffffffffa006bf95>] sg_new_write.isra.17+0x195/0x2d0 [sg]
      [<ffffffffa006cef4>] sg_ioctl+0x644/0xdb0 [sg]
      [<ffffffff81170f80>] do_vfs_ioctl+0x90/0x520
      [<ffffffff81258967>] ? file_has_perm+0x97/0xb0
      [<ffffffff811714a1>] SyS_ioctl+0x91/0xb0
      [<ffffffff81602afb>] tracesys+0xdd/0xe2
        RIP [<ffffffff81281e04>] __blk_put_request+0x154/0x1a0
    
    The solution is straightforward: just set srp->rq to NULL in the
    failure branch so that sg_finish_rem_req() doesn't attempt to re-free
    it.
    
    Additionally, since sg_rq_end_io() will never be called on the object
    when this happens, we need to free memory backing ->cmd if it isn't
    embedded in the object itself.
    
    KASAN was extremely helpful in finding the root cause of this bug.
    
    Change-Id: I8c2389a4e2e1b5f753a47f8af60502a761b891b5
    Signed-off-by: Calvin Owens <calvinowens@fb.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
  10. block: fix use-after-free in sys_ioprio_get()

    osandov authored and mdmower committed Jul 1, 2016
    get_task_ioprio() accesses the task->io_context without holding the task
    lock and thus can race with exit_io_context(), leading to a
    use-after-free. The reproducer below hits this within a few seconds on
    my 4-core QEMU VM:
    
    int main(int argc, char **argv)
    {
    	pid_t pid, child;
    	long nproc, i;
    
    	/* ioprio_set(IOPRIO_WHO_PROCESS, 0, IOPRIO_PRIO_VALUE(IOPRIO_CLASS_IDLE, 0)); */
    	syscall(SYS_ioprio_set, 1, 0, 0x6000);
    
    	nproc = sysconf(_SC_NPROCESSORS_ONLN);
    
    	for (i = 0; i < nproc; i++) {
    		pid = fork();
    		assert(pid != -1);
    		if (pid == 0) {
    			for (;;) {
    				pid = fork();
    				assert(pid != -1);
    				if (pid == 0) {
    					_exit(0);
    				} else {
    					child = wait(NULL);
    					assert(child == pid);
    				}
    			}
    		}
    
    		pid = fork();
    		assert(pid != -1);
    		if (pid == 0) {
    			for (;;) {
    				/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
    				syscall(SYS_ioprio_get, 2, 0);
    			}
    		}
    	}
    
    	for (;;) {
    		/* ioprio_get(IOPRIO_WHO_PGRP, 0); */
    		syscall(SYS_ioprio_get, 2, 0);
    	}
    
    	return 0;
    }
    
    This gets us KASAN dumps like this:
    
    [   35.526914] ==================================================================
    [   35.530009] BUG: KASAN: out-of-bounds in get_task_ioprio+0x7b/0x90 at addr ffff880066f34e6c
    [   35.530009] Read of size 2 by task ioprio-gpf/363
    [   35.530009] =============================================================================
    [   35.530009] BUG blkdev_ioc (Not tainted): kasan: bad access detected
    [   35.530009] -----------------------------------------------------------------------------
    
    [   35.530009] Disabling lock debugging due to kernel taint
    [   35.530009] INFO: Allocated in create_task_io_context+0x2b/0x370 age=0 cpu=0 pid=360
    [   35.530009] 	___slab_alloc+0x55d/0x5a0
    [   35.530009] 	__slab_alloc.isra.20+0x2b/0x40
    [   35.530009] 	kmem_cache_alloc_node+0x84/0x200
    [   35.530009] 	create_task_io_context+0x2b/0x370
    [   35.530009] 	get_task_io_context+0x92/0xb0
    [   35.530009] 	copy_process.part.8+0x5029/0x5660
    [   35.530009] 	_do_fork+0x155/0x7e0
    [   35.530009] 	SyS_clone+0x19/0x20
    [   35.530009] 	do_syscall_64+0x195/0x3a0
    [   35.530009] 	return_from_SYSCALL_64+0x0/0x6a
    [   35.530009] INFO: Freed in put_io_context+0xe7/0x120 age=0 cpu=0 pid=1060
    [   35.530009] 	__slab_free+0x27b/0x3d0
    [   35.530009] 	kmem_cache_free+0x1fb/0x220
    [   35.530009] 	put_io_context+0xe7/0x120
    [   35.530009] 	put_io_context_active+0x238/0x380
    [   35.530009] 	exit_io_context+0x66/0x80
    [   35.530009] 	do_exit+0x158e/0x2b90
    [   35.530009] 	do_group_exit+0xe5/0x2b0
    [   35.530009] 	SyS_exit_group+0x1d/0x20
    [   35.530009] 	entry_SYSCALL_64_fastpath+0x1a/0xa4
    [   35.530009] INFO: Slab 0xffffea00019bcd00 objects=20 used=4 fp=0xffff880066f34ff0 flags=0x1fffe0000004080
    [   35.530009] INFO: Object 0xffff880066f34e58 @offset=3672 fp=0x0000000000000001
    [   35.530009] ==================================================================
    
    Fix it by grabbing the task lock while we poke at the io_context.
    
    Change-Id: I4261aaf076fab943a80a45b0a77e023aa4ecbbd8
    Cc: stable@vger.kernel.org
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
  11. block: fix use-after-free in seq file

    vegard authored and mdmower committed Jul 29, 2016
    I got a KASAN report of use-after-free:
    
        ==================================================================
        BUG: KASAN: use-after-free in klist_iter_exit+0x61/0x70 at addr ffff8800b6581508
        Read of size 8 by task trinity-c1/315
        =============================================================================
        BUG kmalloc-32 (Not tainted): kasan: bad access detected
        -----------------------------------------------------------------------------
    
        Disabling lock debugging due to kernel taint
        INFO: Allocated in disk_seqf_start+0x66/0x110 age=144 cpu=1 pid=315
                ___slab_alloc+0x4f1/0x520
                __slab_alloc.isra.58+0x56/0x80
                kmem_cache_alloc_trace+0x260/0x2a0
                disk_seqf_start+0x66/0x110
                traverse+0x176/0x860
                seq_read+0x7e3/0x11a0
                proc_reg_read+0xbc/0x180
                do_loop_readv_writev+0x134/0x210
                do_readv_writev+0x565/0x660
                vfs_readv+0x67/0xa0
                do_preadv+0x126/0x170
                SyS_preadv+0xc/0x10
                do_syscall_64+0x1a1/0x460
                return_from_SYSCALL_64+0x0/0x6a
        INFO: Freed in disk_seqf_stop+0x42/0x50 age=160 cpu=1 pid=315
                __slab_free+0x17a/0x2c0
                kfree+0x20a/0x220
                disk_seqf_stop+0x42/0x50
                traverse+0x3b5/0x860
                seq_read+0x7e3/0x11a0
                proc_reg_read+0xbc/0x180
                do_loop_readv_writev+0x134/0x210
                do_readv_writev+0x565/0x660
                vfs_readv+0x67/0xa0
                do_preadv+0x126/0x170
                SyS_preadv+0xc/0x10
                do_syscall_64+0x1a1/0x460
                return_from_SYSCALL_64+0x0/0x6a
    
        CPU: 1 PID: 315 Comm: trinity-c1 Tainted: G    B           4.7.0+ #62
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
         ffffea0002d96000 ffff880119b9f918 ffffffff81d6ce81 ffff88011a804480
         ffff8800b6581500 ffff880119b9f948 ffffffff8146c7bd ffff88011a804480
         ffffea0002d96000 ffff8800b6581500 fffffffffffffff4 ffff880119b9f970
        Call Trace:
         [<ffffffff81d6ce81>] dump_stack+0x65/0x84
         [<ffffffff8146c7bd>] print_trailer+0x10d/0x1a0
         [<ffffffff814704ff>] object_err+0x2f/0x40
         [<ffffffff814754d1>] kasan_report_error+0x221/0x520
         [<ffffffff8147590e>] __asan_report_load8_noabort+0x3e/0x40
         [<ffffffff83888161>] klist_iter_exit+0x61/0x70
         [<ffffffff82404389>] class_dev_iter_exit+0x9/0x10
         [<ffffffff81d2e8ea>] disk_seqf_stop+0x3a/0x50
         [<ffffffff8151f812>] seq_read+0x4b2/0x11a0
         [<ffffffff815f8fdc>] proc_reg_read+0xbc/0x180
         [<ffffffff814b24e4>] do_loop_readv_writev+0x134/0x210
         [<ffffffff814b4c45>] do_readv_writev+0x565/0x660
         [<ffffffff814b8a17>] vfs_readv+0x67/0xa0
         [<ffffffff814b8de6>] do_preadv+0x126/0x170
         [<ffffffff814b92ec>] SyS_preadv+0xc/0x10
    
    This problem can occur in the following situation:
    
    open()
     - pread()
        - .seq_start()
           - iter = kmalloc() // succeeds
           - seqf->private = iter
        - .seq_stop()
           - kfree(seqf->private)
     - pread()
        - .seq_start()
           - iter = kmalloc() // fails
        - .seq_stop()
           - class_dev_iter_exit(seqf->private) // boom! old pointer
    
    As the comment in disk_seqf_stop() says, stop is called even if start
    failed, so we need to reinitialise the private pointer to NULL when seq
    iteration stops.
    
    An alternative would be to set the private pointer to NULL when the
    kmalloc() in disk_seqf_start() fails.
    
    Change-Id: I41ee55505a213f99a92ce630885e6c31b4b60232
    Cc: stable@vger.kernel.org
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jens Axboe <axboe@fb.com>
  12. proc: fix build broken by proc inode per namespace patch

    Jin Qian authored and mdmower committed Jul 20, 2015
    Change-Id: I119e4f31584b4a7ab9d6825499947d59c1293f1b
  13. KEYS: Fix short sprintf buffer in /proc/keys show function

    dhowells authored and mdmower committed Sep 6, 2016
    Fix a short sprintf buffer in proc_keys_show().  If the gcc stack protector
    is turned on, this can cause a panic due to stack corruption.
    
    The problem is that xbuf[] is not big enough to hold a 64-bit timeout
    rendered as weeks:
    
    	(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
    	$2 = 30500568904943
    
    That's 14 chars plus NUL, not 11 chars plus NUL.
    
    Expand the buffer to 16 chars.
    
    I think the unpatched code apparently works if the stack-protector is not
    enabled because on a 32-bit machine the buffer won't be overflowed and on a
    64-bit machine there's a 64-bit aligned pointer at one side and an int that
    isn't checked again on the other side.
    
    The panic incurred looks something like:
    
    Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
    CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
     0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
     ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
     ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
    Call Trace:
     [<ffffffff813d941f>] dump_stack+0x63/0x84
     [<ffffffff811b2cb6>] panic+0xde/0x22a
     [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
     [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
     [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
     [<ffffffff81350410>] ? key_validate+0x50/0x50
     [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
     [<ffffffff8126b31c>] seq_read+0x2cc/0x390
     [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
     [<ffffffff81244fc7>] __vfs_read+0x37/0x150
     [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
     [<ffffffff81246156>] vfs_read+0x96/0x130
     [<ffffffff81247635>] SyS_read+0x55/0xc0
     [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4
    
    Change-Id: I0787d5a38c730ecb75d3c08f28f0ab36295d59e7
    Reported-by: Ondrej Kozina <okozina@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Ondrej Kozina <okozina@redhat.com>
  14. tcp: fix use after free in tcp_xmit_retransmit_queue()

    Eric Dumazet authored and mdmower committed Aug 17, 2016
    When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
    tail of the write queue using tcp_add_write_queue_tail()
    
    Then it attempts to copy user data into this fresh skb.
    
    If the copy fails, we undo the work and remove the fresh skb.
    
    Unfortunately, this undo lacks the change done to tp->highest_sack and
    we can leave a dangling pointer (to a freed skb)
    
    Later, tcp_xmit_retransmit_queue() can dereference this pointer and
    access freed memory. For regular kernels where memory is not unmapped,
    this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
    returning garbage instead of tp->snd_nxt, but with various debug
    features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.
    
    This bug was found by Marco Grassi thanks to syzkaller.
    
    Change-Id: I264f97d30d0a623011d9ee811c63fa0e0c2149a2
    Fixes: 6859d49 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
    Reported-by: Marco Grassi <marco.gra@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
  15. mm: remove gup_flags FOLL_WRITE games from __get_user_pages()

    torvalds authored and mdmower committed Oct 19, 2016
    This is an ancient bug that was actually attempted to be fixed once
    (badly) by me eleven years ago in commit 4ceb5db ("Fix
    get_user_pages() race for write access") but that was then undone due to
    problems on s390 by commit f33ea7f ("fix get_user_pages bug").
    
    In the meantime, the s390 situation has long been fixed, and we can now
    fix it by checking the pte_dirty() bit properly (and do it better).  The
    s390 dirty bit was implemented in abf09be ("s390/mm: implement
    software dirty bits") which made it into v3.9.  Earlier kernels will
    have to look at the page state itself.
    
    Also, the VM has become more scalable, and what used a purely
    theoretical race back then has become easier to trigger.
    
    To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
    we already did a COW" rather than play racy games with FOLL_WRITE that
    is very fundamental, and then use the pte dirty flag to validate that
    the FOLL_COW flag is still valid.
    
    Change-Id: Id9bec3722797dff7d0ff0d9f6097c4229e31fd62
    Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
    Acked-by: Hugh Dickins <hughd@google.com>
    Reviewed-by: Michal Hocko <mhocko@suse.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: Nick Piggin <npiggin@gmail.com>
    Cc: Greg Thelen <gthelen@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [wt: s/gup.c/memory.c; s/follow_page_pte/follow_page_mask;
         s/faultin_page/__get_user_page]
    Signed-off-by: Willy Tarreau <w@1wt.eu>
Commits on Oct 17, 2016
  1. fix infoleak in rtnetlink

    kengiter authored and mdmower committed May 4, 2016
    the stack object “map” has a total size of 32 bytes. Its last 4
    bytes are padding generated by compiler. These padding bytes are
    not initialized and sent out via “nla_put”
    
    Bug: 28620102
    
    Change-Id: I13da380c6fe8abca49e3cf9f05293c02b44d2e5e
    Signed-off-by: kangjie <kangjielu@gmail.com>
  2. Replace %p with %pK to prevent leaking kernel address

    mkayyash authored and mdmower committed May 24, 2016
    BUG: 27532522
    Change-Id: Ic0710a9a8cfc682acd88ecf3bbfeece2d798c4a4
    Signed-off-by: Mohamad Ayyash <mkayyash@google.com>
  3. fs: ext4: disable support for fallocate FALLOC_FL_PUNCH_HOLE

    nickdesaulniers authored and mdmower committed Jul 18, 2016
    Bug: 28760453
    Change-Id: I019c2de559db9e4b95860ab852211b456d78c4ca
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
  4. binder: prevent kptr leak by using %pK format specifier

    nickdesaulniers authored and mdmower committed Aug 17, 2016
    Works in conjunction with kptr_restrict.
    Bug: 30143283
    
    Change-Id: I2b3ce22f4e206e74614d51453a1d59b7080ab05a
  5. net: Fix use after free in the recvmmsg exit path

    Arnaldo Carvalho de Melo authored and mdmower committed Mar 14, 2016
    The syzkaller fuzzer hit the following use-after-free:
    
      Call Trace:
       [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
       [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
       [<     inline     >] SYSC_recvmmsg net/socket.c:2281
       [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
       [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
      arch/x86/entry/entry_64.S:185
    
    And, as Dmitry rightly assessed, that is because we can drop the
    reference and then touch it when the underlying recvmsg calls return
    some packets and then hit an error, which will make recvmmsg to set
    sock->sk->sk_err, oops, fix it.
    
    Reported-and-Tested-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Fixes: a2e2725 ("net: Introduce recvmmsg socket syscall")
    http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    
    Change-Id: Ie3b6ee89ad3e8cd3a0fe8f50f74aaa4834d0b4ca
  6. perf: duplicate deletion of perf event

    Srinivasarao P authored and mdmower committed Mar 1, 2016
    a malicious app can open a perf event with constraint_duplicate
    bit set, disable the event, and close the fd.  On closing the fd,
    the perf_release() modification causes the kernel to clean up
    the event as if it still were enabled, leading to the event
    being removed from a list twice.
    
    CRs-Fixed: 977563
    Change-Id: I5fbec3722407d2f3d0ff0d9f7097c5889e31fd62
    Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
  7. ASoC: msm: audio-effects: misc fixes in h/w accelerated effect

    Weiyin Jiang authored and mdmower committed Apr 26, 2016
    Adding memory copy size check and integer overflow check in h/w
    accelerated effect driver.
    
    Change-Id: I17d4cc0a38770f0c5067fa8047cd63e7bf085e48
    CRs-Fixed: 1006609
    Signed-off-by: Weiyin Jiang <wjiang@codeaurora.org>
  8. msm: perf: Do not allocate new hw_event if event is duplicate.

    Veena Sambasivan authored and mdmower committed May 20, 2016
    During a perf_event_enable, kernel/events/core.c calls pmu->add() which
    is platform implementation(arch/arm/kernel/perf_event.c). Due to the
    duplicate constraints, arch/arm/mach-msm/perf_event_msm_krait_l2.c
    drivers marks the event as OFF but returns TRUE to perf_event.c which
    goes ahead and allocates the hw_event and enables it.
    Since event is marked OFF, kernel events core will try to enable this event
    again during next perf_event_enable. Which results in same event enabled
    on multiple hw_events. But during the perf_release, event struct is freed
    and only one hw_event is released. This results in dereferencing the
    invalid pointer and hence the crash.
    Fix this by returning error in case of constraint event duplicate. Hence
    avoiding the same event programmed on multiple hw event counters.
    
    bug: 28172137
    Change-Id: Ia3360be027dfe87ac753191ffe7e0bc947e72455
    Signed-off-by: Arun KS <arunks@codeaurora.org>
    Signed-off-by: Veena Sambasivan <veenas@codeaurora.org>
  9. UPSTREAM: netfilter: x_tables: validate e->target_offset early

    Florian Westphal authored and mdmower committed Mar 22, 2016
    (cherry pick from commit bdf533de6968e9686df777dc178486f600c6e617)
    
    We should check that e->target_offset is sane before
    mark_source_chains gets called since it will fetch the target entry
    for loop detection.
    
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Change-Id: Ic2dbc31c9525d698e94d4d8875886acf3524abbd
    Bug: 29637687
Commits on Sep 30, 2016
  1. wcnss: Avoid user buffer overloading for write cal data

    Anand Kumar authored and mdmower committed Jun 21, 2016
    compare size of allocated cal data buffer from heap
    and count bytes provided to write by user to avoid
    heap overflow for write cal data.
    
    Change-Id: Id70c3230f761385489e5e94c613f4519239dfb1f
    CRs-Fixed: 1032174
    Signed-off-by: Anand Kumar <anandkumar@codeaurora.org>
Commits on Aug 17, 2016
  1. msm: kgsl: Defer adding the mem entry to a process

    Sunil Khatri authored and mdmower committed Jun 13, 2016
    If we add the mem entry pointer in the process idr and rb tree
    too early, other threads can do operations on the entry by
    guessing the ID or GPU address before the object gets returned
    by the creating operation.
    
    Allocate an ID for the object but don't assign the pointer until
    right before the creating function returns ensuring that another
    operation can't access it until it is ready.
    
    Bug: 28026365
    CRs-Fixed: 1002974
    Change-Id: Ic0dedbadc0dd2125bd2a7bcc152972c0555e07f8
    Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
    Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
    Signed-off-by: Santhosh Punugu <spunug@codeaurora.org>
  2. net: ipc_router: Bind only a client port as control port

    Karthikeyan Ramasubramanian authored and mdmower committed Feb 22, 2016
    IPC Router binds any port as a control port and moves it from the client
    port list to control port list. Misbehaving clients can exploit this
    incorrect behavior.
    
    IPC Router to check if the port is a client port before binding it as a
    control port.
    
    CRs-Fixed: 974577
    Change-Id: I9f189b76967d5f85750218a7cb6537d187a69663
    Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
  3. ashmem: Validate ashmem memory with fops pointer

    Sunil Khatri authored and mdmower committed Jun 22, 2016
    Validate the ashmem memory entry against f_op pointer
    rather then comparing its name with path of the dentry.
    
    This is to avoid any invalid access to ashmem area in cases
    where some one deliberately set the dentry name to /ashmem.
    
    Change-Id: I74e50cd244f68cb13009cf2355e528485f4de34b
    Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>