linux-stable.git/drivers, branch v5.14.5

clk: kirkwood: Fix a clocking boot regression

2021-09-15T08:02:36+00:00

commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream.

Since a few kernel releases the Pogoplug 4 has crashed like this
during boot:

Unable to handle kernel NULL pointer dereference at virtual address 00000002
(...)
[] (strlen) from [] (kstrdup+0x1c/0x4c)
[] (kstrdup) from [] (__clk_register+0x44/0x37c)
[] (__clk_register) from [] (clk_hw_register+0x20/0x44)
[] (clk_hw_register) from [] (__clk_hw_register_mux+0x198/0x1e4)
[] (__clk_hw_register_mux) from [] (clk_register_mux_table+0x5c/0x6c)
[] (clk_register_mux_table) from [] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac)
[] (kirkwood_clk_muxing_setup.constprop.0) from [] (of_clk_init+0x12c/0x214)
[] (of_clk_init) from [] (time_init+0x20/0x2c)
[] (time_init) from [] (start_kernel+0x3dc/0x56c)
[] (start_kernel) from [<00000000>] (0x0)
Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000)

This is because the "powersave" mux clock 0 was provided in an unterminated
array, which is required by the loop in the driver:

        /* Count, allocate, and register clock muxes */
        for (n = 0; desc[n].name;)
                n++;

Here n will go out of bounds and then call clk_register_mux() on random
memory contents after the mux clock.

Fix this by terminating the array with a blank entry.

Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer")
Cc: stable@vger.kernel.org
Cc: Andrew Lunn 
Cc: Chris Packham 
Cc: Gregory CLEMENT 
Cc: Sebastian Hesselbarth 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org
Reviewed-by: Andrew Lunn 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

backlight: pwm_bl: Improve bootloader/kernel device handover

2021-09-15T08:02:36+00:00

commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream.

Currently there are (at least) two problems in the way pwm_bl starts
managing the enable_gpio pin. Both occur when the backlight is initially
off and the driver finds the pin not already in output mode and, as a
result, unconditionally switches it to output-mode and asserts the signal.

Problem 1: This could cause the backlight to flicker since, at this stage
in driver initialisation, we have no idea what the PWM and regulator are
doing (an unconfigured PWM could easily "rest" at 100% duty cycle).

Problem 2: This will cause us not to correctly honour the
post_pwm_on_delay (which also risks flickers).

Fix this by moving the code to configure the GPIO output mode until after
we have examines the handover state. That allows us to initialize
enable_gpio to off if the backlight is currently off and on if the
backlight is on.

Cc: stable@vger.kernel.org
Reported-by: Marek Vasut 
Signed-off-by: Daniel Thompson 
Acked-by: Marek Vasut 
Tested-by: Marek Vasut 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

RDMA/mlx5: Fix number of allocated XLT entries

2021-09-15T08:02:36+00:00

commit 9660dcbe0d9186976917c94bce4e69dbd8d7a974 upstream.

In commit 8010d74b9965b ("RDMA/mlx5: Split the WR setup out of
mlx5_ib_update_xlt()") the allocation logic was split out of
mlx5_ib_update_xlt() and the logic was changed to enable better OOM
handling. Sadly this change introduced a miscalculation of the number of
entries that were actually allocated when under memory pressure where it
can actually become 0 which on s390 lets dma_map_single() fail.

It can also lead to corruption of the free pages list when the wrong
number of entries is used in the calculation of sg->length which is used
as argument for free_pages().

Fix this by using the allocation size instead of misusing get_order(size).

Cc: stable@vger.kernel.org
Fixes: 8010d74b9965 ("RDMA/mlx5: Split the WR setup out of mlx5_ib_update_xlt()")
Link: https://lore.kernel.org/r/20210908081849.7948-1-schnelle@linux.ibm.com
Signed-off-by: Niklas Schnelle 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

ACPI: PRM: Find PRMT table before parsing it

2021-09-15T08:02:36+00:00

commit 3265cc3ec52e75fc8daf189954cebda27ad26b2e upstream.

Find and verify PRMT before parsing it, which eliminates a
warning on machines without PRMT:

	[    7.197173] ACPI: PRMT not present

Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Signed-off-by: Aubrey Li 
Tested-by: Paul Menzel 
Cc: 5.14+  # 5.14+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

fbmem: don't allow too huge resolutions

2021-09-15T08:02:36+00:00

commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream.

syzbot is reporting page fault at vga16fb_fillrect() [1], for
vga16fb_check_var() is failing to detect multiplication overflow.

  if (vxres * vyres > maxmem) {
    vyres = maxmem / vxres;
    if (vyres < yres)
      return -ENOMEM;
  }

Since no module would accept too huge resolutions where multiplication
overflow happens, let's reject in the common path.

Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot 
Debugged-by: Randy Dunlap 
Signed-off-by: Tetsuo Handa 
Reviewed-by: Geert Uytterhoeven 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp
Signed-off-by: Greg Kroah-Hartman

char: tpm: Kconfig: remove bad i2c cr50 select

2021-09-15T08:02:35+00:00

commit 847fdae1579f4ee930b01f24a7847b8043bf468c upstream.

This fixes a minor bug which went unnoticed during the initial
driver upstreaming review: TCG_CR50 does not exist in mainline
kernels, so remove it.

Fixes: 3a253caaad11 ("char: tpm: add i2c driver for cr50")
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Adrian Ratiu 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

md/raid10: Remove unnecessary rcu_dereference in raid10_handle_discard

2021-09-15T08:02:35+00:00

commit 46d4703b1db4c86ab5acb2331b10df999f005e8e upstream.

We are seeing the following warning in raid10_handle_discard.
[  695.110751] =============================
[  695.131439] WARNING: suspicious RCU usage
[  695.151389] 4.18.0-319.el8.x86_64+debug #1 Not tainted
[  695.174413] -----------------------------
[  695.192603] drivers/md/raid10.c:1776 suspicious
rcu_dereference_check() usage!
[  695.225107] other info that might help us debug this:
[  695.260940] rcu_scheduler_active = 2, debug_locks = 1
[  695.290157] no locks held by mkfs.xfs/10186.

In the first loop of function raid10_handle_discard. It already
determines which disk need to handle discard request and add the
rdev reference count rdev->nr_pending. So the conf->mirrors will
not change until all bios come back from underlayer disks. It
doesn't need to use rcu_dereference to get rdev.

Cc: stable@vger.kernel.org
Fixes: d30588b2731f ('md/raid10: improve raid10 discard request')
Signed-off-by: Xiao Ni 
Acked-by: Guoqing Jiang 
Signed-off-by: Song Liu 
Signed-off-by: Greg Kroah-Hartman

tty: Fix data race between tiocsti() and flush_to_ldisc()

2021-09-15T08:02:33+00:00

commit bb2853a6a421a052268eee00fd5d3f6b3504b2b1 upstream.

The ops->receive_buf() may be accessed concurrently from these two
functions.  If the driver flushes data to the line discipline
receive_buf() method while tiocsti() is waiting for the
ops->receive_buf() to finish its work, the data race will happen.

For example:
tty_ioctl			|tty_ldisc_receive_buf
 ->tioctsi			| ->tty_port_default_receive_buf
				|  ->tty_ldisc_receive_buf
   ->hci_uart_tty_receive	|   ->hci_uart_tty_receive
    ->h4_recv                   |    ->h4_recv

In this case, the h4 receive buffer will be overwritten by the
latecomer, and we will lost the data.

Hence, change tioctsi() function to use the exclusive lock interface
from tty_buffer to avoid the data race.

Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
Reviewed-by: Jiri Slaby 
Signed-off-by: Nguyen Dinh Phi 
Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

raid1: ensure write behind bio has less than BIO_MAX_VECS sectors

2021-09-15T08:02:33+00:00

commit 6607cd319b6b91bff94e90f798a61c031650b514 upstream.

We can't split write behind bio with more than BIO_MAX_VECS sectors,
otherwise the below call trace was triggered because we could allocate
oversized write behind bio later.

[ 8.097936] bvec_alloc+0x90/0xc0
[ 8.098934] bio_alloc_bioset+0x1b3/0x260
[ 8.099959] raid1_make_request+0x9ce/0xc50 [raid1]
[ 8.100988] ? __bio_clone_fast+0xa8/0xe0
[ 8.102008] md_handle_request+0x158/0x1d0 [md_mod]
[ 8.103050] md_submit_bio+0xcd/0x110 [md_mod]
[ 8.104084] submit_bio_noacct+0x139/0x530
[ 8.105127] submit_bio+0x78/0x1d0
[ 8.106163] ext4_io_submit+0x48/0x60 [ext4]
[ 8.107242] ext4_writepages+0x652/0x1170 [ext4]
[ 8.108300] ? do_writepages+0x41/0x100
[ 8.109338] ? __ext4_mark_inode_dirty+0x240/0x240 [ext4]
[ 8.110406] do_writepages+0x41/0x100
[ 8.111450] __filemap_fdatawrite_range+0xc5/0x100
[ 8.112513] file_write_and_wait_range+0x61/0xb0
[ 8.113564] ext4_sync_file+0x73/0x370 [ext4]
[ 8.114607] __x64_sys_fsync+0x33/0x60
[ 8.115635] do_syscall_64+0x33/0x40
[ 8.116670] entry_SYSCALL_64_after_hwframe+0x44/0xae

Thanks for the comment from Christoph.

[1]. https://bugs.archlinux.org/task/70992

Cc: stable@vger.kernel.org # v5.12+
Reported-by: Jens Stutte 
Tested-by: Jens Stutte 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Guoqing Jiang 
Signed-off-by: Song Liu 
Signed-off-by: Greg Kroah-Hartman

auxdisplay: hd44780: Fix oops on module unloading

2021-09-15T08:02:32+00:00

commit 333ff32d54cdefc2e479892e7f15ac91e026b57d upstream.

Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/lkml/CAHp75VfKyqy+vM0XkP9Yb+znGOTVT4zYCRY3A3nQ7C3WNUVN0g@mail.gmail.com/
Reported-By: Andy Shevchenko 
Signed-off-by: Lars Poeschel 
Tested-by: Andy Shevchenko 
[added Link, Fixes, Cc stable tags, edited message]
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman