1. 25 8月, 2019 36 次提交
    • F
      Btrfs: fix deadlock between fiemap and transaction commits · f833deae
      Filipe Manana 提交于
      [ Upstream commit a6d155d2e363f26290ffd50591169cb96c2a609e ]
      
      The fiemap handler locks a file range that can have unflushed delalloc,
      and after locking the range, it tries to attach to a running transaction.
      If the running transaction started its commit, that is, it is in state
      TRANS_STATE_COMMIT_START, and either the filesystem was mounted with the
      flushoncommit option or the transaction is creating a snapshot for the
      subvolume that contains the file that fiemap is operating on, we end up
      deadlocking. This happens because fiemap is blocked on the transaction,
      waiting for it to complete, and the transaction is waiting for the flushed
      dealloc to complete, which requires locking the file range that the fiemap
      task already locked. The following stack traces serve as an example of
      when this deadlock happens:
      
        (...)
        [404571.515510] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
        [404571.515956] Call Trace:
        [404571.516360]  ? __schedule+0x3ae/0x7b0
        [404571.516730]  schedule+0x3a/0xb0
        [404571.517104]  lock_extent_bits+0x1ec/0x2a0 [btrfs]
        [404571.517465]  ? remove_wait_queue+0x60/0x60
        [404571.517832]  btrfs_finish_ordered_io+0x292/0x800 [btrfs]
        [404571.518202]  normal_work_helper+0xea/0x530 [btrfs]
        [404571.518566]  process_one_work+0x21e/0x5c0
        [404571.518990]  worker_thread+0x4f/0x3b0
        [404571.519413]  ? process_one_work+0x5c0/0x5c0
        [404571.519829]  kthread+0x103/0x140
        [404571.520191]  ? kthread_create_worker_on_cpu+0x70/0x70
        [404571.520565]  ret_from_fork+0x3a/0x50
        [404571.520915] kworker/u8:6    D    0 31651      2 0x80004000
        [404571.521290] Workqueue: btrfs-flush_delalloc btrfs_flush_delalloc_helper [btrfs]
        (...)
        [404571.537000] fsstress        D    0 13117  13115 0x00004000
        [404571.537263] Call Trace:
        [404571.537524]  ? __schedule+0x3ae/0x7b0
        [404571.537788]  schedule+0x3a/0xb0
        [404571.538066]  wait_current_trans+0xc8/0x100 [btrfs]
        [404571.538349]  ? remove_wait_queue+0x60/0x60
        [404571.538680]  start_transaction+0x33c/0x500 [btrfs]
        [404571.539076]  btrfs_check_shared+0xa3/0x1f0 [btrfs]
        [404571.539513]  ? extent_fiemap+0x2ce/0x650 [btrfs]
        [404571.539866]  extent_fiemap+0x2ce/0x650 [btrfs]
        [404571.540170]  do_vfs_ioctl+0x526/0x6f0
        [404571.540436]  ksys_ioctl+0x70/0x80
        [404571.540734]  __x64_sys_ioctl+0x16/0x20
        [404571.540997]  do_syscall_64+0x60/0x1d0
        [404571.541279]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
        (...)
        [404571.543729] btrfs           D    0 14210  14208 0x00004000
        [404571.544023] Call Trace:
        [404571.544275]  ? __schedule+0x3ae/0x7b0
        [404571.544526]  ? wait_for_completion+0x112/0x1a0
        [404571.544795]  schedule+0x3a/0xb0
        [404571.545064]  schedule_timeout+0x1ff/0x390
        [404571.545351]  ? lock_acquire+0xa6/0x190
        [404571.545638]  ? wait_for_completion+0x49/0x1a0
        [404571.545890]  ? wait_for_completion+0x112/0x1a0
        [404571.546228]  wait_for_completion+0x131/0x1a0
        [404571.546503]  ? wake_up_q+0x70/0x70
        [404571.546775]  btrfs_wait_ordered_extents+0x27c/0x400 [btrfs]
        [404571.547159]  btrfs_commit_transaction+0x3b0/0xae0 [btrfs]
        [404571.547449]  ? btrfs_mksubvol+0x4a4/0x640 [btrfs]
        [404571.547703]  ? remove_wait_queue+0x60/0x60
        [404571.547969]  btrfs_mksubvol+0x605/0x640 [btrfs]
        [404571.548226]  ? __sb_start_write+0xd4/0x1c0
        [404571.548512]  ? mnt_want_write_file+0x24/0x50
        [404571.548789]  btrfs_ioctl_snap_create_transid+0x169/0x1a0 [btrfs]
        [404571.549048]  btrfs_ioctl_snap_create_v2+0x11d/0x170 [btrfs]
        [404571.549307]  btrfs_ioctl+0x133f/0x3150 [btrfs]
        [404571.549549]  ? mem_cgroup_charge_statistics+0x4c/0xd0
        [404571.549792]  ? mem_cgroup_commit_charge+0x84/0x4b0
        [404571.550064]  ? __handle_mm_fault+0xe3e/0x11f0
        [404571.550306]  ? do_raw_spin_unlock+0x49/0xc0
        [404571.550608]  ? _raw_spin_unlock+0x24/0x30
        [404571.550976]  ? __handle_mm_fault+0xedf/0x11f0
        [404571.551319]  ? do_vfs_ioctl+0xa2/0x6f0
        [404571.551659]  ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
        [404571.552087]  do_vfs_ioctl+0xa2/0x6f0
        [404571.552355]  ksys_ioctl+0x70/0x80
        [404571.552621]  __x64_sys_ioctl+0x16/0x20
        [404571.552864]  do_syscall_64+0x60/0x1d0
        [404571.553104]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
        (...)
      
      If we were joining the transaction instead of attaching to it, we would
      not risk a deadlock because a join only blocks if the transaction is in a
      state greater then or equals to TRANS_STATE_COMMIT_DOING, and the delalloc
      flush performed by a transaction is done before it reaches that state,
      when it is in the state TRANS_STATE_COMMIT_START. However a transaction
      join is intended for use cases where we do modify the filesystem, and
      fiemap only needs to peek at delayed references from the current
      transaction in order to determine if extents are shared, and, besides
      that, when there is no current transaction or when it blocks to wait for
      a current committing transaction to complete, it creates a new transaction
      without reserving any space. Such unnecessary transactions, besides doing
      unnecessary IO, can cause transaction aborts (-ENOSPC) and unnecessary
      rotation of the precious backup roots.
      
      So fix this by adding a new transaction join variant, named join_nostart,
      which behaves like the regular join, but it does not create a transaction
      when none currently exists or after waiting for a committing transaction
      to complete.
      
      Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
      Signed-off-by: NFilipe Manana <fdmanana@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f833deae
    • Y
      drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m · 202aa96f
      YueHaibing 提交于
      [ Upstream commit f4cc743a98136df3c3763050a0e8223b52d9a960 ]
      
      If DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
      build fails:
      
      drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
      lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Fixes: dbb58bfd ("drm/bridge: Fix lvds-encoder since the panel_bridge rework.")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190729071216.27488-1-yuehaibing@huawei.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      202aa96f
    • K
      libata: zpodd: Fix small read overflow in zpodd_get_mech_type() · f69fd790
      Kees Cook 提交于
      [ Upstream commit 71d6c505b4d9e6f76586350450e785e3d452b346 ]
      
      Jeffrin reported a KASAN issue:
      
        BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70
        Read of size 16 at addr ffffffff91f41f80 by task scsi_eh_1/149
        ...
        The buggy address belongs to the variable:
          cdb.48319+0x0/0x40
      
      Much like commit 18c9a99b ("libata: zpodd: small read overflow in
      eject_tray()"), this fixes a cdb[] buffer length, this time in
      zpodd_get_mech_type():
      
      We read from the cdb[] buffer in ata_exec_internal_sg(). It has to be
      ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.
      Reported-by: NJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Fixes: afe75951 ("libata: identify and init ZPODD devices")
      Link: https://lore.kernel.org/lkml/201907181423.E808958@keescook/Tested-by: NJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f69fd790
    • N
      perf header: Fix use of unitialized value warning · 0a19fff5
      Numfor Mbiziwo-Tiapo 提交于
      [ Upstream commit 20f9781f491360e7459c589705a2e4b1f136bee9 ]
      
      When building our local version of perf with MSAN (Memory Sanitizer) and
      running the perf record command, MSAN throws a use of uninitialized
      value warning in "tools/perf/util/util.c:333:6".
      
      This warning stems from the "buf" variable being passed into "write".
      It originated as the variable "ev" with the type union perf_event*
      defined in the "perf_event__synthesize_attr" function in
      "tools/perf/util/header.c".
      
      In the "perf_event__synthesize_attr" function they allocate space with a malloc
      call using ev, then go on to only assign some of the member variables before
      passing "ev" on as a parameter to the "process" function therefore "ev"
      contains uninitialized memory. Changing the malloc call to zalloc to initialize
      all the members of "ev" which gets rid of the warning.
      
      To reproduce this warning, build perf by running:
      make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
       -fsanitize-memory-track-origins"
      
      (Additionally, llvm might have to be installed and clang might have to
      be specified as the compiler - export CC=/usr/bin/clang)
      
      then running:
      tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate\
       -i - --stdio
      
      Please see the cover letter for why false positive warnings may be
      generated.
      Signed-off-by: NNumfor Mbiziwo-Tiapo <nums@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Drayton <mbd@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190724234500.253358-2-nums@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0a19fff5
    • V
      perf header: Fix divide by zero error if f_header.attr_size==0 · ab5aa579
      Vince Weaver 提交于
      [ Upstream commit 7622236ceb167aa3857395f9bdaf871442aa467e ]
      
      So I have been having lots of trouble with hand-crafted perf.data files
      causing segfaults and the like, so I have started fuzzing the perf tool.
      
      First issue found:
      
      If f_header.attr_size is 0 in the perf.data file, then perf will crash
      with a divide-by-zero error.
      
      Committer note:
      
      Added a pr_err() to tell the user why the command failed.
      Signed-off-by: NVince Weaver <vincent.weaver@maine.edu>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1907231100440.14532@macbook-airSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ab5aa579
    • L
      irqchip/irq-imx-gpcv2: Forward irq type to parent · a5e40452
      Lucas Stach 提交于
      [ Upstream commit 9a446ef08f3bfc0c3deb9c6be840af2528ef8cf8 ]
      
      The GPCv2 is a stacked IRQ controller below the ARM GIC. It doesn't
      care about the IRQ type itself, but needs to forward the type to the
      parent IRQ controller, so this one can be configured correctly.
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a5e40452
    • N
      irqchip/gic-v3-its: Free unused vpt_page when alloc vpe table fail · dcb73180
      Nianyao Tang 提交于
      [ Upstream commit 34f8eb92ca053cbba2887bb7e4dbf2b2cd6eb733 ]
      
      In its_vpe_init, when its_alloc_vpe_table fails, we should free
      vpt_page allocated just before, instead of vpe->vpt_page.
      Let's fix it.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NNianyao Tang <tangnianyao@huawei.com>
      Signed-off-by: NShaokun Zhang <zhangshaokun@hisilicon.com>
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dcb73180
    • Y
      xen/pciback: remove set but not used variable 'old_state' · e72e6ba1
      YueHaibing 提交于
      [ Upstream commit 09e088a4903bd0dd911b4f1732b250130cdaffed ]
      
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      drivers/xen/xen-pciback/conf_space_capability.c: In function pm_ctrl_write:
      drivers/xen/xen-pciback/conf_space_capability.c:119:25: warning:
       variable old_state set but not used [-Wunused-but-set-variable]
      
      It is never used so can be removed.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e72e6ba1
    • G
      clk: renesas: cpg-mssr: Fix reset control race condition · ca5b26a8
      Geert Uytterhoeven 提交于
      [ Upstream commit e1f1ae8002e4b06addc52443fcd975bbf554ae92 ]
      
      The module reset code in the Renesas CPG/MSSR driver uses
      read-modify-write (RMW) operations to write to a Software Reset Register
      (SRCRn), and simple writes to write to a Software Reset Clearing
      Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
      User's Manuals.
      
      However, this may cause a race condition when two devices are reset in
      parallel: if the reset for device A completes in the middle of the RMW
      operation for device B, device A may be reset again, causing subtle
      failures (e.g. i2c timeouts):
      
      	thread A			thread B
      	--------			--------
      
      	val = SRCRn
      	val |= bit A
      	SRCRn = val
      
      	delay
      
      					val = SRCRn (bit A is set)
      
      	SRSTCLRn = bit A
      	(bit A in SRCRn is cleared)
      
      					val |= bit B
      					SRCRn = val (bit A and B are set)
      
      This can be reproduced on e.g. Salvator-XS using:
      
          $ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done &
          $ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done &
      
          i2c-rcar e6510000.i2c: error -110 : 40000002
          i2c-rcar e66d8000.i2c: error -110 : 40000002
      
      According to the R-Car Gen3 Hardware Manual Errata for Rev.
      0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware
      User's Manual, writes to SRCRn do not require read-modify-write cycles.
      
      Note that the R-Car Gen2 Hardware User's Manual has not been updated
      yet, and still says a read-modify-write sequence is required.  According
      to the hardware team, the reset hardware block is the same on both R-Car
      Gen2 and Gen3, though.
      
      Hence fix the issue by replacing the read-modify-write operations on
      SRCRn by simple writes.
      Reported-by: NYao Lihua <Lihua.Yao@desay-svautomotive.com>
      Fixes: 6197aa65 ("clk: renesas: cpg-mssr: Add support for reset control")
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: NLinh Phung <linh.phung.jy@renesas.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca5b26a8
    • C
      clk: sprd: Select REGMAP_MMIO to avoid compile errors · af2ed1a0
      Chunyan Zhang 提交于
      [ Upstream commit c9a67cbb5189e966c70451562b2ca4c3876ab546 ]
      
      Make REGMAP_MMIO selected to avoid undefined reference to regmap symbols.
      
      Fixes: d41f59fd ("clk: sprd: Add common infrastructure")
      Signed-off-by: NChunyan Zhang <chunyan.zhang@unisoc.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      af2ed1a0
    • C
      clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1 · 3e5f29b6
      Codrin Ciubotariu 提交于
      [ Upstream commit 1573eebeaa8055777eb753f9b4d1cbe653380c38 ]
      
      In clk_generated_determine_rate(), if the divisor is greater than
      GENERATED_MAX_DIV + 1, then the wrong best_rate will be returned.
      If clk_generated_set_rate() will be called later with this wrong
      rate, it will return -EINVAL, so the generated clock won't change
      its value. Do no let the divisor be greater than GENERATED_MAX_DIV + 1.
      
      Fixes: 8c7aa632 ("clk: at91: clk-generated: remove useless divisor loop")
      Signed-off-by: NCodrin Ciubotariu <codrin.ciubotariu@microchip.com>
      Acked-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3e5f29b6
    • V
      riscv: Make __fstate_clean() work correctly. · 28fd9b37
      Vincent Chen 提交于
      commit 69703eb9a8ae28a46cd5bce7d69ceeef6273a104 upstream.
      
      Make the __fstate_clean() function correctly set the
      state of sstatus.FS in pt_regs to SR_FS_CLEAN.
      
      Fixes: 7db91e57 ("RISC-V: Task implementation")
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NVincent Chen <vincent.chen@sifive.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      [paul.walmsley@sifive.com: expanded "Fixes" commit ID]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28fd9b37
    • F
      netfilter: ebtables: also count base chain policies · cef0e9eb
      Florian Westphal 提交于
      commit 3b48300d5cc7c7bed63fddb006c4046549ed4aec upstream.
      
      ebtables doesn't include the base chain policies in the rule count,
      so we need to add them manually when we call into the x_tables core
      to allocate space for the comapt offset table.
      
      This lead syzbot to trigger:
      WARNING: CPU: 1 PID: 9012 at net/netfilter/x_tables.c:649
      xt_compat_add_offset.cold+0x11/0x36 net/netfilter/x_tables.c:649
      
      Reported-by: syzbot+276ddebab3382bbf72db@syzkaller.appspotmail.com
      Fixes: 2035f3ff8eaa ("netfilter: ebtables: compat: un-break 32bit setsockopt when no rules are present")
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cef0e9eb
    • D
      net: usb: pegasus: fix improper read if get_registers() fail · 07d92cae
      Denis Kirjanov 提交于
      commit 224c04973db1125fcebefffd86115f99f50f8277 upstream.
      
      get_registers() may fail with -ENOMEM and in this
      case we can read a garbage from the status variable tmp.
      
      Reported-by: syzbot+3499a83b2d062ae409d4@syzkaller.appspotmail.com
      Signed-off-by: NDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07d92cae
    • O
      Input: iforce - add sanity checks · f13de3d6
      Oliver Neukum 提交于
      commit 849f5ae3a513c550cad741c68dd3d7eb2bcc2a2c upstream.
      
      The endpoint type should also be checked before a device
      is accepted.
      
      Reported-by: syzbot+5efc10c005014d061a74@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f13de3d6
    • O
      Input: kbtab - sanity check for endpoint type · 08b3af00
      Oliver Neukum 提交于
      commit c88090dfc84254fa149174eb3e6a8458de1912c4 upstream.
      
      The driver should check whether the endpoint it uses has the correct
      type.
      
      Reported-by: syzbot+c7df50363aaff50aa363@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08b3af00
    • H
      HID: hiddev: do cleanup in failure of opening a device · b545dc9d
      Hillf Danton 提交于
      commit 6d4472d7bec39917b54e4e80245784ea5d60ce49 upstream.
      
      Undo what we did for opening before releasing the memory slice.
      Reported-by: Nsyzbot <syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NHillf Danton <hdanton@sina.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b545dc9d
    • H
      HID: hiddev: avoid opening a disconnected device · 0aab1a46
      Hillf Danton 提交于
      commit 9c09b214f30e3c11f9b0b03f89442df03643794d upstream.
      
      syzbot found the following crash on:
      
      HEAD commit:    e96407b4 usb-fuzzer: main usb gadget fuzzer driver
      git tree:       https://github.com/google/kasan.git usb-fuzzer
      console output: https://syzkaller.appspot.com/x/log.txt?x=147ac20c600000
      kernel config:  https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
      dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e
      compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
      
      ==================================================================
      BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50
      kernel/locking/lockdep.c:3753
      Read of size 8 at addr ffff8881cf591a08 by task syz-executor.1/26260
      
      CPU: 1 PID: 26260 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #24
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x6a/0x32c mm/kasan/report.c:351
        __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
        kasan_report+0xe/0x12 mm/kasan/common.c:612
        __lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753
        lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
        __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
        _raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159
        hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221
        __fput+0x2d7/0x840 fs/file_table.c:280
        task_work_run+0x13f/0x1c0 kernel/task_work.c:113
        exit_task_work include/linux/task_work.h:22 [inline]
        do_exit+0x8ef/0x2c50 kernel/exit.c:878
        do_group_exit+0x125/0x340 kernel/exit.c:982
        get_signal+0x466/0x23d0 kernel/signal.c:2728
        do_signal+0x88/0x14e0 arch/x86/kernel/signal.c:815
        exit_to_usermode_loop+0x1a2/0x200 arch/x86/entry/common.c:159
        prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
        syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
        do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x459829
      Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
      48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
      ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f75b2a6ccf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
      RAX: fffffffffffffe00 RBX: 000000000075c078 RCX: 0000000000459829
      RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000000075c078
      RBP: 000000000075c070 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000075c07c
      R13: 00007ffcdfe1023f R14: 00007f75b2a6d9c0 R15: 000000000075c07c
      
      Allocated by task 104:
        save_stack+0x1b/0x80 mm/kasan/common.c:69
        set_track mm/kasan/common.c:77 [inline]
        __kasan_kmalloc mm/kasan/common.c:487 [inline]
        __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460
        kmalloc include/linux/slab.h:552 [inline]
        kzalloc include/linux/slab.h:748 [inline]
        hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900
        hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
        hid_hw_start drivers/hid/hid-core.c:1981 [inline]
        hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
        appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
        hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
        usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
        generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
        usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
        hub_port_connect drivers/usb/core/hub.c:5098 [inline]
        hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
        port_event drivers/usb/core/hub.c:5359 [inline]
        hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
        process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
        worker_thread+0x96/0xe20 kernel/workqueue.c:2415
        kthread+0x318/0x420 kernel/kthread.c:255
        ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      Freed by task 104:
        save_stack+0x1b/0x80 mm/kasan/common.c:69
        set_track mm/kasan/common.c:77 [inline]
        __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449
        slab_free_hook mm/slub.c:1423 [inline]
        slab_free_freelist_hook mm/slub.c:1470 [inline]
        slab_free mm/slub.c:3012 [inline]
        kfree+0xe4/0x2f0 mm/slub.c:3953
        hiddev_connect.cold+0x45/0x5c drivers/hid/usbhid/hiddev.c:914
        hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882
        hid_hw_start drivers/hid/hid-core.c:1981 [inline]
        hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972
        appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308
        hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365
        usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
        generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
        usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
        really_probe+0x281/0x650 drivers/base/dd.c:548
        driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
        __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
        bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
        __device_attach+0x217/0x360 drivers/base/dd.c:882
        bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
        device_add+0xae6/0x16f0 drivers/base/core.c:2114
        usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
        hub_port_connect drivers/usb/core/hub.c:5098 [inline]
        hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
        port_event drivers/usb/core/hub.c:5359 [inline]
        hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
        process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
        worker_thread+0x96/0xe20 kernel/workqueue.c:2415
        kthread+0x318/0x420 kernel/kthread.c:255
        ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      
      The buggy address belongs to the object at ffff8881cf591900
        which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 264 bytes inside of
        512-byte region [ffff8881cf591900, ffff8881cf591b00)
      The buggy address belongs to the page:
      page:ffffea00073d6400 refcount:1 mapcount:0 mapping:ffff8881da002500
      index:0x0 compound_mapcount: 0
      flags: 0x200000000010200(slab|head)
      raw: 0200000000010200 0000000000000000 0000000100000001 ffff8881da002500
      raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
        ffff8881cf591900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8881cf591980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      > ffff8881cf591a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                             ^
        ffff8881cf591a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff8881cf591b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      
      In order to avoid opening a disconnected device, we need to check exist
      again after acquiring the existance lock, and bail out if necessary.
      Reported-by: Nsyzbot <syzbot+62a1e04fd3ec2abf099e@syzkaller.appspotmail.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NHillf Danton <hdanton@sina.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0aab1a46
    • O
      HID: holtek: test for sanity of intfdata · 537d957b
      Oliver Neukum 提交于
      commit 01ec0a5f19c8c82960a07f6c7410fc9e01d7fb51 upstream.
      
      The ioctl handler uses the intfdata of a second interface,
      which may not be present in a broken or malicious device, hence
      the intfdata needs to be checked for NULL.
      
      [jkosina@suse.cz: fix newly added spurious space]
      Reported-by: syzbot+965152643a75a56737be@syzkaller.appspotmail.com
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      537d957b
    • H
      ALSA: hda - Let all conexant codec enter D3 when rebooting · 9585f444
      Hui Wang 提交于
      commit 401714d9534aad8c24196b32600da683116bbe09 upstream.
      
      We have 3 new lenovo laptops which have conexant codec 0x14f11f86,
      these 3 laptops also have the noise issue when rebooting, after
      letting the codec enter D3 before rebooting or poweroff, the noise
      disappers.
      
      Instead of adding a new ID again in the reboot_notify(), let us make
      this function apply to all conexant codec. In theory make codec enter
      D3 before rebooting or poweroff is harmless, and I tested this change
      on a couple of other Lenovo laptops which have different conexant
      codecs, there is no side effect so far.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9585f444
    • H
      ALSA: hda - Add a generic reboot_notify · e58ba88d
      Hui Wang 提交于
      commit 871b9066027702e6e6589da0e1edd3b7dede7205 upstream.
      
      Make codec enter D3 before rebooting or poweroff can fix the noise
      issue on some laptops. And in theory it is harmless for all codecs
      to enter D3 before rebooting or poweroff, let us add a generic
      reboot_notify, then realtek and conexant drivers can call this
      function.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NHui Wang <hui.wang@canonical.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e58ba88d
    • W
      ALSA: hda - Fix a memory leak bug · 6c4a536c
      Wenwen Wang 提交于
      commit cfef67f016e4c00a2f423256fc678a6967a9fc09 upstream.
      
      In snd_hda_parse_generic_codec(), 'spec' is allocated through kzalloc().
      Then, the pin widgets in 'codec' are parsed. However, if the parsing
      process fails, 'spec' is not deallocated, leading to a memory leak.
      
      To fix the above issue, free 'spec' before returning the error.
      
      Fixes: 352f7f91 ("ALSA: hda - Merge Realtek parser code to generic parser")
      Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c4a536c
    • T
      ALSA: hda - Apply workaround for another AMD chip 1022:1487 · 1bf5f827
      Takashi Iwai 提交于
      commit de768ce45466f3009809719eb7b1f6f5277d9373 upstream.
      
      MSI MPG X570 board is with another AMD HD-audio controller (PCI ID
      1022:1487) and it requires the same workaround applied for X370, etc
      (PCI ID 1022:1457).
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1bf5f827
    • H
      ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit · 58b9f19e
      Hui Peng 提交于
      commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream.
      
      The `uac_mixer_unit_descriptor` shown as below is read from the
      device side. In `parse_audio_mixer_unit`, `baSourceID` field is
      accessed from index 0 to `bNrInPins` - 1, the current implementation
      assumes that descriptor is always valid (the length  of descriptor
      is no shorter than 5 + `bNrInPins`). If a descriptor read from
      the device side is invalid, it may trigger out-of-bound memory
      access.
      
      ```
      struct uac_mixer_unit_descriptor {
      	__u8 bLength;
      	__u8 bDescriptorType;
      	__u8 bDescriptorSubtype;
      	__u8 bUnitID;
      	__u8 bNrInPins;
      	__u8 baSourceID[];
      }
      ```
      
      This patch fixes the bug by add a sanity check on the length of
      the descriptor.
      Reported-by: NHui Peng <benquike@gmail.com>
      Reported-by: NMathias Payer <mathias.payer@nebelwelt.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHui Peng <benquike@gmail.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58b9f19e
    • H
      ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_term · 46f9a1bc
      Hui Peng 提交于
      commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream.
      
      `check_input_term` recursively calls itself with input from
      device side (e.g., uac_input_terminal_descriptor.bCSourceID)
      as argument (id). In `check_input_term`, if `check_input_term`
      is called with the same `id` argument as the caller, it triggers
      endless recursive call, resulting kernel space stack overflow.
      
      This patch fixes the bug by adding a bitmap to `struct mixer_build`
      to keep track of the checked ids and stop the execution if some id
      has been checked (similar to how parse_audio_unit handles unitid
      argument).
      Reported-by: NHui Peng <benquike@gmail.com>
      Reported-by: NMathias Payer <mathias.payer@nebelwelt.net>
      Signed-off-by: NHui Peng <benquike@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46f9a1bc
    • T
      ALSA: hda/realtek - Add quirk for HP Envy x360 · d5bb1240
      Takashi Iwai 提交于
      commit 190d03814eb3b49d4f87ff38fef26d36f3568a60 upstream.
      
      HP Envy x360 (AMD Ryzen-based model) with 103c:8497 needs the same
      quirk like HP Spectre x360 for enabling the mute LED over Mic3 pin.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204373
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5bb1240
    • M
      xtensa: add missing isync to the cpu_reset TLB code · 61f6ecb7
      Max Filippov 提交于
      commit cd8869f4cb257f22b89495ca40f5281e58ba359c upstream.
      
      ITLB entry modifications must be followed by the isync instruction
      before the new entries are possibly used. cpu_reset lacks one isync
      between ITLB way 6 initialization and jump to the identity mapping.
      Add missing isync to xtensa cpu_reset.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61f6ecb7
    • V
      cpufreq: schedutil: Don't skip freq update when limits change · 7c001e5a
      Viresh Kumar 提交于
      commit 600f5badb78c316146d062cfd7af4a2cfb655baa upstream.
      
      To avoid reducing the frequency of a CPU prematurely, we skip reducing
      the frequency if the CPU had been busy recently.
      
      This should not be done when the limits of the policy are changed, for
      example due to thermal throttling. We should always get the frequency
      within the new limits as soon as possible.
      
      Trying to fix this by using only one flag, i.e. need_freq_update, can
      lead to a race condition where the flag gets cleared without forcing us
      to change the frequency at least once. And so this patch introduces
      another flag to avoid that race condition.
      
      Fixes: ecd28842 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
      Cc: v4.18+ <stable@vger.kernel.org> # v4.18+
      Reported-by: NDoug Smythies <dsmythies@telus.net>
      Tested-by: NDoug Smythies <dsmythies@telus.net>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c001e5a
    • F
      Revert "pwm: Set class for exported channels in sysfs" · 7f68aa2e
      Fabrice Gasnier 提交于
      commit c289d6625237aa785b484b4e94c23b3b91ea7e60 upstream.
      
      This reverts commit 7e5d1fd7 ("pwm: Set
      class for exported channels in sysfs") as it causes regression with
      multiple pwm chip[1], when exporting a pwm channel (echo X > export):
      
      - ABI (Documentation/ABI/testing/sysfs-class-pwm) states pwmX should be
        created in /sys/class/pwm/pwmchipN/pwmX
      - Reverted patch causes new entry to be also created directly in
        /sys/class/pwm/pwmX
      - 1st time, exporting pwmX will create an entry in /sys/class/pwm/pwmX
      - class attributes are added under pwmX folder, such as export, unexport
        npwm, symlinks. This is wrong as it belongs to pwmchipN. It may cause
        bad behavior and report wrong values.
      - when another export happens on another pwmchip, it can't be created
        (e.g. -EEXIST). This is causing the issue with multiple pwmchip.
      
      Example on stm32 (stm32429i-eval) platform:
      $ ls /sys/class/pwm
      pwmchip0 pwmchip4
      
      $ cd /sys/class/pwm/pwmchip0/
      $ echo 0 > export
      $ ls /sys/class/pwm
      pwm0 pwmchip0 pwmchip4
      
      $ cd /sys/class/pwm/pwmchip4/
      $ echo 0 > export
      sysfs: cannot create duplicate filename '/class/pwm/pwm0'
      ...Exception stack follows...
      
      This is also seen on other platform [2]
      
      [1] https://lkml.org/lkml/2018/9/25/713
      [2] https://lkml.org/lkml/2018/9/25/447Signed-off-by: NFabrice Gasnier <fabrice.gasnier@st.com>
      Tested-by: NGottfried Haider <gottfried.haider@gmail.com>
      Tested-by: NMichal Vokáč <michal.vokac@ysoft.com>
      Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
      Cc: John Keeping <john@metanate.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f68aa2e
    • I
      mm/usercopy: use memory range to be accessed for wraparound check · 056368fc
      Isaac J. Manjarres 提交于
      commit 951531691c4bcaa59f56a316e018bc2ff1ddf855 upstream.
      
      Currently, when checking to see if accessing n bytes starting at address
      "ptr" will cause a wraparound in the memory addresses, the check in
      check_bogus_address() adds an extra byte, which is incorrect, as the
      range of addresses that will be accessed is [ptr, ptr + (n - 1)].
      
      This can lead to incorrectly detecting a wraparound in the memory
      address, when trying to read 4 KB from memory that is mapped to the the
      last possible page in the virtual address space, when in fact, accessing
      that range of memory would not cause a wraparound to occur.
      
      Use the memory range that will actually be accessed when considering if
      accessing a certain amount of bytes will cause the memory address to
      wrap around.
      
      Link: http://lkml.kernel.org/r/1564509253-23287-1-git-send-email-isaacm@codeaurora.org
      Fixes: f5509cc1 ("mm: Hardened usercopy")
      Signed-off-by: NPrasad Sodagudi <psodagud@codeaurora.org>
      Signed-off-by: NIsaac J. Manjarres <isaacm@codeaurora.org>
      Co-developed-by: NPrasad Sodagudi <psodagud@codeaurora.org>
      Reviewed-by: NWilliam Kucharski <william.kucharski@oracle.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Trilok Soni <tsoni@codeaurora.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      056368fc
    • M
      mm/memcontrol.c: fix use after free in mem_cgroup_iter() · c8282f1b
      Miles Chen 提交于
      commit 54a83d6bcbf8f4700013766b974bf9190d40b689 upstream.
      
      This patch is sent to report an use after free in mem_cgroup_iter()
      after merging commit be2657752e9e ("mm: memcg: fix use after free in
      mem_cgroup_iter()").
      
      I work with android kernel tree (4.9 & 4.14), and commit be2657752e9e
      ("mm: memcg: fix use after free in mem_cgroup_iter()") has been merged
      to the trees.  However, I can still observe use after free issues
      addressed in the commit be2657752e9e.  (on low-end devices, a few times
      this month)
      
      backtrace:
              css_tryget <- crash here
              mem_cgroup_iter
              shrink_node
              shrink_zones
              do_try_to_free_pages
              try_to_free_pages
              __perform_reclaim
              __alloc_pages_direct_reclaim
              __alloc_pages_slowpath
              __alloc_pages_nodemask
      
      To debug, I poisoned mem_cgroup before freeing it:
      
        static void __mem_cgroup_free(struct mem_cgroup *memcg)
              for_each_node(node)
              free_mem_cgroup_per_node_info(memcg, node);
              free_percpu(memcg->stat);
        +     /* poison memcg before freeing it */
        +     memset(memcg, 0x78, sizeof(struct mem_cgroup));
              kfree(memcg);
        }
      
      The coredump shows the position=0xdbbc2a00 is freed.
      
        (gdb) p/x ((struct mem_cgroup_per_node *)0xe5009e00)->iter[8]
        $13 = {position = 0xdbbc2a00, generation = 0x2efd}
      
        0xdbbc2a00:     0xdbbc2e00      0x00000000      0xdbbc2800      0x00000100
        0xdbbc2a10:     0x00000200      0x78787878      0x00026218      0x00000000
        0xdbbc2a20:     0xdcad6000      0x00000001      0x78787800      0x00000000
        0xdbbc2a30:     0x78780000      0x00000000      0x0068fb84      0x78787878
        0xdbbc2a40:     0x78787878      0x78787878      0x78787878      0xe3fa5cc0
        0xdbbc2a50:     0x78787878      0x78787878      0x00000000      0x00000000
        0xdbbc2a60:     0x00000000      0x00000000      0x00000000      0x00000000
        0xdbbc2a70:     0x00000000      0x00000000      0x00000000      0x00000000
        0xdbbc2a80:     0x00000000      0x00000000      0x00000000      0x00000000
        0xdbbc2a90:     0x00000001      0x00000000      0x00000000      0x00100000
        0xdbbc2aa0:     0x00000001      0xdbbc2ac8      0x00000000      0x00000000
        0xdbbc2ab0:     0x00000000      0x00000000      0x00000000      0x00000000
        0xdbbc2ac0:     0x00000000      0x00000000      0xe5b02618      0x00001000
        0xdbbc2ad0:     0x00000000      0x78787878      0x78787878      0x78787878
        0xdbbc2ae0:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2af0:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b00:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b10:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b20:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b30:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b40:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b50:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b60:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b70:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2b80:     0x78787878      0x78787878      0x00000000      0x78787878
        0xdbbc2b90:     0x78787878      0x78787878      0x78787878      0x78787878
        0xdbbc2ba0:     0x78787878      0x78787878      0x78787878      0x78787878
      
      In the reclaim path, try_to_free_pages() does not setup
      sc.target_mem_cgroup and sc is passed to do_try_to_free_pages(), ...,
      shrink_node().
      
      In mem_cgroup_iter(), root is set to root_mem_cgroup because
      sc->target_mem_cgroup is NULL.  It is possible to assign a memcg to
      root_mem_cgroup.nodeinfo.iter in mem_cgroup_iter().
      
              try_to_free_pages
              	struct scan_control sc = {...}, target_mem_cgroup is 0x0;
              do_try_to_free_pages
              shrink_zones
              shrink_node
              	 mem_cgroup *root = sc->target_mem_cgroup;
              	 memcg = mem_cgroup_iter(root, NULL, &reclaim);
              mem_cgroup_iter()
              	if (!root)
              		root = root_mem_cgroup;
              	...
      
              	css = css_next_descendant_pre(css, &root->css);
              	memcg = mem_cgroup_from_css(css);
              	cmpxchg(&iter->position, pos, memcg);
      
      My device uses memcg non-hierarchical mode.  When we release a memcg:
      invalidate_reclaim_iterators() reaches only dead_memcg and its parents.
      If non-hierarchical mode is used, invalidate_reclaim_iterators() never
      reaches root_mem_cgroup.
      
        static void invalidate_reclaim_iterators(struct mem_cgroup *dead_memcg)
        {
              struct mem_cgroup *memcg = dead_memcg;
      
              for (; memcg; memcg = parent_mem_cgroup(memcg)
              ...
        }
      
      So the use after free scenario looks like:
      
        CPU1						CPU2
      
        try_to_free_pages
        do_try_to_free_pages
        shrink_zones
        shrink_node
        mem_cgroup_iter()
            if (!root)
            	root = root_mem_cgroup;
            ...
            css = css_next_descendant_pre(css, &root->css);
            memcg = mem_cgroup_from_css(css);
            cmpxchg(&iter->position, pos, memcg);
      
              				invalidate_reclaim_iterators(memcg);
              				...
              				__mem_cgroup_free()
              					kfree(memcg);
      
        try_to_free_pages
        do_try_to_free_pages
        shrink_zones
        shrink_node
        mem_cgroup_iter()
            if (!root)
            	root = root_mem_cgroup;
            ...
            mz = mem_cgroup_nodeinfo(root, reclaim->pgdat->node_id);
            iter = &mz->iter[reclaim->priority];
            pos = READ_ONCE(iter->position);
            css_tryget(&pos->css) <- use after free
      
      To avoid this, we should also invalidate root_mem_cgroup.nodeinfo.iter
      in invalidate_reclaim_iterators().
      
      [cai@lca.pw: fix -Wparentheses compilation warning]
        Link: http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-cai@lca.pw
      Link: http://lkml.kernel.org/r/20190730015729.4406-1-miles.chen@mediatek.com
      Fixes: 5ac8fb31 ("mm: memcontrol: convert reclaim iterator to simple css refcounting")
      Signed-off-by: NMiles Chen <miles.chen@mediatek.com>
      Signed-off-by: NQian Cai <cai@lca.pw>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8282f1b
    • Y
      mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind · 3c0cb90e
      Yang Shi 提交于
      commit a53190a4aaa36494f4d7209fd1fcc6f2ee08e0e0 upstream.
      
      When running syzkaller internally, we ran into the below bug on 4.9.x
      kernel:
      
        kernel BUG at mm/huge_memory.c:2124!
        invalid opcode: 0000 [#1] SMP KASAN
        CPU: 0 PID: 1518 Comm: syz-executor107 Not tainted 4.9.168+ #2
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011
        task: ffff880067b34900 task.stack: ffff880068998000
        RIP: split_huge_page_to_list+0x8fb/0x1030 mm/huge_memory.c:2124
        Call Trace:
          split_huge_page include/linux/huge_mm.h:100 [inline]
          queue_pages_pte_range+0x7e1/0x1480 mm/mempolicy.c:538
          walk_pmd_range mm/pagewalk.c:50 [inline]
          walk_pud_range mm/pagewalk.c:90 [inline]
          walk_pgd_range mm/pagewalk.c:116 [inline]
          __walk_page_range+0x44a/0xdb0 mm/pagewalk.c:208
          walk_page_range+0x154/0x370 mm/pagewalk.c:285
          queue_pages_range+0x115/0x150 mm/mempolicy.c:694
          do_mbind mm/mempolicy.c:1241 [inline]
          SYSC_mbind+0x3c3/0x1030 mm/mempolicy.c:1370
          SyS_mbind+0x46/0x60 mm/mempolicy.c:1352
          do_syscall_64+0x1d2/0x600 arch/x86/entry/common.c:282
          entry_SYSCALL_64_after_swapgs+0x5d/0xdb
        Code: c7 80 1c 02 00 e8 26 0a 76 01 <0f> 0b 48 c7 c7 40 46 45 84 e8 4c
        RIP  [<ffffffff81895d6b>] split_huge_page_to_list+0x8fb/0x1030 mm/huge_memory.c:2124
         RSP <ffff88006899f980>
      
      with the below test:
      
        uint64_t r[1] = {0xffffffffffffffff};
      
        int main(void)
        {
              syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
                                      intptr_t res = 0;
              res = syscall(__NR_socket, 0x11, 3, 0x300);
              if (res != -1)
                      r[0] = res;
              *(uint32_t*)0x20000040 = 0x10000;
              *(uint32_t*)0x20000044 = 1;
              *(uint32_t*)0x20000048 = 0xc520;
              *(uint32_t*)0x2000004c = 1;
              syscall(__NR_setsockopt, r[0], 0x107, 0xd, 0x20000040, 0x10);
              syscall(__NR_mmap, 0x20fed000, 0x10000, 0, 0x8811, r[0], 0);
              *(uint64_t*)0x20000340 = 2;
              syscall(__NR_mbind, 0x20ff9000, 0x4000, 0x4002, 0x20000340, 0x45d4, 3);
              return 0;
        }
      
      Actually the test does:
      
        mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000
        socket(AF_PACKET, SOCK_RAW, 768)        = 3
        setsockopt(3, SOL_PACKET, PACKET_TX_RING, {block_size=65536, block_nr=1, frame_size=50464, frame_nr=1}, 16) = 0
        mmap(0x20fed000, 65536, PROT_NONE, MAP_SHARED|MAP_FIXED|MAP_POPULATE|MAP_DENYWRITE, 3, 0) = 0x20fed000
        mbind(..., MPOL_MF_STRICT|MPOL_MF_MOVE) = 0
      
      The setsockopt() would allocate compound pages (16 pages in this test)
      for packet tx ring, then the mmap() would call packet_mmap() to map the
      pages into the user address space specified by the mmap() call.
      
      When calling mbind(), it would scan the vma to queue the pages for
      migration to the new node.  It would split any huge page since 4.9
      doesn't support THP migration, however, the packet tx ring compound
      pages are not THP and even not movable.  So, the above bug is triggered.
      
      However, the later kernel is not hit by this issue due to commit
      d44d363f ("mm: don't assume anonymous pages have SwapBacked flag"),
      which just removes the PageSwapBacked check for a different reason.
      
      But, there is a deeper issue.  According to the semantic of mbind(), it
      should return -EIO if MPOL_MF_MOVE or MPOL_MF_MOVE_ALL was specified and
      MPOL_MF_STRICT was also specified, but the kernel was unable to move all
      existing pages in the range.  The tx ring of the packet socket is
      definitely not movable, however, mbind() returns success for this case.
      
      Although the most socket file associates with non-movable pages, but XDP
      may have movable pages from gup.  So, it sounds not fine to just check
      the underlying file type of vma in vma_migratable().
      
      Change migrate_page_add() to check if the page is movable or not, if it
      is unmovable, just return -EIO.  But do not abort pte walk immediately,
      since there may be pages off LRU temporarily.  We should migrate other
      pages if MPOL_MF_MOVE* is specified.  Set has_unmovable flag if some
      paged could not be not moved, then return -EIO for mbind() eventually.
      
      With this change the above test would return -EIO as expected.
      
      [yang.shi@linux.alibaba.com: fix review comments from Vlastimil]
        Link: http://lkml.kernel.org/r/1563556862-54056-3-git-send-email-yang.shi@linux.alibaba.com
      Link: http://lkml.kernel.org/r/1561162809-59140-3-git-send-email-yang.shi@linux.alibaba.comSigned-off-by: NYang Shi <yang.shi@linux.alibaba.com>
      Reviewed-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c0cb90e
    • Y
      mm: mempolicy: make the behavior consistent when MPOL_MF_MOVE* and MPOL_MF_STRICT were specified · cd825d87
      Yang Shi 提交于
      commit d883544515aae54842c21730b880172e7894fde9 upstream.
      
      When both MPOL_MF_MOVE* and MPOL_MF_STRICT was specified, mbind() should
      try best to migrate misplaced pages, if some of the pages could not be
      migrated, then return -EIO.
      
      There are three different sub-cases:
       1. vma is not migratable
       2. vma is migratable, but there are unmovable pages
       3. vma is migratable, pages are movable, but migrate_pages() fails
      
      If #1 happens, kernel would just abort immediately, then return -EIO,
      after a7f40cfe3b7a ("mm: mempolicy: make mbind() return -EIO when
      MPOL_MF_STRICT is specified").
      
      If #3 happens, kernel would set policy and migrate pages with
      best-effort, but won't rollback the migrated pages and reset the policy
      back.
      
      Before that commit, they behaves in the same way.  It'd better to keep
      their behavior consistent.  But, rolling back the migrated pages and
      resetting the policy back sounds not feasible, so just make #1 behave as
      same as #3.
      
      Userspace will know that not everything was successfully migrated (via
      -EIO), and can take whatever steps it deems necessary - attempt
      rollback, determine which exact page(s) are violating the policy, etc.
      
      Make queue_pages_range() return 1 to indicate there are unmovable pages
      or vma is not migratable.
      
      The #2 is not handled correctly in the current kernel, the following
      patch will fix it.
      
      [yang.shi@linux.alibaba.com: fix review comments from Vlastimil]
        Link: http://lkml.kernel.org/r/1563556862-54056-2-git-send-email-yang.shi@linux.alibaba.com
      Link: http://lkml.kernel.org/r/1561162809-59140-2-git-send-email-yang.shi@linux.alibaba.comSigned-off-by: NYang Shi <yang.shi@linux.alibaba.com>
      Reviewed-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd825d87
    • R
      mm/hmm: fix bad subpage pointer in try_to_unmap_one · f0fed828
      Ralph Campbell 提交于
      commit 1de13ee59225dfc98d483f8cce7d83f97c0b31de upstream.
      
      When migrating an anonymous private page to a ZONE_DEVICE private page,
      the source page->mapping and page->index fields are copied to the
      destination ZONE_DEVICE struct page and the page_mapcount() is
      increased.  This is so rmap_walk() can be used to unmap and migrate the
      page back to system memory.
      
      However, try_to_unmap_one() computes the subpage pointer from a swap pte
      which computes an invalid page pointer and a kernel panic results such
      as:
      
        BUG: unable to handle page fault for address: ffffea1fffffffc8
      
      Currently, only single pages can be migrated to device private memory so
      no subpage computation is needed and it can be set to "page".
      
      [rcampbell@nvidia.com: add comment]
        Link: http://lkml.kernel.org/r/20190724232700.23327-4-rcampbell@nvidia.com
      Link: http://lkml.kernel.org/r/20190719192955.30462-4-rcampbell@nvidia.com
      Fixes: a5430dda ("mm/migrate: support un-addressable ZONE_DEVICE page in migration")
      Signed-off-by: NRalph Campbell <rcampbell@nvidia.com>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0fed828
    • N
      seq_file: fix problem when seeking mid-record · 3858cca1
      NeilBrown 提交于
      commit 6a2aeab59e97101b4001bac84388fc49a992f87e upstream.
      
      If you use lseek or similar (e.g.  pread) to access a location in a
      seq_file file that is within a record, rather than at a record boundary,
      then the first read will return the remainder of the record, and the
      second read will return the whole of that same record (instead of the
      next record).  When seeking to a record boundary, the next record is
      correctly returned.
      
      This bug was introduced by a recent patch (identified below).  Before
      that patch, seq_read() would increment m->index when the last of the
      buffer was returned (m->count == 0).  After that patch, we rely on
      ->next to increment m->index after filling the buffer - but there was
      one place where that didn't happen.
      
      Link: https://lkml.kernel.org/lkml/877e7xl029.fsf@notabene.neil.brown.name/
      Fixes: 1f4aace6 ("fs/seq_file.c: simplify seq_file iteration code and interface")
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Reported-by: NSergei Turchanov <turchanov@farpost.com>
      Tested-by: NSergei Turchanov <turchanov@farpost.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Markus Elfring <Markus.Elfring@web.de>
      Cc: <stable@vger.kernel.org>	[4.19+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3858cca1
    • G
      sh: kernel: hw_breakpoint: Fix missing break in switch statement · 50d15197
      Gustavo A. R. Silva 提交于
      commit 1ee1119d184bb06af921b48c3021d921bbd85bac upstream.
      
      Add missing break statement in order to prevent the code from falling
      through to case SH_BREAKPOINT_WRITE.
      
      Fixes: 09a07294 ("sh: hw-breakpoints: Add preliminary support for SH-4A UBC.")
      Cc: stable@vger.kernel.org
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50d15197
  2. 16 8月, 2019 4 次提交