linux.git, branch v5.4.179

Linux 5.4.179

2022-02-11T08:07:52+00:00

Link: https://lore.kernel.org/r/20220209191248.688351316@linuxfoundation.org
Tested-by: Shuah Khan 
Tested-by: Florian Fainelli 
Tested-by: Jon Hunter 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Sudip Mukherjee 
Tested-by: Slade Watkins 
Tested-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

tipc: improve size validations for received domain records

2022-02-11T08:07:52+00:00

commit 9aa422ad326634b76309e8ff342c246800621216 upstream.

The function tipc_mon_rcv() allows a node to receive and process
domain_record structs from peer nodes to track their views of the
network topology.

This patch verifies that the number of members in a received domain
record does not exceed the limit defined by MAX_MON_DOMAIN, something
that may otherwise lead to a stack overflow.

tipc_mon_rcv() is called from the function tipc_link_proto_rcv(), where
we are reading a 32 bit message data length field into a uint16.  To
avert any risk of bit overflow, we add an extra sanity check for this in
that function.  We cannot see that happen with the current code, but
future designers being unaware of this risk, may introduce it by
allowing delivery of very large (> 64k) sk buffers from the bearer
layer.  This potential problem was identified by Eric Dumazet.

This fixes CVE-2022-0435

Reported-by: Samuel Page 
Reported-by: Eric Dumazet 
Fixes: 35c55c9877f8 ("tipc: add neighbor monitoring framework")
Signed-off-by: Jon Maloy 
Reviewed-by: Xin Long 
Reviewed-by: Samuel Page 
Reviewed-by: Eric Dumazet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

moxart: fix potential use-after-free on remove path

2022-02-11T08:07:51+00:00

commit bd2db32e7c3e35bd4d9b8bbff689434a50893546 upstream.

It was reported that the mmc host structure could be accessed after it
was freed in moxart_remove(), so fix this by saving the base register of
the device and using it instead of the pointer dereference.

Cc: Ulf Hansson 
Cc: Xiyu Yang 
Cc: Xin Xiong 
Cc: Xin Tan 
Cc: Tony Lindgren 
Cc: Yang Li 
Cc: linux-mmc@vger.kernel.org
Cc: stable 
Reported-by: whitehat002 
Signed-off-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20220127071638.4057899-1-gregkh@linuxfoundation.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

Linux 5.4.178

2022-02-08T17:24:35+00:00

Link: https://lore.kernel.org/r/20220207103753.155627314@linuxfoundation.org
Tested-by: Shuah Khan 
Tested-by: Florian Fainelli 
Tested-by: Slade Watkins 
Tested-by: Guenter Roeck 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Jon Hunter 
Tested-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

cgroup/cpuset: Fix "suspicious RCU usage" lockdep warning

2022-02-08T17:24:35+00:00

commit 2bdfd2825c9662463371e6691b1a794e97fa36b4 upstream.

It was found that a "suspicious RCU usage" lockdep warning was issued
with the rcu_read_lock() call in update_sibling_cpumasks().  It is
because the update_cpumasks_hier() function may sleep. So we have
to release the RCU lock, call update_cpumasks_hier() and reacquire
it afterward.

Also add a percpu_rwsem_assert_held() in update_sibling_cpumasks()
instead of stating that in the comment.

Fixes: 4716909cc5c5 ("cpuset: Track cpusets that use parent's effective_cpus")
Signed-off-by: Waiman Long 
Tested-by: Phil Auld 
Reviewed-by: Phil Auld 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

ext4: fix error handling in ext4_restore_inline_data()

2022-02-08T17:24:34+00:00

commit 897026aaa73eb2517dfea8d147f20ddb0b813044 upstream.

While running "./check -I 200 generic/475" it sometimes gives below
kernel BUG(). Ideally we should not call ext4_write_inline_data() if
ext4_create_inline_data() has failed.


[73131.453234] kernel BUG at fs/ext4/inline.c:223!


 212 static void ext4_write_inline_data(struct inode *inode, struct ext4_iloc *iloc,
 213                                    void *buffer, loff_t pos, unsigned int len)
 214 {
<...>
 223         BUG_ON(!EXT4_I(inode)->i_inline_off);
 224         BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);

This patch handles the error and prints out a emergency msg saying potential
data loss for the given inode (since we couldn't restore the original
inline_data due to some previous error).

[ 9571.070313] EXT4-fs (dm-0): error restoring inline_data for inode -- potential data loss! (inode 1703982, error -30)

Reported-by: Eric Whitney 
Signed-off-by: Ritesh Harjani 
Reviewed-by: Jan Kara 
Link: https://lore.kernel.org/r/9f4cd7dfd54fa58ff27270881823d94ddf78dd07.1642416995.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman



EDAC/xgene: Fix deferred probing
2022-02-08T17:24:34+00:00

commit dfd0dfb9a7cc04acf93435b440dd34c2ca7b4424 upstream.

The driver overrides error codes returned by platform_get_irq_optional()
to -EINVAL for some strange reason, so if it returns -EPROBE_DEFER, the
driver will fail the probe permanently instead of the deferred probing.
Switch to propagating the proper error codes to platform driver code
upwards.

  [ bp: Massage commit message. ]

Fixes: 0d4429301c4a ("EDAC: Add APM X-Gene SoC EDAC driver")
Signed-off-by: Sergey Shtylyov 
Signed-off-by: Borislav Petkov 
Cc: 
Link: https://lore.kernel.org/r/20220124185503.6720-3-s.shtylyov@omp.ru
Signed-off-by: Greg Kroah-Hartman 




EDAC/altera: Fix deferred probing
2022-02-08T17:24:34+00:00

commit 279eb8575fdaa92c314a54c0d583c65e26229107 upstream.

The driver overrides the error codes returned by platform_get_irq() to
-ENODEV for some strange reason, so if it returns -EPROBE_DEFER, the
driver will fail the probe permanently instead of the deferred probing.
Switch to propagating the proper error codes to platform driver code
upwards.

  [ bp: Massage commit message. ]

Fixes: 71bcada88b0f ("edac: altera: Add Altera SDRAM EDAC support")
Signed-off-by: Sergey Shtylyov 
Signed-off-by: Borislav Petkov 
Acked-by: Dinh Nguyen 
Cc: 
Link: https://lore.kernel.org/r/20220124185503.6720-2-s.shtylyov@omp.ru
Signed-off-by: Greg Kroah-Hartman 




rtc: cmos: Evaluate century appropriate
2022-02-08T17:24:34+00:00

commit ff164ae39b82ee483b24579c8e22a13a8ce5bd04 upstream.

There's limiting the year to 2069. When setting the rtc year to 2070,
reading it returns 1970. Evaluate century starting from 19 to count the
correct year.

$ sudo date -s 20700106
Mon 06 Jan 2070 12:00:00 AM CST
$ sudo hwclock -w
$ sudo hwclock -r
1970-01-06 12:00:49.604968+08:00

Fixes: 2a4daadd4d3e5071 ("rtc: cmos: ignore bogus century byte")

Signed-off-by: Riwen Lu 
Acked-by: Eric Wong 
Reviewed-by: Mateusz Jończyk 
Signed-off-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20220106084609.1223688-1-luriwen@kylinos.cn
Signed-off-by: Mateusz Jończyk  # preparation for stable
Signed-off-by: Greg Kroah-Hartman 




selftests: futex: Use variable MAKE instead of make
2022-02-08T17:24:34+00:00

commit b9199181a9ef8252e47e207be8c23e1f50662620 upstream.

Recursive make commands should always use the variable MAKE, not the
explicit command name ‘make’. This has benefits and removes the
following warning when multiple jobs are used for the build:

make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.

Fixes: a8ba798bc8ec ("selftests: enable O and KBUILD_OUTPUT")
Signed-off-by: Muhammad Usama Anjum 
Reviewed-by: André Almeida 
Signed-off-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman