1. 10 Mar, 2020 1 commit
    • Marek Szyprowski's avatar
      drm/exynos: Fix cleanup of IOMMU related objects · 07dc3678
      Marek Szyprowski authored
      Store the IOMMU mapping created by the device core of each Exynos DRM
      sub-device and restore it when the Exynos DRM driver is unbound. This
      fixes IOMMU initialization failure for the second time when a deferred
      probe is triggered from the bind() callback of master's compound DRM
      driver. This also fixes the following issue found using kmemleak
      detector:
      
      unreferenced object 0xc2137640 (size 64):
        comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
        hex dump (first 32 bytes):
          50 a3 14 c2 80 a2 14 c2 01 00 00 00 20 00 00 00  P........... ...
          00 10 00 00 00 80 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<3acd268d>] arch_setup_dma_ops+0x4c/0x104
          [<9f7d2cce>] of_dma_configure+0x19c/0x3a4
          [<ba07704b>] really_probe+0xb0/0x47c
          [<4f510e4f>] driver_probe_device+0x78/0x1c4
          [<7481a0cf>] device_driver_attach+0x58/0x60
          [<0ff8f5c1>] __driver_attach+0xb8/0x158
          [<86006144>] bus_for_each_dev+0x74/0xb4
          [<10159dca>] bus_add_driver+0x1c0/0x200
          [<8a265265>] driver_register+0x74/0x108
          [<e0f3451a>] exynos_drm_init+0xb0/0x134
          [<db3fc7ba>] do_one_initcall+0x90/0x458
          [<6da35917>] kernel_init_freeable+0x188/0x200
          [<db3f74d4>] kernel_init+0x8/0x110
          [<1f3cddf9>] ret_from_fork+0x14/0x20
          [<8cd12507>] 0x0
      unreferenced object 0xc214a280 (size 128):
        comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
        hex dump (first 32 bytes):
          00 a0 ec ed 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<3acd268d>] arch_setup_dma_ops+0x4c/0x104
          [<9f7d2cce>] of_dma_configure+0x19c/0x3a4
          [<ba07704b>] really_probe+0xb0/0x47c
          [<4f510e4f>] driver_probe_device+0x78/0x1c4
          [<7481a0cf>] device_driver_attach+0x58/0x60
          [<0ff8f5c1>] __driver_attach+0xb8/0x158
          [<86006144>] bus_for_each_dev+0x74/0xb4
          [<10159dca>] bus_add_driver+0x1c0/0x200
          [<8a265265>] driver_register+0x74/0x108
          [<e0f3451a>] exynos_drm_init+0xb0/0x134
          [<db3fc7ba>] do_one_initcall+0x90/0x458
          [<6da35917>] kernel_init_freeable+0x188/0x200
          [<db3f74d4>] kernel_init+0x8/0x110
          [<1f3cddf9>] ret_from_fork+0x14/0x20
          [<8cd12507>] 0x0
      unreferenced object 0xedeca000 (size 4096):
        comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<3acd268d>] arch_setup_dma_ops+0x4c/0x104
          [<9f7d2cce>] of_dma_configure+0x19c/0x3a4
          [<ba07704b>] really_probe+0xb0/0x47c
          [<4f510e4f>] driver_probe_device+0x78/0x1c4
          [<7481a0cf>] device_driver_attach+0x58/0x60
          [<0ff8f5c1>] __driver_attach+0xb8/0x158
          [<86006144>] bus_for_each_dev+0x74/0xb4
          [<10159dca>] bus_add_driver+0x1c0/0x200
          [<8a265265>] driver_register+0x74/0x108
          [<e0f3451a>] exynos_drm_init+0xb0/0x134
          [<db3fc7ba>] do_one_initcall+0x90/0x458
          [<6da35917>] kernel_init_freeable+0x188/0x200
          [<db3f74d4>] kernel_init+0x8/0x110
          [<1f3cddf9>] ret_from_fork+0x14/0x20
          [<8cd12507>] 0x0
      unreferenced object 0xc214a300 (size 128):
        comm "swapper/0", pid 1, jiffies 4294937900 (age 3127.400s)
        hex dump (first 32 bytes):
          00 a3 14 c2 00 a3 14 c2 00 40 18 c2 00 80 18 c2  .........@......
          02 00 02 00 ad 4e ad de ff ff ff ff ff ff ff ff  .....N..........
        backtrace:
          [<08cbd8bc>] iommu_domain_alloc+0x24/0x50
          [<b835abee>] arm_iommu_create_mapping+0xe4/0x134
          [<3acd268d>] arch_setup_dma_ops+0x4c/0x104
          [<9f7d2cce>] of_dma_configure+0x19c/0x3a4
          [<ba07704b>] really_probe+0xb0/0x47c
          [<4f510e4f>] driver_probe_device+0x78/0x1c4
          [<7481a0cf>] device_driver_attach+0x58/0x60
          [<0ff8f5c1>] __driver_attach+0xb8/0x158
          [<86006144>] bus_for_each_dev+0x74/0xb4
          [<10159dca>] bus_add_driver+0x1c0/0x200
          [<8a265265>] driver_register+0x74/0x108
          [<e0f3451a>] exynos_drm_init+0xb0/0x134
          [<db3fc7ba>] do_one_initcall+0x90/0x458
          [<6da35917>] kernel_init_freeable+0x188/0x200
          [<db3f74d4>] kernel_init+0x8/0x110
          [<1f3cddf9>] ret_from_fork+0x14/0x20
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarLukasz Luba <lukasz.luba@arm.com>
      Signed-off-by: default avatarInki Dae <inki.dae@samsung.com>
      07dc3678
  2. 06 Mar, 2020 3 commits
    • Zhang Xiaoxu's avatar
      vgacon: Fix a UAF in vgacon_invert_region · 513dc792
      Zhang Xiaoxu authored
      When syzkaller tests, there is a UAF:
        BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
          ffff880000100000
        Read of size 2 by task syz-executor.1/16489
        page:ffffea0000004000 count:0 mapcount:-127 mapping:          (null)
        index:0x0
        page flags: 0xfffff00000000()
        page dumped because: kasan: bad access detected
        CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
        rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
        Call Trace:
          [<ffffffffb119f309>] dump_stack+0x1e/0x20
          [<ffffffffb04af957>] kasan_report+0x577/0x950
          [<ffffffffb04ae652>] __asan_load2+0x62/0x80
          [<ffffffffb090f26d>] vgacon_invert_region+0x9d/0x110
          [<ffffffffb0a39d95>] invert_screen+0xe5/0x470
          [<ffffffffb0a21dcb>] set_selection+0x44b/0x12f0
          [<ffffffffb0a3bfae>] tioclinux+0xee/0x490
          [<ffffffffb0a1d114>] vt_ioctl+0xff4/0x2670
          [<ffffffffb0a0089a>] tty_ioctl+0x46a/0x1a10
          [<ffffffffb052db3d>] do_vfs_ioctl+0x5bd/0xc40
          [<ffffffffb052e2f2>] SyS_ioctl+0x132/0x170
          [<ffffffffb11c9b1b>] system_call_fastpath+0x22/0x27
          Memory state around the buggy address:
           ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
           00 00
           ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00
           00 00 00
          >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff
           ff ff ff
      
      It can be reproduce in the linux mainline by the program:
        #include <stdio.h>
        #include <stdlib.h>
        #include <unistd.h>
        #include <fcntl.h>
        #include <sys/types.h>
        #include <sys/stat.h>
        #include <sys/ioctl.h>
        #include <linux/vt.h>
      
        struct tiocl_selection {
          unsigned short xs;      /* X start */
          unsigned short ys;      /* Y start */
          unsigned short xe;      /* X end */
          unsigned short ye;      /* Y end */
          unsigned short sel_mode; /* selection mode */
        };
      
        #define TIOCL_SETSEL    2
        struct tiocl {
          unsigned char type;
          unsigned char pad;
          struct tiocl_selection sel;
        };
      
        int main()
        {
          int fd = 0;
          const char *dev = "/dev/char/4:1";
      
          struct vt_consize v = {0};
          struct tiocl tioc = {0};
      
          fd = open(dev, O_RDWR, 0);
      
          v.v_rows = 3346;
          ioctl(fd, VT_RESIZEX, &v);
      
          tioc.type = TIOCL_SETSEL;
          ioctl(fd, TIOCLINUX, &tioc);
      
          return 0;
        }
      
      When resize the screen, update the 'vc->vc_size_row' to the new_row_size,
      but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base'
      for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe
      smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc
      the offset, it maybe larger than the vga_vram_size in vgacon driver, then
      bad access.
      Also, if set an larger screenbuf firstly, then set an more larger
      screenbuf, when copy old_origin to new_origin, a bad access may happen.
      
      So, If the screen size larger than vga_vram, resize screen should be
      failed. This alse fix CVE-2020-8649 and CVE-2020-8647.
      
      Linus pointed out that overflow checking seems absent. We're saved by
      the existing bounds checks in vc_do_resize() with rather strict
      limits:
      
      	if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW)
      		return -EINVAL;
      
      Fixes: 0aec4867 ("[PATCH] SVGATextMode fix")
      Reference: CVE-2020-8647 and CVE-2020-8649
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZhang Xiaoxu <zhangxiaoxu5@huawei.com>
      [danvet: augment commit message to point out overflow safety]
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com
      513dc792
    • Dave Airlie's avatar
      Merge tag 'amd-drm-fixes-5.6-2020-03-05' of... · 2ac4853e
      Dave Airlie authored
      Merge tag 'amd-drm-fixes-5.6-2020-03-05' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
      
      amd-drm-fixes-5.6-2020-03-05:
      
      amdgpu:
      - Gfx reset fix for gfx9, 10
      - Fix for gfx10
      - DP MST fix
      - DCC fix
      - Renoir power fixes
      - Navi power fix
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Alex Deucher <alexdeucher@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200305185957.4268-1-alexander.deucher@amd.com
      2ac4853e
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2020-03-05' of... · 64c3fd53
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2020-03-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      drm/i915 fixes for v5.6-rc5:
      - Break up long lists of object reclaim with cond_resched()
      - PSR probe fix
      - TGL workarounds
      - Selftest return value fix
      - Drop timeline mutex while waiting for retirement
      - Wait for OA configuration completion before writes to OA buffer
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      
      From: Jani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/87eeu7nl6z.fsf@intel.com
      64c3fd53
  3. 05 Mar, 2020 10 commits
  4. 04 Mar, 2020 3 commits
  5. 03 Mar, 2020 3 commits
  6. 02 Mar, 2020 11 commits
  7. 01 Mar, 2020 5 commits
  8. 29 Feb, 2020 4 commits
    • Dan Carpenter's avatar
      ext4: potential crash on allocation error in ext4_alloc_flex_bg_array() · 37b0b6b8
      Dan Carpenter authored
      If sbi->s_flex_groups_allocated is zero and the first allocation fails
      then this code will crash.  The problem is that "i--" will set "i" to
      -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1
      is type promoted to unsigned and becomes UINT_MAX.  Since UINT_MAX
      is more than zero, the condition is true so we call kvfree(new_groups[-1]).
      The loop will carry on freeing invalid memory until it crashes.
      
      Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access")
      Reviewed-by: default avatarSuraj Jitindar Singh <surajjs@amazon.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@kernel.org
      Link: https://lore.kernel.org/r/20200228092142.7irbc44yaz3by7nb@kili.mountainSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      37b0b6b8
    • Wolfram Sang's avatar
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      Wolfram Sang authored
      Removing attach_adapter from this driver caused a regression for at
      least some machines. Those machines had the sensors described in their
      DT, too, so they didn't need manual creation of the sensor devices. The
      old code worked, though, because manual creation came first. Creation of
      DT devices then failed later and caused error logs, but the sensors
      worked nonetheless because of the manually created devices.
      
      When removing attach_adaper, manual creation now comes later and loses
      the race. The sensor devices were already registered via DT, yet with
      another binding, so the driver could not be bound to it.
      
      This fix refactors the code to remove the race and only manually creates
      devices if there are no DT nodes present. Also, the DT binding is updated
      to match both, the DT and manually created devices. Because we don't
      know which device creation will be used at runtime, the code to start
      the kthread is moved to do_probe() which will be called by both methods.
      
      Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Tested-by: default avatarErhard Furtner <erhard_f@mailbox.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org # v4.19+
      38b17afb
    • Qian Cai's avatar
      jbd2: fix data races at struct journal_head · 6c5d9112
      Qian Cai authored
      journal_head::b_transaction and journal_head::b_next_transaction could
      be accessed concurrently as noticed by KCSAN,
      
       LTP: starting fsync04
       /dev/zero: Can't open blockdev
       EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
       EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
       ==================================================================
       BUG: KCSAN: data-race in __jbd2_journal_refile_buffer [jbd2] / jbd2_write_access_granted [jbd2]
      
       write to 0xffff99f9b1bd0e30 of 8 bytes by task 25721 on cpu 70:
        __jbd2_journal_refile_buffer+0xdd/0x210 [jbd2]
        __jbd2_journal_refile_buffer at fs/jbd2/transaction.c:2569
        jbd2_journal_commit_transaction+0x2d15/0x3f20 [jbd2]
        (inlined by) jbd2_journal_commit_transaction at fs/jbd2/commit.c:1034
        kjournald2+0x13b/0x450 [jbd2]
        kthread+0x1cd/0x1f0
        ret_from_fork+0x27/0x50
      
       read to 0xffff99f9b1bd0e30 of 8 bytes by task 25724 on cpu 68:
        jbd2_write_access_granted+0x1b2/0x250 [jbd2]
        jbd2_write_access_granted at fs/jbd2/transaction.c:1155
        jbd2_journal_get_write_access+0x2c/0x60 [jbd2]
        __ext4_journal_get_write_access+0x50/0x90 [ext4]
        ext4_mb_mark_diskspace_used+0x158/0x620 [ext4]
        ext4_mb_new_blocks+0x54f/0xca0 [ext4]
        ext4_ind_map_blocks+0xc79/0x1b40 [ext4]
        ext4_map_blocks+0x3b4/0x950 [ext4]
        _ext4_get_block+0xfc/0x270 [ext4]
        ext4_get_block+0x3b/0x50 [ext4]
        __block_write_begin_int+0x22e/0xae0
        __block_write_begin+0x39/0x50
        ext4_write_begin+0x388/0xb50 [ext4]
        generic_perform_write+0x15d/0x290
        ext4_buffered_write_iter+0x11f/0x210 [ext4]
        ext4_file_write_iter+0xce/0x9e0 [ext4]
        new_sync_write+0x29c/0x3b0
        __vfs_write+0x92/0xa0
        vfs_write+0x103/0x260
        ksys_write+0x9d/0x130
        __x64_sys_write+0x4c/0x60
        do_syscall_64+0x91/0xb05
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       5 locks held by fsync04/25724:
        #0: ffff99f9911093f8 (sb_writers#13){.+.+}, at: vfs_write+0x21c/0x260
        #1: ffff99f9db4c0348 (&sb->s_type->i_mutex_key#15){+.+.}, at: ext4_buffered_write_iter+0x65/0x210 [ext4]
        #2: ffff99f5e7dfcf58 (jbd2_handle){++++}, at: start_this_handle+0x1c1/0x9d0 [jbd2]
        #3: ffff99f9db4c0168 (&ei->i_data_sem){++++}, at: ext4_map_blocks+0x176/0x950 [ext4]
        #4: ffffffff99086b40 (rcu_read_lock){....}, at: jbd2_write_access_granted+0x4e/0x250 [jbd2]
       irq event stamp: 1407125
       hardirqs last  enabled at (1407125): [<ffffffff980da9b7>] __find_get_block+0x107/0x790
       hardirqs last disabled at (1407124): [<ffffffff980da8f9>] __find_get_block+0x49/0x790
       softirqs last  enabled at (1405528): [<ffffffff98a0034c>] __do_softirq+0x34c/0x57c
       softirqs last disabled at (1405521): [<ffffffff97cc67a2>] irq_exit+0xa2/0xc0
      
       Reported by Kernel Concurrency Sanitizer on:
       CPU: 68 PID: 25724 Comm: fsync04 Tainted: G L 5.6.0-rc2-next-20200221+ #7
       Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
      
      The plain reads are outside of jh->b_state_lock critical section which result
      in data races. Fix them by adding pairs of READ|WRITE_ONCE().
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Link: https://lore.kernel.org/r/20200222043111.2227-1-cai@lca.pwSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      6c5d9112
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 7557c1b3
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Four small fixes.
      
        Three are in drivers for fairly obvious bugs. The fourth is a set of
        regressions introduced by the compat_ioctl changes because some of the
        compat updates wrongly replaced .ioctl instead of .compat_ioctl"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: compat_ioctl: cdrom: Replace .ioctl with .compat_ioctl in four appropriate places
        scsi: zfcp: fix wrong data and display format of SFP+ temperature
        scsi: sd_sbc: Fix sd_zbc_report_zones()
        scsi: libfc: free response frame from GPN_ID
      7557c1b3