Skip to content
  1. Apr 08, 2022
    • Evgeny Novikov's avatar
      video: fbdev: w100fb: Reset global state · 1e33f197
      Evgeny Novikov authored
      [ Upstream commit 8738ddca
      
       ]
      
      w100fb_probe() did not reset the global state to its initial state. This
      can result in invocation of iounmap() even when there was not the
      appropriate successful call of ioremap(). For instance, this may be the
      case if first probe fails after two successful ioremap() while second
      probe fails when first ioremap() fails. The similar issue is with
      w100fb_remove(). The patch fixes both bugs.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      
      Signed-off-by: default avatarEvgeny Novikov <novikov@ispras.ru>
      Co-developed-by: default avatarKirill Shilimanov <kirill.shilimanov@huawei.com>
      Signed-off-by: default avatarKirill Shilimanov <kirill.shilimanov@huawei.com>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1e33f197
    • Tim Gardner's avatar
      video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow · 08dff482
      Tim Gardner authored
      [ Upstream commit 37a1a2e6
      
       ]
      
      Coverity complains of a possible buffer overflow. However,
      given the 'static' scope of nvidia_setup_i2c_bus() it looks
      like that can't happen after examiniing the call sites.
      
      CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
      1. fixed_size_dest: You might overrun the 48-character fixed-size string
        chan->adapter.name by copying name without checking the length.
      2. parameter_as_source: Note: This defect has an elevated risk because the
        source argument is a parameter of the current function.
       89        strcpy(chan->adapter.name, name);
      
      Fix this warning by using strscpy() which will silence the warning and
      prevent any future buffer overflows should the names used to identify the
      channel become much longer.
      
      Cc: Antonino Daplas <adaplas@gmail.com>
      Cc: linux-fbdev@vger.kernel.org
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      08dff482
    • Peiwei Hu's avatar
      media: ir_toy: free before error exiting · 99e3f835
      Peiwei Hu authored
      [ Upstream commit 52cdb013
      
       ]
      
      Fix leak in error path.
      
      Signed-off-by: default avatarPeiwei Hu <jlu.hpw@foxmail.com>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      99e3f835
    • Hans Verkuil's avatar
      media: staging: media: zoran: fix various V4L2 compliance errors · d658178b
      Hans Verkuil authored
      [ Upstream commit 91494182
      
       ]
      
      This fixes several issues found with 'v4l2-compliance -s':
      
      1) read()/write() is supported, but not reported in the capabilities
      2) S_STD(G_STD()) failed: setting the same standard should just return 0.
      3) G_PARM failed to set readbuffers.
      4) different field values in the format vs. what v4l2_buffer reported.
      5) zero the sequence number when starting streaming.
      6) drop VB_USERPTR: makes no sense with dma_contig streaming.
      
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d658178b
    • Corentin Labbe's avatar
      media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com · bafec1a6
      Corentin Labbe authored
      [ Upstream commit e3b86f4e
      
       ]
      
      On the case tmp_dcim=1, the index of buffer is miscalculated.
      This generate a NULL pointer dereference later.
      
      So let's fix the calcul and add a check to prevent this to reappear.
      
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bafec1a6
    • Corentin Labbe's avatar
      media: staging: media: zoran: move videodev alloc · bd016293
      Corentin Labbe authored
      [ Upstream commit 82e3a496
      
       ]
      
      Move some code out of zr36057_init() and create new functions for handling
      zr->video_dev. This permit to ease code reading and fix a zr->video_dev
      memory leak.
      
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bd016293
    • Dongliang Mu's avatar
      ntfs: add sanity check on allocation size · b230f2d9
      Dongliang Mu authored
      [ Upstream commit 714fbf26 ]
      
      ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation
      size.  It triggers one BUG in the __ntfs_malloc function.
      
      Fix this by adding sanity check on ni->attr_list_size.
      
      Link: https://lkml.kernel.org/r/20220120094914.47736-1-dzm91@hust.edu.cn
      
      
      Reported-by: default avatar <syzbot+3c765c5248797356edaa@syzkaller.appspotmail.com>
      Signed-off-by: default avatarDongliang Mu <mudongliangabcd@gmail.com>
      Acked-by: default avatarAnton Altaparmakov <anton@tuxera.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b230f2d9
    • Chao Yu's avatar
      f2fs: compress: fix to print raw data size in error path of lz4 decompression · f7e8aff0
      Chao Yu authored
      [ Upstream commit d284af43
      
       ]
      
      In lz4_decompress_pages(), if size of decompressed data is not equal to
      expected one, we should print the size rather than size of target buffer
      for decompressed data, fix it.
      
      Signed-off-by: default avatarChao Yu <chao.yu@oppo.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f7e8aff0
    • Chuck Lever's avatar
      NFSD: Fix nfsd_breaker_owns_lease() return values · d91d1e68
      Chuck Lever authored
      [ Upstream commit 50719bf3
      
       ]
      
      These have been incorrect since the function was introduced.
      
      A proper kerneldoc comment is added since this function, though
      static, is part of an external interface.
      
      Reported-by: default avatarDai Ngo <dai.ngo@oracle.com>
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d91d1e68
    • Chao Yu's avatar
      f2fs: fix to do sanity check on curseg->alloc_type · 498b7088
      Chao Yu authored
      [ Upstream commit f41ee8b9 ]
      
      As Wenqing Liu reported in bugzilla:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=215657
      
      
      
      - Overview
      UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image
      
      - Reproduce
      tested on kernel 5.17-rc4, 5.17-rc6
      
      1. mkdir test_crash
      2. cd test_crash
      3. unzip tmp2.zip
      4. mkdir mnt
      5. ./single_test.sh f2fs 2
      
      - Kernel dump
      [   46.434454] loop0: detected capacity change from 0 to 131072
      [   46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9
      [   46.738319] ================================================================================
      [   46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2
      [   46.738475] index 231 is out of range for type 'unsigned int [2]'
      [   46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1
      [   46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
      [   46.738551] Call Trace:
      [   46.738556]  <TASK>
      [   46.738563]  dump_stack_lvl+0x47/0x5c
      [   46.738581]  ubsan_epilogue+0x5/0x50
      [   46.738592]  __ubsan_handle_out_of_bounds+0x68/0x80
      [   46.738604]  f2fs_allocate_data_block+0xdff/0xe60 [f2fs]
      [   46.738819]  do_write_page+0xef/0x210 [f2fs]
      [   46.738934]  f2fs_do_write_node_page+0x3f/0x80 [f2fs]
      [   46.739038]  __write_node_page+0x2b7/0x920 [f2fs]
      [   46.739162]  f2fs_sync_node_pages+0x943/0xb00 [f2fs]
      [   46.739293]  f2fs_write_checkpoint+0x7bb/0x1030 [f2fs]
      [   46.739405]  kill_f2fs_super+0x125/0x150 [f2fs]
      [   46.739507]  deactivate_locked_super+0x60/0xc0
      [   46.739517]  deactivate_super+0x70/0xb0
      [   46.739524]  cleanup_mnt+0x11a/0x200
      [   46.739532]  __cleanup_mnt+0x16/0x20
      [   46.739538]  task_work_run+0x67/0xa0
      [   46.739547]  exit_to_user_mode_prepare+0x18c/0x1a0
      [   46.739559]  syscall_exit_to_user_mode+0x26/0x40
      [   46.739568]  do_syscall_64+0x46/0xb0
      [   46.739584]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      The root cause is we missed to do sanity check on curseg->alloc_type,
      result in out-of-bound accessing on sbi->block_count[] array, fix it.
      
      Signed-off-by: default avatarChao Yu <chao@kernel.org>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      498b7088
    • Theodore Ts'o's avatar
      ext4: don't BUG if someone dirty pages without asking ext4 first · 330d0e44
      Theodore Ts'o authored
      [ Upstream commit cc509574 ]
      
      [un]pin_user_pages_remote is dirtying pages without properly warning
      the file system in advance.  A related race was noted by Jan Kara in
      2018[1]; however, more recently instead of it being a very hard-to-hit
      race, it could be reliably triggered by process_vm_writev(2) which was
      discovered by Syzbot[2].
      
      This is technically a bug in mm/gup.c, but arguably ext4 is fragile in
      that if some other kernel subsystem dirty pages without properly
      notifying the file system using page_mkwrite(), ext4 will BUG, while
      other file systems will not BUG (although data will still be lost).
      
      So instead of crashing with a BUG, issue a warning (since there may be
      potential data loss) and just mark the page as clean to avoid
      unprivileged denial of service attacks until the problem can be
      properly fixed.  More discussion and background can be found in the
      thread starting at [2].
      
      [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz
      [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
      
      
      
      Reported-by: default avatar <syzbot+d59332e2db681cf18f0318a06e994ebbb529a8db@syzkaller.appspotmail.com>
      Reported-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Link: https://lore.kernel.org/r/YiDS9wVfq4mM2jGK@mit.edu
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      330d0e44
    • Ritesh Harjani's avatar
      ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit · cd6d7195
      Ritesh Harjani authored
      [ Upstream commit bfdc502a
      
       ]
      
      In case of flex_bg feature (which is by default enabled), extents for
      any given inode might span across blocks from two different block group.
      ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the
      starting block group, but it fails to read it again when the extent length
      boundary overflows to another block group. Then in this below loop it
      accesses memory beyond the block group bitmap buffer_head and results
      into a data abort.
      
      	for (i = 0; i < clen; i++)
      		if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state)
      			already++;
      
      This patch adds this functionality for checking block group boundary in
      ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different
      block group.
      
      w/o this patch, I was easily able to hit a data access abort using Power platform.
      
      <...>
      [   74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters
      [   74.533214] EXT4-fs (loop3): shut down requested (2)
      [   74.536705] Aborting journal on device loop3-8.
      [   74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000
      [   74.703727] Faulting instruction address: 0xc0000000007bffb8
      cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060]
          pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0
          lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0
          sp: c000000015db7300
         msr: 800000000280b033
         dar: c00000005e980000
       dsisr: 40000000
        current = 0xc000000027af6880
        paca    = 0xc00000003ffd5200   irqmask: 0x03   irq_happened: 0x01
          pid   = 5167, comm = mount
      <...>
      enter ? for help
      [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410
      [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000
      [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0
      [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0
      [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0
      [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10
      [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350
      [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40
      [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100
      [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70
      [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550
      [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0
      [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250
      
      Signed-off-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/2609bc8f66fc15870616ee416a18a3d392a209c4.1644992609.git.riteshh@linux.ibm.com
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd6d7195
    • Ritesh Harjani's avatar
      ext4: correct cluster len and clusters changed accounting in ext4_mb_mark_bb · 69d2421b
      Ritesh Harjani authored
      [ Upstream commit a5c0e2fd
      
       ]
      
      ext4_mb_mark_bb() currently wrongly calculates cluster len (clen) and
      flex_group->free_clusters. This patch fixes that.
      
      Identified based on code review of ext4_mb_mark_bb() function.
      
      Signed-off-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/a0b035d536bafa88110b74456853774b64c8ac40.1644992609.git.riteshh@linux.ibm.com
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      69d2421b
    • Waiman Long's avatar
      locking/lockdep: Iterate lock_classes directly when reading lockdep files · ecd384c4
      Waiman Long authored
      [ Upstream commit fb7275ac
      
       ]
      
      When dumping lock_classes information via /proc/lockdep, we can't take
      the lockdep lock as the lock hold time is indeterminate. Iterating
      over all_lock_classes without holding lock can be dangerous as there
      is a slight chance that it may branch off to other lists leading to
      infinite loop or even access invalid memory if changes are made to
      all_lock_classes list in parallel.
      
      To avoid this problem, iteration of lock classes is now done directly
      on the lock_classes array itself. The lock_classes_in_use bitmap is
      checked to see if the lock class is being used. To avoid iterating
      the full array all the times, a new max_lock_class_idx value is added
      to track the maximum lock_class index that is currently being used.
      
      We can theoretically take the lockdep lock for iterating all_lock_classes
      when other lockdep files (lockdep_stats and lock_stat) are accessed as
      the lock hold time will be shorter for them. For consistency, they are
      also modified to iterate the lock_classes array directly.
      
      Signed-off-by: default avatarWaiman Long <longman@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20220211035526.1329503-2-longman@redhat.com
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ecd384c4
    • Minghao Chi's avatar
      spi: tegra20: Use of_device_get_match_data() · 3ad817f1
      Minghao Chi authored
      [ Upstream commit c9839acf
      
       ]
      
      Use of_device_get_match_data() to simplify the code.
      
      Reported-by: default avatarZeal Robot <zealci@zte.com.cn>
      Signed-off-by: default avatarMinghao Chi <chi.minghao@zte.com.cn>
      Link: https://lore.kernel.org/r/20220315023138.2118293-1-chi.minghao@zte.com.cn
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3ad817f1
    • Chris Leech's avatar
      nvme-tcp: lockdep: annotate in-kernel sockets · 1c200c8b
      Chris Leech authored
      [ Upstream commit 841aee4d ]
      
      Put NVMe/TCP sockets in their own class to avoid some lockdep warnings.
      Sockets created by nvme-tcp are not exposed to user-space, and will not
      trigger certain code paths that the general socket API exposes.
      
      Lockdep complains about a circular dependency between the socket and
      filesystem locks, because setsockopt can trigger a page fault with a
      socket lock held, but nvme-tcp sends requests on the socket while file
      system locks are held.
      
        ======================================================
        WARNING: possible circular locking dependency detected
        5.15.0-rc3 #1 Not tainted
        ------------------------------------------------------
        fio/1496 is trying to acquire lock:
        (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendpage+0x23/0x80
      
        but task is already holding lock:
        (&xfs_dir_ilock_class/5){+.+.}-{3:3}, at: xfs_ilock+0xcf/0x290 [xfs]
      
        which lock already depends on the new lock.
      
        other info that might help us debug this:
      
        chain exists of:
         sk_lock-AF_INET --> sb_internal --> &xfs_dir_ilock_class/5
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&xfs_dir_ilock_class/5);
                                      lock(sb_internal);
                                      lock(&xfs_dir_ilock_class/5);
         lock(sk_lock-AF_INET);
      
        *** DEADLOCK ***
      
        6 locks held by fio/1496:
         #0: (sb_writers#13){.+.+}-{0:0}, at: path_openat+0x9fc/0xa20
         #1: (&inode->i_sb->s_type->i_mutex_dir_key){++++}-{3:3}, at: path_openat+0x296/0xa20
         #2: (sb_internal){.+.+}-{0:0}, at: xfs_trans_alloc_icreate+0x41/0xd0 [xfs]
         #3: (&xfs_dir_ilock_class/5){+.+.}-{3:3}, at: xfs_ilock+0xcf/0x290 [xfs]
         #4: (hctx->srcu){....}-{0:0}, at: hctx_lock+0x51/0xd0
         #5: (&queue->send_mutex){+.+.}-{3:3}, at: nvme_tcp_queue_rq+0x33e/0x380 [nvme_tcp]
      
      This annotation lets lockdep analyze nvme-tcp controlled sockets
      independently of what the user-space sockets API does.
      
      Link: https://lore.kernel.org/linux-nvme/CAHj4cs9MDYLJ+q+2_GXUK9HxFizv2pxUryUR0toX974M040z7g@mail.gmail.com/
      
      
      
      Signed-off-by: default avatarChris Leech <cleech@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c200c8b
    • John David Anglin's avatar
      parisc: Fix handling off probe non-access faults · 7e4967e9
      John David Anglin authored
      [ Upstream commit e00b0a2a
      
       ]
      
      Currently, the parisc kernel does not fully support non-access TLB
      fault handling for probe instructions. In the fast path, we set the
      target register to zero if it is not a shadowed register. The slow
      path is not implemented, so we call do_page_fault. The architecture
      indicates that non-access faults should not cause a page fault from
      disk.
      
      This change adds to code to provide non-access fault support for
      probe instructions. It also modifies the handling of faults on
      userspace so that if the address lies in a valid VMA and the access
      type matches that for the VMA, the probe target register is set to
      one. Otherwise, the target register is set to zero.
      
      This was done to make probe instructions more useful for userspace.
      Probe instructions are not very useful if they set the target register
      to zero whenever a page is not present in memory. Nominally, the
      purpose of the probe instruction is determine whether read or write
      access to a given address is allowed.
      
      This fixes a problem in function pointer comparison noticed in the
      glibc testsuite (stdio-common/tst-vfprintf-user-type). The same
      problem is likely in glibc (_dl_lookup_address).
      
      V2 adds flush and lpa instruction support to handle_nadtlb_fault.
      
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7e4967e9
    • Dmitry Baryshkov's avatar
      PM: core: keep irq flags in device_pm_check_callbacks() · ede1ef1a
      Dmitry Baryshkov authored
      [ Upstream commit 524bb1da
      
       ]
      
      The function device_pm_check_callbacks() can be called under the spin
      lock (in the reported case it happens from genpd_add_device() ->
      dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.
      
      However this function uncoditionally uses spin_lock_irq() /
      spin_unlock_irq(), thus not preserving the CPU flags. Use the
      irqsave/irqrestore instead.
      
      The backtrace for the reference:
      [    2.752010] ------------[ cut here ]------------
      [    2.756769] raw_local_irq_restore() called with IRQs enabled
      [    2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50
      [    2.772338] Modules linked in:
      [    2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S                5.17.0-rc6-00384-ge330d0d82eff-dirty #684
      [    2.781384] Freeing initrd memory: 46024K
      [    2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [    2.785841] pc : warn_bogus_irq_restore+0x34/0x50
      [    2.785844] lr : warn_bogus_irq_restore+0x34/0x50
      [    2.785846] sp : ffff80000805b7d0
      [    2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002
      [    2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800
      [    2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00
      [    2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff
      [    2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7
      [    2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8
      [    2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0
      [    2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0
      [    2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
      [    2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000
      [    2.889774] Call trace:
      [    2.892290]  warn_bogus_irq_restore+0x34/0x50
      [    2.896770]  _raw_spin_unlock_irqrestore+0x94/0xa0
      [    2.901690]  genpd_unlock_spin+0x20/0x30
      [    2.905724]  genpd_add_device+0x100/0x2d0
      [    2.909850]  __genpd_dev_pm_attach+0xa8/0x23c
      [    2.914329]  genpd_dev_pm_attach_by_id+0xc4/0x190
      [    2.919167]  genpd_dev_pm_attach_by_name+0x3c/0xd0
      [    2.924086]  dev_pm_domain_attach_by_name+0x24/0x30
      [    2.929102]  psci_dt_attach_cpu+0x24/0x90
      [    2.933230]  psci_cpuidle_probe+0x2d4/0x46c
      [    2.937534]  platform_probe+0x68/0xe0
      [    2.941304]  really_probe.part.0+0x9c/0x2fc
      [    2.945605]  __driver_probe_device+0x98/0x144
      [    2.950085]  driver_probe_device+0x44/0x15c
      [    2.954385]  __device_attach_driver+0xb8/0x120
      [    2.958950]  bus_for_each_drv+0x78/0xd0
      [    2.962896]  __device_attach+0xd8/0x180
      [    2.966843]  device_initial_probe+0x14/0x20
      [    2.971144]  bus_probe_device+0x9c/0xa4
      [    2.975092]  device_add+0x380/0x88c
      [    2.978679]  platform_device_add+0x114/0x234
      [    2.983067]  platform_device_register_full+0x100/0x190
      [    2.988344]  psci_idle_init+0x6c/0xb0
      [    2.992113]  do_one_initcall+0x74/0x3a0
      [    2.996060]  kernel_init_freeable+0x2fc/0x384
      [    3.000543]  kernel_init+0x28/0x130
      [    3.004132]  ret_from_fork+0x10/0x20
      [    3.007817] irq event stamp: 319826
      [    3.011404] hardirqs last  enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84
      [    3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c
      [    3.028458] softirqs last  enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588
      [    3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174
      [    3.045607] ---[ end trace 0000000000000000 ]---
      
      Signed-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ede1ef1a
    • Darren Hart's avatar
      ACPI/APEI: Limit printable size of BERT table data · 227718c8
      Darren Hart authored
      [ Upstream commit 3f8dec11
      
       ]
      
      Platforms with large BERT table data can trigger soft lockup errors
      while attempting to print the entire BERT table data to the console at
      boot:
      
        watchdog: BUG: soft lockup - CPU#160 stuck for 23s! [swapper/0:1]
      
      Observed on Ampere Altra systems with a single BERT record of ~250KB.
      
      The original bert driver appears to have assumed relatively small table
      data. Since it is impractical to reassemble large table data from
      interwoven console messages, and the table data is available in
      
        /sys/firmware/acpi/tables/data/BERT
      
      limit the size for tables printed to the console to 1024 (for no reason
      other than it seemed like a good place to kick off the discussion, would
      appreciate feedback from existing users in terms of what size would
      maintain their current usage model).
      
      Alternatively, we could make printing a CONFIG option, use the
      bert_disable boot arg (or something similar), or use a debug log level.
      However, all those solutions require extra steps or change the existing
      behavior for small table data. Limiting the size preserves existing
      behavior on existing platforms with small table data, and eliminates the
      soft lockups for platforms with large table data, while still making it
      available.
      
      Signed-off-by: default avatarDarren Hart <darren@os.amperecomputing.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      227718c8
    • Paolo Valente's avatar
      Revert "Revert "block, bfq: honor already-setup queue merges"" · cc051f49
      Paolo Valente authored
      [ Upstream commit 15729ff8 ]
      
      A crash [1] happened to be triggered in conjunction with commit
      2d52c58b ("block, bfq: honor already-setup queue merges"). The
      latter was then reverted by commit ebc69e89 ("Revert "block, bfq:
      honor already-setup queue merges""). Yet, the reverted commit was not
      the one introducing the bug. In fact, it actually triggered a UAF
      introduced by a different commit, and now fixed by commit d29bd414
      ("block, bfq: reset last_bfqq_created on group change").
      
      So, there is no point in keeping commit 2d52c58b ("block, bfq:
      honor already-setup queue merges") out. This commit restores it.
      
      [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503
      
      
      
      Reported-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      Signed-off-by: default avatarPaolo Valente <paolo.valente@linaro.org>
      Link: https://lore.kernel.org/r/20211125181510.15004-1-paolo.valente@linaro.org
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cc051f49
    • Paul Menzel's avatar
      lib/raid6/test/Makefile: Use $(pound) instead of \# for Make 4.3 · 1b69302b
      Paul Menzel authored
      [ Upstream commit 633174a7 ]
      
      Buidling raid6test on Ubuntu 21.10 (ppc64le) with GNU Make 4.3 shows the
      errors below:
      
          $ cd lib/raid6/test/
          $ make
          <stdin>:1:1: error: stray ‘\’ in program
          <stdin>:1:2: error: stray ‘#’ in program
          <stdin>:1:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ \
              before ‘<’ token
      
          [...]
      
      The errors come from the HAS_ALTIVEC test, which fails, and the POWER
      optimized versions are not built. That’s also reason nobody noticed on the
      other architectures.
      
      GNU Make 4.3 does not remove the backslash anymore. From the 4.3 release
      announcment:
      
      > * WARNING: Backward-incompatibility!
      >   Number signs (#) appearing inside a macro reference or function invocation
      >   no longer introduce comments and should not be escaped with backslashes:
      >   thus a call such as:
      >     foo := $(shell echo '#')
      >   is legal.  Previously the number sign needed to be escaped, for example:
      >     foo := $(shell echo '\#')
      >   Now this latter will resolve to "\#".  If you want to write makefiles
      >   portable to both versions, assign the number sign to a variable:
      >     H := \#
      >     foo := $(shell echo '$H')
      >   This was claimed to be fixed in 3.81, but wasn't, for some reason.
      >   To detect this change search for 'nocomment' in the .FEATURES variable.
      
      So, do the same as commit 9564a8cf ("Kbuild: fix # escaping in .cmd
      files for future Make") and commit 929bef46 ("bpf: Use $(pound) instead
      of \# in Makefiles") and define and use a $(pound) variable.
      
      Reference for the change in make:
      https://git.savannah.gnu.org/cgit/make.git/commit/?id=c6966b323811c37acedff05b57
      
      
      
      Cc: Matt Brown <matthew.brown.dev@gmail.com>
      Signed-off-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1b69302b
    • Rafael J. Wysocki's avatar
      ACPICA: Avoid walking the ACPI Namespace if it is not there · 1b87ce6a
      Rafael J. Wysocki authored
      [ Upstream commit 0c999231 ]
      
      ACPICA commit b1c3656ef4950098e530be68d4b589584f06cddc
      
      Prevent acpi_ns_walk_namespace() from crashing when called with
      start_node equal to ACPI_ROOT_OBJECT if the Namespace has not been
      instantiated yet and acpi_gbl_root_node is NULL.
      
      For instance, this can happen if the kernel is run with "acpi=off"
      in the command line.
      
      Link: https://github.com/acpica/acpica/commit/b1c3656ef4950098e530be68d4b589584f06cddc
      Link: https://lore.kernel.org/linux-acpi/CAJZ5v0hJWW_vZ3wwajE7xT38aWjY7cZyvqMJpXHzUL98-SiCVQ@mail.gmail.com/
      
      
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1b87ce6a
    • Zhang Wensheng's avatar
      bfq: fix use-after-free in bfq_dispatch_request · df6e00b1
      Zhang Wensheng authored
      [ Upstream commit ab552fcb
      
       ]
      
      KASAN reports a use-after-free report when doing normal scsi-mq test
      
      [69832.239032] ==================================================================
      [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0
      [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155
      [69832.244656]
      [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8
      [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      [69832.249069] Workqueue: kblockd blk_mq_run_work_fn
      [69832.250022] Call Trace:
      [69832.250541]  dump_stack+0x9b/0xce
      [69832.251232]  ? bfq_dispatch_request+0x1045/0x44b0
      [69832.252243]  print_address_description.constprop.6+0x3e/0x60
      [69832.253381]  ? __cpuidle_text_end+0x5/0x5
      [69832.254211]  ? vprintk_func+0x6b/0x120
      [69832.254994]  ? bfq_dispatch_request+0x1045/0x44b0
      [69832.255952]  ? bfq_dispatch_request+0x1045/0x44b0
      [69832.256914]  kasan_report.cold.9+0x22/0x3a
      [69832.257753]  ? bfq_dispatch_request+0x1045/0x44b0
      [69832.258755]  check_memory_region+0x1c1/0x1e0
      [69832.260248]  bfq_dispatch_request+0x1045/0x44b0
      [69832.261181]  ? bfq_bfqq_expire+0x2440/0x2440
      [69832.262032]  ? blk_mq_delay_run_hw_queues+0xf9/0x170
      [69832.263022]  __blk_mq_do_dispatch_sched+0x52f/0x830
      [69832.264011]  ? blk_mq_sched_request_inserted+0x100/0x100
      [69832.265101]  __blk_mq_sched_dispatch_requests+0x398/0x4f0
      [69832.266206]  ? blk_mq_do_dispatch_ctx+0x570/0x570
      [69832.267147]  ? __switch_to+0x5f4/0xee0
      [69832.267898]  blk_mq_sched_dispatch_requests+0xdf/0x140
      [69832.268946]  __blk_mq_run_hw_queue+0xc0/0x270
      [69832.269840]  blk_mq_run_work_fn+0x51/0x60
      [69832.278170]  process_one_work+0x6d4/0xfe0
      [69832.278984]  worker_thread+0x91/0xc80
      [69832.279726]  ? __kthread_parkme+0xb0/0x110
      [69832.280554]  ? process_one_work+0xfe0/0xfe0
      [69832.281414]  kthread+0x32d/0x3f0
      [69832.282082]  ? kthread_park+0x170/0x170
      [69832.282849]  ret_from_fork+0x1f/0x30
      [69832.283573]
      [69832.283886] Allocated by task 7725:
      [69832.284599]  kasan_save_stack+0x19/0x40
      [69832.285385]  __kasan_kmalloc.constprop.2+0xc1/0xd0
      [69832.286350]  kmem_cache_alloc_node+0x13f/0x460
      [69832.287237]  bfq_get_queue+0x3d4/0x1140
      [69832.287993]  bfq_get_bfqq_handle_split+0x103/0x510
      [69832.289015]  bfq_init_rq+0x337/0x2d50
      [69832.289749]  bfq_insert_requests+0x304/0x4e10
      [69832.290634]  blk_mq_sched_insert_requests+0x13e/0x390
      [69832.291629]  blk_mq_flush_plug_list+0x4b4/0x760
      [69832.292538]  blk_flush_plug_list+0x2c5/0x480
      [69832.293392]  io_schedule_prepare+0xb2/0xd0
      [69832.294209]  io_schedule_timeout+0x13/0x80
      [69832.295014]  wait_for_common_io.constprop.1+0x13c/0x270
      [69832.296137]  submit_bio_wait+0x103/0x1a0
      [69832.296932]  blkdev_issue_discard+0xe6/0x160
      [69832.297794]  blk_ioctl_discard+0x219/0x290
      [69832.298614]  blkdev_common_ioctl+0x50a/0x1750
      [69832.304715]  blkdev_ioctl+0x470/0x600
      [69832.305474]  block_ioctl+0xde/0x120
      [69832.306232]  vfs_ioctl+0x6c/0xc0
      [69832.306877]  __se_sys_ioctl+0x90/0xa0
      [69832.307629]  do_syscall_64+0x2d/0x40
      [69832.308362]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [69832.309382]
      [69832.309701] Freed by task 155:
      [69832.310328]  kasan_save_stack+0x19/0x40
      [69832.311121]  kasan_set_track+0x1c/0x30
      [69832.311868]  kasan_set_free_info+0x1b/0x30
      [69832.312699]  __kasan_slab_free+0x111/0x160
      [69832.313524]  kmem_cache_free+0x94/0x460
      [69832.314367]  bfq_put_queue+0x582/0x940
      [69832.315112]  __bfq_bfqd_reset_in_service+0x166/0x1d0
      [69832.317275]  bfq_bfqq_expire+0xb27/0x2440
      [69832.318084]  bfq_dispatch_request+0x697/0x44b0
      [69832.318991]  __blk_mq_do_dispatch_sched+0x52f/0x830
      [69832.319984]  __blk_mq_sched_dispatch_requests+0x398/0x4f0
      [69832.321087]  blk_mq_sched_dispatch_requests+0xdf/0x140
      [69832.322225]  __blk_mq_run_hw_queue+0xc0/0x270
      [69832.323114]  blk_mq_run_work_fn+0x51/0x60
      [69832.323942]  process_one_work+0x6d4/0xfe0
      [69832.324772]  worker_thread+0x91/0xc80
      [69832.325518]  kthread+0x32d/0x3f0
      [69832.326205]  ret_from_fork+0x1f/0x30
      [69832.326932]
      [69832.338297] The buggy address belongs to the object at ffff88802622b968
      [69832.338297]  which belongs to the cache bfq_queue of size 512
      [69832.340766] The buggy address is located 288 bytes inside of
      [69832.340766]  512-byte region [ffff88802622b968, ffff88802622bb68)
      [69832.343091] The buggy address belongs to the page:
      [69832.344097] page:ffffea0000988a00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802622a528 pfn:0x26228
      [69832.346214] head:ffffea0000988a00 order:2 compound_mapcount:0 compound_pincount:0
      [69832.347719] flags: 0x1fffff80010200(slab|head)
      [69832.348625] raw: 001fffff80010200 ffffea0000dbac08 ffff888017a57650 ffff8880179fe840
      [69832.354972] raw: ffff88802622a528 0000000000120008 00000001ffffffff 0000000000000000
      [69832.356547] page dumped because: kasan: bad access detected
      [69832.357652]
      [69832.357970] Memory state around the buggy address:
      [69832.358926]  ffff88802622b980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [69832.360358]  ffff88802622ba00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [69832.361810] >ffff88802622ba80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [69832.363273]                       ^
      [69832.363975]  ffff88802622bb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
      [69832.375960]  ffff88802622bb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [69832.377405] ==================================================================
      
      In bfq_dispatch_requestfunction, it may have function call:
      
      bfq_dispatch_request
      	__bfq_dispatch_request
      		bfq_select_queue
      			bfq_bfqq_expire
      				__bfq_bfqd_reset_in_service
      					bfq_put_queue
      						kmem_cache_free
      In this function call, in_serv_queue has beed expired and meet the
      conditions to free. In the function bfq_dispatch_request, the address
      of in_serv_queue pointing to has been released. For getting the value
      of idle_timer_disabled, it will get flags value from the address which
      in_serv_queue pointing to, then the problem of use-after-free happens;
      
      Fix the problem by check in_serv_queue == bfqd->in_service_queue, to
      get the value of idle_timer_disabled if in_serve_queue is equel to
      bfqd->in_service_queue. If the space of in_serv_queue pointing has
      been released, this judge will aviod use-after-free problem.
      And if in_serv_queue may be expired or finished, the idle_timer_disabled
      will be false which would not give effects to bfq_update_dispatch_stats.
      
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarZhang Wensheng <zhangwensheng5@huawei.com>
      Link: https://lore.kernel.org/r/20220303070334.3020168-1-zhangwensheng5@huawei.com
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df6e00b1
    • Akira Kawata's avatar
      fs/binfmt_elf: Fix AT_PHDR for unusual ELF files · dd85ed4a
      Akira Kawata authored
      [ Upstream commit 0da1d500 ]
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197921
      
      
      
      As pointed out in the discussion of buglink, we cannot calculate AT_PHDR
      as the sum of load_addr and exec->e_phoff.
      
      : The AT_PHDR of ELF auxiliary vectors should point to the memory address
      : of program header. But binfmt_elf.c calculates this address as follows:
      :
      : NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
      :
      : which is wrong since e_phoff is the file offset of program header and
      : load_addr is the memory base address from PT_LOAD entry.
      :
      : The ld.so uses AT_PHDR as the memory address of program header. In normal
      : case, since the e_phoff is usually 64 and in the first PT_LOAD region, it
      : is the correct program header address.
      :
      : But if the address of program header isn't equal to the first PT_LOAD
      : address + e_phoff (e.g.  Put the program header in other non-consecutive
      : PT_LOAD region), ld.so will try to read program header from wrong address
      : then crash or use incorrect program header.
      
      This is because exec->e_phoff
      is the offset of PHDRs in the file and the address of PHDRs in the
      memory may differ from it. This patch fixes the bug by calculating the
      address of program headers from PT_LOADs directly.
      
      Signed-off-by: default avatarAkira Kawata <akirakawata1@gmail.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20220127124014.338760-2-akirakawata1@gmail.com
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dd85ed4a
    • Souptick Joarder (HPE)'s avatar
      irqchip/nvic: Release nvic_base upon failure · 9fc899ce
      Souptick Joarder (HPE) authored
      [ Upstream commit e414c25e
      
       ]
      
      smatch warning was reported as below ->
      
      smatch warnings:
      drivers/irqchip/irq-nvic.c:131 nvic_of_init()
      warn: 'nvic_base' not released on lines: 97.
      
      Release nvic_base upon failure.
      
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSouptick Joarder (HPE) <jrdr.linux@gmail.com>
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20220218163303.33344-1-jrdr.linux@gmail.com
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9fc899ce
    • Marc Zyngier's avatar
      irqchip/qcom-pdc: Fix broken locking · 4bbd910d
      Marc Zyngier authored
      [ Upstream commit a6aca2f4
      
       ]
      
      pdc_enable_intr() serves as a primitive to qcom_pdc_gic_{en,dis}able,
      and has a raw spinlock for mutual exclusion, which is uses with
      interruptible primitives.
      
      This means that this critical section can itself be interrupted.
      Should the interrupt also be a PDC interrupt, and the endpoint driver
      perform an irq_disable() on that interrupt, we end-up in a deadlock.
      
      Fix this by using the irqsave/irqrestore variants of the locking
      primitives.
      
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Reviewed-by: default avatarMaulik Shah <quic_mkshah@quicinc.com>
      Link: https://lore.kernel.org/r/20220224101226.88373-5-maz@kernel.org
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4bbd910d
    • Casey Schaufler's avatar
      Fix incorrect type in assignment of ipv6 port for audit · f038185b
      Casey Schaufler authored
      [ Upstream commit a5cd1ab7
      
       ]
      
      Remove inappropriate use of ntohs() and assign the
      port value directly.
      
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f038185b
    • Chaitanya Kulkarni's avatar
      loop: use sysfs_emit() in the sysfs xxx show() · 012c5720
      Chaitanya Kulkarni authored
      [ Upstream commit b27824d3
      
       ]
      
      sprintf does not know the PAGE_SIZE maximum of the temporary buffer
      used for outputting sysfs content and it's possible to overrun the
      PAGE_SIZE buffer length.
      
      Use a generic sysfs_emit function that knows the size of the
      temporary buffer and ensures that no overrun is done for offset
      attribute in
      loop_attr_[offset|sizelimit|autoclear|partscan|dio]_show() callbacks.
      
      Signed-off-by: default avatarChaitanya Kulkarni <kch@nvidia.com>
      Reviewed-by: default avatarHimanshu Madhani <himanshu.madhani@oracle.com>
      Link: https://lore.kernel.org/r/20220215213310.7264-2-kch@nvidia.com
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      012c5720
    • Richard Haines's avatar
      selinux: allow FIOCLEX and FIONCLEX with policy capability · 448857f5
      Richard Haines authored
      [ Upstream commit 65881e1d
      
       ]
      
      These ioctls are equivalent to fcntl(fd, F_SETFD, flags), which SELinux
      always allows too.  Furthermore, a failed FIOCLEX could result in a file
      descriptor being leaked to a process that should not have access to it.
      
      As this patch removes access controls, a policy capability needs to be
      enabled in policy to always allow these ioctls.
      
      Based-on-patch-by: default avatarDemi Marie Obenour <demiobenour@gmail.com>
      Signed-off-by: default avatarRichard Haines <richard_c_haines@btinternet.com>
      [PM: subject line tweak]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      448857f5
    • Christian Göttsche's avatar
      selinux: use correct type for context length · 4b9b60b5
      Christian Göttsche authored
      [ Upstream commit b97df7c0
      
       ]
      
      security_sid_to_context() expects a pointer to an u32 as the address
      where to store the length of the computed context.
      
      Reported by sparse:
      
          security/selinux/xfrm.c:359:39: warning: incorrect type in arg 4
                                          (different signedness)
          security/selinux/xfrm.c:359:39:    expected unsigned int
                                             [usertype] *scontext_len
          security/selinux/xfrm.c:359:39:    got int *
      
      Signed-off-by: default avatarChristian Göttsche <cgzones@googlemail.com>
      [PM: wrapped commit description]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4b9b60b5
    • Yu Kuai's avatar
      block, bfq: don't move oom_bfqq · 7507ead1
      Yu Kuai authored
      [ Upstream commit 8410f709
      
       ]
      
      Our test report a UAF:
      
      [ 2073.019181] ==================================================================
      [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168
      [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584
      [ 2073.019192]
      [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5
      [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      [ 2073.019200] Call trace:
      [ 2073.019203]  dump_backtrace+0x0/0x310
      [ 2073.019206]  show_stack+0x28/0x38
      [ 2073.019210]  dump_stack+0xec/0x15c
      [ 2073.019216]  print_address_description+0x68/0x2d0
      [ 2073.019220]  kasan_report+0x238/0x2f0
      [ 2073.019224]  __asan_store8+0x88/0xb0
      [ 2073.019229]  __bfq_put_async_bfqq+0xa0/0x168
      [ 2073.019233]  bfq_put_async_queues+0xbc/0x208
      [ 2073.019236]  bfq_pd_offline+0x178/0x238
      [ 2073.019240]  blkcg_deactivate_policy+0x1f0/0x420
      [ 2073.019244]  bfq_exit_queue+0x128/0x178
      [ 2073.019249]  blk_mq_exit_sched+0x12c/0x160
      [ 2073.019252]  elevator_exit+0xc8/0xd0
      [ 2073.019256]  blk_exit_queue+0x50/0x88
      [ 2073.019259]  blk_cleanup_queue+0x228/0x3d8
      [ 2073.019267]  null_del_dev+0xfc/0x1e0 [null_blk]
      [ 2073.019274]  null_exit+0x90/0x114 [null_blk]
      [ 2073.019278]  __arm64_sys_delete_module+0x358/0x5a0
      [ 2073.019282]  el0_svc_common+0xc8/0x320
      [ 2073.019287]  el0_svc_handler+0xf8/0x160
      [ 2073.019290]  el0_svc+0x10/0x218
      [ 2073.019291]
      [ 2073.019294] Allocated by task 14163:
      [ 2073.019301]  kasan_kmalloc+0xe0/0x190
      [ 2073.019305]  kmem_cache_alloc_node_trace+0x1cc/0x418
      [ 2073.019308]  bfq_pd_alloc+0x54/0x118
      [ 2073.019313]  blkcg_activate_policy+0x250/0x460
      [ 2073.019317]  bfq_create_group_hierarchy+0x38/0x110
      [ 2073.019321]  bfq_init_queue+0x6d0/0x948
      [ 2073.019325]  blk_mq_init_sched+0x1d8/0x390
      [ 2073.019330]  elevator_switch_mq+0x88/0x170
      [ 2073.019334]  elevator_switch+0x140/0x270
      [ 2073.019338]  elv_iosched_store+0x1a4/0x2a0
      [ 2073.019342]  queue_attr_store+0x90/0xe0
      [ 2073.019348]  sysfs_kf_write+0xa8/0xe8
      [ 2073.019351]  kernfs_fop_write+0x1f8/0x378
      [ 2073.019359]  __vfs_write+0xe0/0x360
      [ 2073.019363]  vfs_write+0xf0/0x270
      [ 2073.019367]  ksys_write+0xdc/0x1b8
      [ 2073.019371]  __arm64_sys_write+0x50/0x60
      [ 2073.019375]  el0_svc_common+0xc8/0x320
      [ 2073.019380]  el0_svc_handler+0xf8/0x160
      [ 2073.019383]  el0_svc+0x10/0x218
      [ 2073.019385]
      [ 2073.019387] Freed by task 72584:
      [ 2073.019391]  __kasan_slab_free+0x120/0x228
      [ 2073.019394]  kasan_slab_free+0x10/0x18
      [ 2073.019397]  kfree+0x94/0x368
      [ 2073.019400]  bfqg_put+0x64/0xb0
      [ 2073.019404]  bfqg_and_blkg_put+0x90/0xb0
      [ 2073.019408]  bfq_put_queue+0x220/0x228
      [ 2073.019413]  __bfq_put_async_bfqq+0x98/0x168
      [ 2073.019416]  bfq_put_async_queues+0xbc/0x208
      [ 2073.019420]  bfq_pd_offline+0x178/0x238
      [ 2073.019424]  blkcg_deactivate_policy+0x1f0/0x420
      [ 2073.019429]  bfq_exit_queue+0x128/0x178
      [ 2073.019433]  blk_mq_exit_sched+0x12c/0x160
      [ 2073.019437]  elevator_exit+0xc8/0xd0
      [ 2073.019440]  blk_exit_queue+0x50/0x88
      [ 2073.019443]  blk_cleanup_queue+0x228/0x3d8
      [ 2073.019451]  null_del_dev+0xfc/0x1e0 [null_blk]
      [ 2073.019459]  null_exit+0x90/0x114 [null_blk]
      [ 2073.019462]  __arm64_sys_delete_module+0x358/0x5a0
      [ 2073.019467]  el0_svc_common+0xc8/0x320
      [ 2073.019471]  el0_svc_handler+0xf8/0x160
      [ 2073.019474]  el0_svc+0x10/0x218
      [ 2073.019475]
      [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00
       which belongs to the cache kmalloc-1024 of size 1024
      [ 2073.019484] The buggy address is located 552 bytes inside of
       1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)
      [ 2073.019486] The buggy address belongs to the page:
      [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0
      [ 2073.020123] flags: 0x7ffff0000008100(slab|head)
      [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00
      [ 2073.020409] raw: 0000000000000000 00000000001c001c 00000001ffffffff 0000000000000000
      [ 2073.020411] page dumped because: kasan: bad access detected
      [ 2073.020412]
      [ 2073.020414] Memory state around the buggy address:
      [ 2073.020420]  ffff8000ccf64000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [ 2073.020424]  ffff8000ccf64080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [ 2073.020428] >ffff8000ccf64100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [ 2073.020430]                                   ^
      [ 2073.020434]  ffff8000ccf64180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [ 2073.020438]  ffff8000ccf64200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [ 2073.020439] ==================================================================
      
      The same problem exist in mainline as well.
      
      This is because oom_bfqq is moved to a non-root group, thus root_group
      is freed earlier.
      
      Thus fix the problem by don't move oom_bfqq.
      
      Signed-off-by: default avatarYu Kuai <yukuai3@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Acked-by: default avatarPaolo Valente <paolo.valente@linaro.org>
      Link: https://lore.kernel.org/r/20220129015924.3958918-4-yukuai3@huawei.com
      
      
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7507ead1
    • Marc Zyngier's avatar
      pinctrl: npcm: Fix broken references to chip->parent_device · 79b16d00
      Marc Zyngier authored
      [ Upstream commit f7e53e22
      
       ]
      
      The npcm driver has a bunch of references to the irq_chip parent_device
      field, but never sets it.
      
      Fix it by fishing that reference from somewhere else, but it is
      obvious that these debug statements were never used. Also remove
      an unused field in a local data structure.
      
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
      Acked-by: default avatarBartosz Golaszewski <brgl@bgdev.pl>
      Link: https://lore.kernel.org/r/20220201120310.878267-11-maz@kernel.org
      
      
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      79b16d00
    • Kees Cook's avatar
      gcc-plugins/stackleak: Exactly match strings instead of prefixes · 9d1d8e5e
      Kees Cook authored
      [ Upstream commit 27e9faf4
      
       ]
      
      Since STRING_CST may not be NUL terminated, strncmp() was used for check
      for equality. However, this may lead to mismatches for longer section
      names where the start matches the tested-for string. Test for exact
      equality by checking for the presences of NUL termination.
      
      Cc: Alexander Popov <alex.popov@linux.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9d1d8e5e
    • Dave Stevenson's avatar
      regulator: rpi-panel: Handle I2C errors/timing to the Atmel · b0f2f89d
      Dave Stevenson authored
      [ Upstream commit 5665eee7
      
       ]
      
      The Atmel is doing some things in the I2C ISR, during which
      period it will not respond to further commands. This is
      particularly true of the POWERON command.
      
      Increase delays appropriately, and retry should I2C errors be
      reported.
      
      Signed-off-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
      Signed-off-by: default avatarDetlev Casanova <detlev.casanova@collabora.com>
      Link: https://lore.kernel.org/r/20220124220129.158891-3-detlev.casanova@collabora.com
      
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b0f2f89d
    • Casey Schaufler's avatar
      LSM: general protection fault in legacy_parse_param · 2784604c
      Casey Schaufler authored
      [ Upstream commit ecff3057
      
       ]
      
      The usual LSM hook "bail on fail" scheme doesn't work for cases where
      a security module may return an error code indicating that it does not
      recognize an input.  In this particular case Smack sees a mount option
      that it recognizes, and returns 0. A call to a BPF hook follows, which
      returns -ENOPARAM, which confuses the caller because Smack has processed
      its data.
      
      The SELinux hook incorrectly returns 1 on success. There was a time
      when this was correct, however the current expectation is that it
      return 0 on success. This is repaired.
      
      Reported-by: default avatar <syzbot+d1e3b1d92d25abf97943@syzkaller.appspotmail.com>
      Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: default avatarJames Morris <jamorris@linux.microsoft.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2784604c
    • Linus Torvalds's avatar
      fs: fix fd table size alignment properly · e600b597
      Linus Torvalds authored
      [ Upstream commit d888c83f ]
      
      Jason Donenfeld reports that my commit 1c24a186 ("fs: fd tables have
      to be multiples of BITS_PER_LONG") doesn't work, and the reason is an
      embarrassing brown-paper-bag bug.
      
      Yes, we want to align the number of fds to BITS_PER_LONG, and yes, the
      reason they might not be aligned is because the incoming 'max_fd'
      argument might not be aligned.
      
      But aligining the argument - while simple - will cause a "infinitely
      big" maxfd (eg NR_OPEN_MAX) to just overflow to zero.  Which most
      definitely isn't what we want either.
      
      The obvious fix was always just to do the alignment last, but I had
      moved it earlier just to make the patch smaller and the code look
      simpler.  Duh.  It certainly made _me_ look simple.
      
      Fixes: 1c24a186
      
       ("fs: fd tables have to be multiples of BITS_PER_LONG")
      Reported-and-tested-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Fedor Pchelkin <aissur0002@gmail.com>
      Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
      Cc: Christian Brauner <brauner@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e600b597
    • Dan Carpenter's avatar
      lib/test: use after free in register_test_dev_kmod() · 327f07e3
      Dan Carpenter authored
      [ Upstream commit dc0ce6cc ]
      
      The "test_dev" pointer is freed but then returned to the caller.
      
      Fixes: d9c6a72d
      
       ("kmod: add test driver to stress test the module loader")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      327f07e3
    • Linus Torvalds's avatar
      fs: fd tables have to be multiples of BITS_PER_LONG · 00d2b9fe
      Linus Torvalds authored
      [ Upstream commit 1c24a186 ]
      
      This has always been the rule: fdtables have several bitmaps in them,
      and as a result they have to be sized properly for bitmaps.  We walk
      those bitmaps in chunks of 'unsigned long' in serveral cases, but even
      when we don't, we use the regular kernel bitops that are defined to work
      on arrays of 'unsigned long', not on some byte array.
      
      Now, the distinction between arrays of bytes and 'unsigned long'
      normally only really ends up being noticeable on big-endian systems, but
      Fedor Pchelkin and Alexey Khoroshilov reported that copy_fd_bitmaps()
      could be called with an argument that wasn't even a multiple of
      BITS_PER_BYTE.  And then it fails to do the proper copy even on
      little-endian machines.
      
      The bug wasn't in copy_fd_bitmap(), but in sane_fdtable_size(), which
      didn't actually sanitize the fdtable size sufficiently, and never made
      sure it had the proper BITS_PER_LONG alignment.
      
      That's partly because the alignment historically came not from having to
      explicitly align things, but simply from previous fdtable sizes, and
      from count_open_files(), which counts the file descriptors by walking
      them one 'unsigned long' word at a time and thus naturally ends up doing
      sizing in the proper 'chunks of unsigned long'.
      
      But with the introduction of close_range(), we now have an external
      source of "this is how many files we want to have", and so
      sane_fdtable_size() needs to do a better job.
      
      This also adds that explicit alignment to alloc_fdtable(), although
      there it is mainly just for documentation at a source code level.  The
      arithmetic we do there to pick a reasonable fdtable size already aligns
      the result sufficiently.
      
      In fact,clang notices that the added ALIGN() in that function doesn't
      actually do anything, and does not generate any extra code for it.
      
      It turns out that gcc ends up confusing itself by combining a previous
      constant-sized shift operation with the variable-sized shift operations
      in roundup_pow_of_two().  And probably due to that doesn't notice that
      the ALIGN() is a no-op.  But that's a (tiny) gcc misfeature that doesn't
      matter.  Having the explicit alignment makes sense, and would actually
      matter on a 128-bit architecture if we ever go there.
      
      This also adds big comments above both functions about how fdtable sizes
      have to have that BITS_PER_LONG alignment.
      
      Fixes: 60997c3d
      
       ("close_range: add CLOSE_RANGE_UNSHARE")
      Reported-by: default avatarFedor Pchelkin <aissur0002@gmail.com>
      Reported-by: default avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Link: https://lore.kernel.org/all/20220326114009.1690-1-aissur0002@gmail.com/
      
      
      Tested-and-acked-by: default avatarChristian Brauner <brauner@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      00d2b9fe
    • Xiaomeng Tong's avatar
      net: dsa: bcm_sf2_cfp: fix an incorrect NULL check on list iterator · 1752fcd4
      Xiaomeng Tong authored
      [ Upstream commit 6da69b1d ]
      
      The bug is here:
      	return rule;
      
      The list iterator value 'rule' will *always* be set and non-NULL
      by list_for_each_entry(), so it is incorrect to assume that the
      iterator value will be NULL if the list is empty or no element
      is found.
      
      To fix the bug, return 'rule' when found, otherwise return NULL.
      
      Fixes: ae7a5aff
      
       ("net: dsa: bcm_sf2: Keep copy of inserted rules")
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarXiaomeng Tong <xiam0nd.tong@gmail.com>
      Link: https://lore.kernel.org/r/20220328032431.22538-1-xiam0nd.tong@gmail.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1752fcd4
    • Trond Myklebust's avatar
      NFSv4/pNFS: Fix another issue with a list iterator pointing to the head · edb91a47
      Trond Myklebust authored
      [ Upstream commit 7c9d845f
      
       ]
      
      In nfs4_callback_devicenotify(), if we don't find a matching entry for
      the deviceid, we're left with a pointer to 'struct nfs_server' that
      actually points to the list of super blocks associated with our struct
      nfs_client.
      Furthermore, even if we have a valid pointer, nothing pins the super
      block, and so the struct nfs_server could end up getting freed while
      we're using it.
      
      Since all we want is a pointer to the struct pnfs_layoutdriver_type,
      let's skip all the iteration over super blocks, and just use APIs to
      find the layout driver directly.
      
      Reported-by: default avatarXiaomeng Tong <xiam0nd.tong@gmail.com>
      Fixes: 1be5683b
      
       ("pnfs: CB_NOTIFY_DEVICEID")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      edb91a47