This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git. Pull mirroring updated .
  1. 25 Jan, 2023 1 commit
  2. 18 Jan, 2023 22 commits
    • Michal Hocko's avatar
      mm, oom: do not trigger out_of_memory from the #PF · 39bdf044
      Michal Hocko authored
      commit 60e2793d440a3ec95abb5d6d4fc034a4b480472d upstream.
      
      Any allocation failure during the #PF path will return with VM_FAULT_OOM
      which in turn results in pagefault_out_of_memory.  This can happen for 2
      different reasons.  a) Memcg is out of memory and we rely on
      mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
      normal allocation fails.
      
      The latter is quite problematic because allocation paths already trigger
      out_of_memory and the page allocator tries really hard to not fail
      allocations.  Anyway, if the OOM killer has been already invoked there
      is no reason to invoke it again from the #PF path.  Especially when the
      OOM condition might be gone by that time and we have no way to find out
      other than allocate.
      
      Moreover if the allocation failed and the OOM killer hasn't been invoked
      then we are unlikely to do the right thing from the #PF context because
      we have already lost the allocation context and restictions and
      therefore might oom kill a task from a different NUMA domain.
      
      This all suggests that there is no legitimate reason to trigger
      out_of_memory from pagefault_out_of_memory so drop it.  Just to be sure
      that no #PF path returns with VM_FAULT_OOM without allocation print a
      warning that this is happening before we restart the #PF.
      
      [VvS: #PF allocation can hit into limit of cgroup v1 kmem controller.
      This is a local problem related to memcg, however, it causes unnecessary
      global OOM kills that are repeated over and over again and escalate into a
      real disaster.  This has been broken since kmem accounting has been
      introduced for cgroup v1 (3.8).  There was no kmem specific reclaim for
      the separate limit so the only way to handle kmem hard limit was to return
      with ENOMEM.  In upstream the problem will be fixed by removing the
      outdated kmem limit, however stable and LTS kernels cannot do it and are
      still affected.  This patch fixes the problem and should be backported
      into stable/LTS.]
      
      Link: https://lkml.kernel.org/r/f5fd8dd8-0ad4-c524-5f65-920b01972a42@virtuozzo.com
      
      
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Cc: Uladzislau Rezki <urezki@gmail.com>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [uli: backport to 4.4]
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      39bdf044
    • Keita Suzuki's avatar
      media: dvb-core: Fix double free in dvb_register_device() · ae54d447
      Keita Suzuki authored
      commit 6b0d0477fce747d4137aa65856318b55fba72198 upstream.
      
      In function dvb_register_device() -> dvb_register_media_device() ->
      dvb_create_media_entity(), dvb->entity is allocated and initialized. If
      the initialization fails, it frees the dvb->entity, and return an error
      code. The caller takes the error code and handles the error by calling
      dvb_media_device_free(), which unregisters the entity and frees the
      field again if it is not NULL. As dvb->entity may not NULLed in
      dvb_create_media_entity() when the allocation of dvbdev->pad fails, a
      double free may occur. This may also cause an Use After free in
      media_device_unregister_entity().
      
      Fix this by storing NULL to dvb->entity when it is freed.
      
      Link: https://lore.kernel.org/linux-media/20220426052921.2088416-1-keitasuzuki.park@sslab.ics.keio.ac.jp
      Fixes: fcd5ce4b
      
       ("media: dvb-core: fix a memory leak bug")
      Cc: stable@vger.kernel.org
      Cc: Wenwen Wang <wenwen@cs.uga.edu>
      Signed-off-by: default avatarKeita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
      Signed-off-by: Mauro Carvalho Chehab's avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [uli: backport to 4.4]
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      ae54d447
    • Jan Kara's avatar
      ext4: avoid BUG_ON when creating xattrs · 7bb79477
      Jan Kara authored
      commit b40ebaf63851b3a401b0dc9263843538f64f5ce6 upstream.
      
      Commit fb0a387d ("ext4: limit block allocations for indirect-block
      files to < 2^32") added code to try to allocate xattr block with 32-bit
      block number for indirect block based files on the grounds that these
      files cannot use larger block numbers. It also added BUG_ON when
      allocated block could not fit into 32 bits. This is however bogus
      reasoning because xattr block is stored in inode->i_file_acl and
      inode->i_file_acl_hi and as such even indirect block based files can
      happily use full 48 bits for xattr block number. The proper handling
      seems to be there basically since 64-bit block number support was added.
      So remove the bogus limitation and BUG_ON.
      
      Cc: Eric Sandeen <sandeen@redhat.com>
      Fixes: fb0a387d
      
       ("ext4: limit block allocations for indirect-block files to < 2^32")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20221121130929.32031-1-jack@suse.cz
      
      
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      7bb79477
    • Luís Henriques's avatar
      ext4: fix error code return to user-space in ext4_get_branch() · 0ffd5a40
      Luís Henriques authored
      
      
      commit 26d75a16af285a70863ba6a81f85d81e7e65da50 upstream.
      
      If a block is out of range in ext4_get_branch(), -ENOMEM will be returned
      to user-space.  Obviously, this error code isn't really useful.  This
      patch fixes it by making sure the right error code (-EFSCORRUPTED) is
      propagated to user-space.  EUCLEAN is more informative than ENOMEM.
      
      Signed-off-by: default avatarLuís Henriques <lhenriques@suse.de>
      Link: https://lore.kernel.org/r/20221109181445.17843-1-lhenriques@suse.de
      
      
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      0ffd5a40
    • Ye Bin's avatar
      ext4: init quota for 'old.inode' in 'ext4_rename' · 716c50d6
      Ye Bin authored
      
      
      commit fae381a3d79bb94aa2eb752170d47458d778b797 upstream.
      
      Syzbot found the following issue:
      ext4_parse_param: s_want_extra_isize=128
      ext4_inode_info_init: s_want_extra_isize=32
      ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828
      __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128
      __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128
      ext4_xattr_block_set: inode=ffff88823869a2c8
      ------------[ cut here ]------------
      WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980
      Modules linked in:
      RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980
      RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202
      RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000
      RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178
      RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e
      R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000
      R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000
      FS:  00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       ? ext4_xattr_set_entry+0x3b7/0x2320
       ? ext4_xattr_block_set+0x0/0x2020
       ? ext4_xattr_set_entry+0x0/0x2320
       ? ext4_xattr_check_entries+0x77/0x310
       ? ext4_xattr_ibody_set+0x23b/0x340
       ext4_xattr_move_to_block+0x594/0x720
       ext4_expand_extra_isize_ea+0x59a/0x10f0
       __ext4_expand_extra_isize+0x278/0x3f0
       __ext4_mark_inode_dirty.cold+0x347/0x410
       ext4_rename+0xed3/0x174f
       vfs_rename+0x13a7/0x2510
       do_renameat2+0x55d/0x920
       __x64_sys_rename+0x7d/0xb0
       do_syscall_64+0x3b/0xa0
       entry_SYSCALL_64_after_hwframe+0x72/0xdc
      
      As 'ext4_rename' will modify 'old.inode' ctime and mark inode dirty,
      which may trigger expand 'extra_isize' and allocate block. If inode
      didn't init quota will lead to warning.  To solve above issue, init
      'old.inode' firstly in 'ext4_rename'.
      
      Reported-by: default avatar <syzbot+98346927678ac3059c77@syzkaller.appspotmail.com>
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20221107015335.2524319-1-yebin@huaweicloud.com
      
      
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      716c50d6
    • Baokun Li's avatar
      ext4: fix bug_on in __es_tree_search caused by bad boot loader inode · 91c683d6
      Baokun Li authored
      
      
      commit 991ed014de0840c5dc405b679168924afb2952ac upstream.
      
      We got a issue as fllows:
      ==================================================================
       kernel BUG at fs/ext4/extents_status.c:203!
       invalid opcode: 0000 [#1] PREEMPT SMP
       CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349
       RIP: 0010:ext4_es_end.isra.0+0x34/0x42
       RSP: 0018:ffffc9000143b768 EFLAGS: 00010203
       RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff
       RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8
       R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0
       R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000
       FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        <TASK>
        __es_tree_search.isra.0+0x6d/0xf5
        ext4_es_cache_extent+0xfa/0x230
        ext4_cache_extents+0xd2/0x110
        ext4_find_extent+0x5d5/0x8c0
        ext4_ext_map_blocks+0x9c/0x1d30
        ext4_map_blocks+0x431/0xa50
        ext4_mpage_readpages+0x48e/0xe40
        ext4_readahead+0x47/0x50
        read_pages+0x82/0x530
        page_cache_ra_unbounded+0x199/0x2a0
        do_page_cache_ra+0x47/0x70
        page_cache_ra_order+0x242/0x400
        ondemand_readahead+0x1e8/0x4b0
        page_cache_sync_ra+0xf4/0x110
        filemap_get_pages+0x131/0xb20
        filemap_read+0xda/0x4b0
        generic_file_read_iter+0x13a/0x250
        ext4_file_read_iter+0x59/0x1d0
        vfs_read+0x28f/0x460
        ksys_read+0x73/0x160
        __x64_sys_read+0x1e/0x30
        do_syscall_64+0x35/0x80
        entry_SYSCALL_64_after_hwframe+0x63/0xcd
        </TASK>
      ==================================================================
      
      In the above issue, ioctl invokes the swap_inode_boot_loader function to
      swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and
      disordered extents, and i_nlink is set to 1. The extents check for inode in
      the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO.
      While links_count is set to 1, the extents are not initialized in
      swap_inode_boot_loader. After the ioctl command is executed successfully,
      the extents are swapped to inode<12>, in this case, run the `cat` command
      to view inode<12>. And Bug_ON is triggered due to the incorrect extents.
      
      When the boot loader inode is not initialized, its imode can be one of the
      following:
      1) the imode is a bad type, which is marked as bad_inode in ext4_iget and
         set to S_IFREG.
      2) the imode is good type but not S_IFREG.
      3) the imode is S_IFREG.
      
      The BUG_ON may be triggered by bypassing the check in cases 1 and 2.
      Therefore, when the boot loader inode is bad_inode or its imode is not
      S_IFREG, initialize the inode to avoid triggering the BUG.
      
      Signed-off-by: default avatarBaokun Li <libaokun1@huawei.com>
      Reviewed-by: default avatarJason Yan <yanaijie@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com
      
      
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      91c683d6
    • Gaosheng Cui's avatar
      ext4: fix undefined behavior in bit shift for ext4_check_flag_values · 5afdf818
      Gaosheng Cui authored
      commit 3bf678a0f9c017c9ba7c581541dbc8453452a7ae upstream.
      
      Shifting signed 32-bit value by 31 bits is undefined, so changing
      significant bit to unsigned. The UBSAN warning calltrace like below:
      
      UBSAN: shift-out-of-bounds in fs/ext4/ext4.h:591:2
      left shift of 1 by 31 places cannot be represented in type 'int'
      Call Trace:
       <TASK>
       dump_stack_lvl+0x7d/0xa5
       dump_stack+0x15/0x1b
       ubsan_epilogue+0xe/0x4e
       __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
       ext4_init_fs+0x5a/0x277
       do_one_initcall+0x76/0x430
       kernel_init_freeable+0x3b3/0x422
       kernel_init+0x24/0x1e0
       ret_from_fork+0x1f/0x30
       </TASK>
      
      Fixes: 9a4c8019
      
       ("ext4: ensure Inode flags consistency are checked at build time")
      Signed-off-by: default avatarGaosheng Cui <cuigaosheng1@huawei.com>
      Link: https://lore.kernel.org/r/20221031055833.3966222-1-cuigaosheng1@huawei.com
      
      
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      5afdf818
    • Baokun Li's avatar
      ext4: add inode table check in __ext4_get_inode_loc to aovid possible infinite loop · be961174
      Baokun Li authored
      
      
      commit eee22187b53611e173161e38f61de1c7ecbeb876 upstream.
      
      In do_writepages, if the value returned by ext4_writepages is "-ENOMEM"
      and "wbc->sync_mode == WB_SYNC_ALL", retry until the condition is not met.
      
      In __ext4_get_inode_loc, if the bh returned by sb_getblk is NULL,
      the function returns -ENOMEM.
      
      In __getblk_slow, if the return value of grow_buffers is less than 0,
      the function returns NULL.
      
      When the three processes are connected in series like the following stack,
      an infinite loop may occur:
      
      do_writepages					<--- keep retrying
       ext4_writepages
        mpage_map_and_submit_extent
         mpage_map_one_extent
          ext4_map_blocks
           ext4_ext_map_blocks
            ext4_ext_handle_unwritten_extents
             ext4_ext_convert_to_initialized
              ext4_split_extent
               ext4_split_extent_at
                __ext4_ext_dirty
                 __ext4_mark_inode_dirty
                  ext4_reserve_inode_write
                   ext4_get_inode_loc
                    __ext4_get_inode_loc		<--- return -ENOMEM
                     sb_getblk
                      __getblk_gfp
                       __getblk_slow			<--- return NULL
                        grow_buffers
                         grow_dev_page		<--- return -ENXIO
                          ret = (block < end_block) ? 1 : -ENXIO;
      
      In this issue, bg_inode_table_hi is overwritten as an incorrect value.
      As a result, `block < end_block` cannot be met in grow_dev_page.
      Therefore, __ext4_get_inode_loc always returns '-ENOMEM' and do_writepages
      keeps retrying. As a result, the writeback process is in the D state due
      to an infinite loop.
      
      Add a check on inode table block in the __ext4_get_inode_loc function by
      referring to ext4_read_inode_bitmap to avoid this infinite loop.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarBaokun Li <libaokun1@huawei.com>
      Reviewed-by: default avatarRitesh Harjani (IBM) <ritesh.list@gmail.com>
      Link: https://lore.kernel.org/r/20220817132701.3015912-3-libaokun1@huawei.com
      
      
      Signed-off-by: Theodore Ts'o's avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      be961174
    • Zack Rusin's avatar
      drm/vmwgfx: Validate the box size for the snooped cursor · b72b4b25
      Zack Rusin authored
      
      
      commit 4cf949c7fafe21e085a4ee386bb2dade9067316e upstream.
      
      Invalid userspace dma surface copies could potentially overflow
      the memcpy from the surface to the snooped image leading to crashes.
      To fix it the dimensions of the copybox have to be validated
      against the expected size of the snooped cursor.
      
      Signed-off-by: default avatarZack Rusin <zackr@vmware.com>
      Fixes: 2ac86371
      
       ("vmwgfx: Snoop DMA transfers with non-covering sizes")
      Cc: <stable@vger.kernel.org> # v3.2+
      Reviewed-by: default avatarMichael Banack <banackm@vmware.com>
      Reviewed-by: default avatarMartin Krastev <krastevm@vmware.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.org
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      b72b4b25
    • Wang Weiyang's avatar
      device_cgroup: Roll back to original exceptions after copy failure · 32319bc3
      Wang Weiyang authored
      commit e68bfbd3b3c3a0ec3cf8c230996ad8cabe90322f upstream.
      
      When add the 'a *:* rwm' entry to devcgroup A's whitelist, at first A's
      exceptions will be cleaned and A's behavior is changed to
      DEVCG_DEFAULT_ALLOW. Then parent's exceptions will be copyed to A's
      whitelist. If copy failure occurs, just return leaving A to grant
      permissions to all devices. And A may grant more permissions than
      parent.
      
      Backup A's whitelist and recover original exceptions after copy
      failure.
      
      Cc: stable@vger.kernel.org
      Fixes: 4cef7299
      
       ("device_cgroup: add proper checking when changing default behavior")
      Signed-off-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
      Reviewed-by: Aristeu Rozanski's avatarAristeu Rozanski <aris@redhat.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      32319bc3
    • Shang XiaoJing's avatar
      parisc: led: Fix potential null-ptr-deref in start_task() · 97e089a0
      Shang XiaoJing authored
      commit 41f563ab3c33698bdfc3403c7c2e6c94e73681e4 upstream.
      
      start_task() calls create_singlethread_workqueue() and not checked the
      ret value, which may return NULL. And a null-ptr-deref may happen:
      
      start_task()
          create_singlethread_workqueue() # failed, led_wq is NULL
          queue_delayed_work()
              queue_delayed_work_on()
                  __queue_delayed_work()  # warning here, but continue
                      __queue_work()      # access wq->flags, null-ptr-deref
      
      Check the ret value and return -ENOMEM if it is NULL.
      
      Fixes: 34994952
      
       ("[PARISC] Use work queue in LED/LCD driver instead of tasklet.")
      Signed-off-by: default avatarShang XiaoJing <shangxiaojing@huawei.com>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      97e089a0
    • Corentin Labbe's avatar
      crypto: n2 - add missing hash statesize · 68682420
      Corentin Labbe authored
      
      
      commit 76a4e874593543a2dff91d249c95bac728df2774 upstream.
      
      Add missing statesize to hash templates.
      This is mandatory otherwise no algorithms can be registered as the core
      requires statesize to be set.
      
      CC: stable@kernel.org # 4.3+
      Reported-by: default avatarRolf Eike Beer <eike-kernel@sf-tec.de>
      Tested-by: default avatarRolf Eike Beer <eike-kernel@sf-tec.de>
      Fixes: 0a625fd2
      
       ("crypto: n2 - Add Niagara2 crypto driver")
      Signed-off-by: Corentin Labbe's avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: Herbert Xu's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      68682420
    • Paulo Alcantara's avatar
      cifs: fix confusing debug message · 58ca304b
      Paulo Alcantara authored
      
      
      commit a85ceafd41927e41a4103d228a993df7edd8823b upstream.
      
      Since rc was initialised to -ENOMEM in cifs_get_smb_ses(), when an
      existing smb session was found, free_xid() would be called and then
      print
      
        CIFS: fs/cifs/connect.c: Existing tcp session with server found
        CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 44 with uid: 0
        CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
        CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 44) rc = -12
      
      Fix this by initialising rc to 0 and then let free_xid() print this
      instead
      
        CIFS: fs/cifs/connect.c: Existing tcp session with server found
        CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 14 with uid: 0
        CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
        CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 14) rc = 0
      
      Signed-off-by: default avatarPaulo Alcantara (SUSE) <pc@cjr.nz>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      58ca304b
    • Nick Desaulniers's avatar
      ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod · 5e73d0a4
      Nick Desaulniers authored
      commit 3220022038b9a3845eea762af85f1c5694b9f861 upstream.
      
      clang-15's ability to elide loops completely became more aggressive when
      it can deduce how a variable is being updated in a loop. Counting down
      one variable by an increment of another can be replaced by a modulo
      operation.
      
      For 64b variables on 32b ARM EABI targets, this can result in the
      compiler generating calls to __aeabi_uldivmod, which it does for a do
      while loop in float64_rem().
      
      For the kernel, we'd generally prefer that developers not open code 64b
      division via binary / operators and instead use the more explicit
      helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can
      result in linkage failures due to undefined references to
      __aeabi_uldivmod().
      
      While developers can avoid open coding divisions on 64b variables, the
      compiler doesn't know that the Linux kernel has a partial implementation
      of a compiler runtime (--rtlib) to enforce this convention.
      
      It's also undecidable for the compiler whether the code in question
      would be faster to execute the loop vs elide it and do the 64b division.
      
      While I actively avoid using the internal -mllvm command line flags, I
      think we get better code than using barrier() here, which will force
      reloads+spills in the loop for all toolchains.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/1666
      
      
      
      Reported-by: Nathan Chancellor's avatarNathan Chancellor <nathan@kernel.org>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Tested-by: Nathan Chancellor's avatarNathan Chancellor <nathan@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      5e73d0a4
    • Yang Jihong's avatar
      tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line · 9ede6665
      Yang Jihong authored
      commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream.
      
      print_trace_line may overflow seq_file buffer. If the event is not
      consumed, the while loop keeps peeking this event, causing a infinite loop.
      
      Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com
      
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: stable@vger.kernel.org
      Fixes: 088b1e42
      
       ("ftrace: pipe fixes")
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Signed-off-by: Steven Rostedt's avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      9ede6665
    • Mike Snitzer's avatar
      dm cache: set needs_check flag after aborting metadata · e0ff5daf
      Mike Snitzer authored
      commit 6b9973861cb2e96dcd0bb0f1baddc5c034207c5c upstream.
      
      Otherwise the commit that will be aborted will be associated with the
      metadata objects that will be torn down.  Must write needs_check flag
      to metadata with a reset block manager.
      
      Found through code-inspection (and compared against dm-thin.c).
      
      Cc: stable@vger.kernel.org
      Fixes: 028ae9f7
      
       ("dm cache: add fail io mode and needs_check flag")
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      e0ff5daf
    • Luo Meng's avatar
      dm cache: Fix UAF in destroy() · 8bb72075
      Luo Meng authored
      commit 6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa upstream.
      
      Dm_cache also has the same UAF problem when dm_resume()
      and dm_destroy() are concurrent.
      
      Therefore, cancelling timer again in destroy().
      
      Cc: stable@vger.kernel.org
      Fixes: c6b4fcba
      
       ("dm: add cache target")
      Signed-off-by: default avatarLuo Meng <luomeng12@huawei.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      8bb72075
    • Luo Meng's avatar
      dm thin: Fix UAF in run_timer_softirq() · 8578f071
      Luo Meng authored
      commit 88430ebcbc0ec637b710b947738839848c20feff upstream.
      
      When dm_resume() and dm_destroy() are concurrent, it will
      lead to UAF, as follows:
      
       BUG: KASAN: use-after-free in __run_timers+0x173/0x710
       Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0
      <snip>
       Call Trace:
        <IRQ>
        dump_stack_lvl+0x73/0x9f
        print_report.cold+0x132/0xaa2
        _raw_spin_lock_irqsave+0xcd/0x160
        __run_timers+0x173/0x710
        kasan_report+0xad/0x110
        __run_timers+0x173/0x710
        __asan_store8+0x9c/0x140
        __run_timers+0x173/0x710
        call_timer_fn+0x310/0x310
        pvclock_clocksource_read+0xfa/0x250
        kvm_clock_read+0x2c/0x70
        kvm_clock_get_cycles+0xd/0x20
        ktime_get+0x5c/0x110
        lapic_next_event+0x38/0x50
        clockevents_program_event+0xf1/0x1e0
        run_timer_softirq+0x49/0x90
        __do_softirq+0x16e/0x62c
        __irq_exit_rcu+0x1fa/0x270
        irq_exit_rcu+0x12/0x20
        sysvec_apic_timer_interrupt+0x8e/0xc0
      
      One of the concurrency UAF can be shown as below:
      
              use                                  free
      do_resume                           |
        __find_device_hash_cell           |
          dm_get                          |
            atomic_inc(&md->holders)      |
                                          | dm_destroy
                                          |   __dm_destroy
                                          |     if (!dm_suspended_md(md))
                                          |     atomic_read(&md->holders)
                                          |     msleep(1)
        dm_resume                         |
          __dm_resume                     |
            dm_table_resume_targets       |
              pool_resume                 |
                do_waker  #add delay work |
        dm_put                            |
          atomic_dec(&md->holders)        |
                                          |     dm_table_destroy
                                          |       pool_dtr
                                          |         __pool_dec
                                          |           __pool_destroy
                                          |             destroy_workqueue
                                          |             kfree(pool) # free pool
              time out
      __do_softirq
        run_timer_softirq # pool has already been freed
      
      This can be easily reproduced using:
        1. create thin-pool
        2. dmsetup suspend pool
        3. dmsetup resume pool
        4. dmsetup remove_all # Concurrent with 3
      
      The root cause of this UAF bug is that dm_resume() adds timer after
      dm_destroy() skips cancelling the timer because of suspend status.
      After timeout, it will call run_timer_softirq(), however pool has
      already been freed. The concurrency UAF bug will happen.
      
      Therefore, cancelling timer again in __pool_destroy().
      
      Cc: stable@vger.kernel.org
      Fixes: 991d9fa0
      
       ("dm: add thin provisioning target")
      Signed-off-by: default avatarLuo Meng <luomeng12@huawei.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      8578f071
    • Zhihao Cheng's avatar
      dm thin: Use last transaction's pmd->root when commit failed · 1c8b44bd
      Zhihao Cheng authored
      commit 7991dbff6849f67e823b7cc0c15e5a90b0549b9f upstream.
      
      Recently we found a softlock up problem in dm thin pool btree lookup
      code due to corrupted metadata:
      
       Kernel panic - not syncing: softlockup: hung tasks
       CPU: 7 PID: 2669225 Comm: kworker/u16:3
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
       Workqueue: dm-thin do_worker [dm_thin_pool]
       Call Trace:
         <IRQ>
         dump_stack+0x9c/0xd3
         panic+0x35d/0x6b9
         watchdog_timer_fn.cold+0x16/0x25
         __run_hrtimer+0xa2/0x2d0
         </IRQ>
         RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]
         __bufio_new+0x11f/0x4f0 [dm_bufio]
         new_read+0xa3/0x1e0 [dm_bufio]
         dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]
         ro_step+0x63/0x100 [dm_persistent_data]
         btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]
         dm_btree_lookup+0x16f/0x210 [dm_persistent_data]
         dm_thin_find_block+0x12c/0x210 [dm_thin_pool]
         __process_bio_read_only+0xc5/0x400 [dm_thin_pool]
         process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]
         process_one_work+0x3c5/0x730
      
      Following process may generate a broken btree mixed with fresh and
      stale btree nodes, which could get dm thin trapped in an infinite loop
      while looking up data block:
       Transaction 1: pmd->root = A, A->B->C   // One path in btree
                      pmd->root = X, X->Y->Z   // Copy-up
       Transaction 2: X,Z is updated on disk, Y write failed.
                      // Commit failed, dm thin becomes read-only.
                      process_bio_read_only
      		 dm_thin_find_block
      		  __find_block
      		   dm_btree_lookup(pmd->root)
      The pmd->root points to a broken btree, Y may contain stale node
      pointing to any block, for example X, which gets dm thin trapped into
      a dead loop while looking up Z.
      
      Fix this by setting pmd->root in __open_metadata(), so that dm thin
      will use the last transaction's pmd->root if commit failed.
      
      Fetch a reproducer in [Link].
      
      Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
      Cc: stable@vger.kernel.org
      Fixes: 991d9fa0
      
       ("dm: add thin provisioning target")
      Signed-off-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
      Acked-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      1c8b44bd
    • Mike Snitzer's avatar
      dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort · e9968ba3
      Mike Snitzer authored
      
      
      commit 352b837a5541690d4f843819028cf2b8be83d424 upstream.
      
      Same ABBA deadlock pattern fixed in commit 4b60f452ec51 ("dm thin: Fix
      ABBA deadlock between shrink_slab and dm_pool_abort_metadata") to
      DM-cache's metadata.
      
      Reported-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
      Cc: stable@vger.kernel.org
      Fixes: 028ae9f7
      
       ("dm cache: add fail io mode and needs_check flag")
      Signed-off-by: default avatarMike Snitzer <snitzer@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      e9968ba3
    • Steven Rostedt's avatar
      ktest.pl minconfig: Unset configs instead of just removing them · 425ceb84
      Steven Rostedt authored
      commit ef784eebb56425eed6e9b16e7d47e5c00dcf9c38 upstream.
      
      After a full run of a make_min_config test, I noticed there were a lot of
      CONFIGs still enabled that really should not be. Looking at them, I
      noticed they were all defined as "default y". The issue is that the test
      simple removes the config and re-runs make oldconfig, which enables it
      again because it is set to default 'y'. Instead, explicitly disable the
      config with writing "# CONFIG_FOO is not set" to the file to keep it from
      being set again.
      
      With this change, one of my box's minconfigs went from 768 configs set,
      down to 521 configs set.
      
      Link: https://lkml.kernel.org/r/20221202115936.016fce23@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Fixes: 0a05c769
      
       ("ktest: Added config_bisect test type")
      Reviewed-by: default avatarJohn 'Warthog9' Hawley (VMware) <warthog9@eaglescrag.net>
      Signed-off-by: Steven Rostedt's avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      425ceb84
    • Jason Donenfeld's avatar
      media: stv0288: use explicitly signed char · 27e8f559
      Jason Donenfeld authored
      
      
      commit 7392134428c92a4cb541bd5c8f4f5c8d2e88364d upstream.
      
      With char becoming unsigned by default, and with `char` alone being
      ambiguous and based on architecture, signed chars need to be marked
      explicitly as such. Use `s8` and `u8` types here, since that's what
      surrounding code does. This fixes:
      
      drivers/media/dvb-frontends/stv0288.c:471 stv0288_set_frontend() warn: assigning (-9) to unsigned variable 'tm'
      drivers/media/dvb-frontends/stv0288.c:471 stv0288_set_frontend() warn: we never enter this loop
      
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: linux-media@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: Jason Donenfeld's avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarUlrich Hecht <uli+cip@fpond.eu>
      27e8f559
  3. 10 Jan, 2023 17 commits