When sta_info_move does not make progress, likely to due driver
being funky, mac80211 can busy spin forever. Fix this by detecting
the lack of progress and attempting to recover as best we can.
Painful details on how this bug was found:
I backported out-of-tree ax200 driver from backport-iwlwifi to my
5.4 kernel so that I could run ax200 beside other radios (backports
mac80211 otherwise is incompatible and other drivers will crash).
While running tx + rx udp and tcp traffic on ax200, it crashes often
(but backport driver is much more stable than in-kernel driver).
The crash often causes the kernel to deadlock due to the
while (sta->sta_state == IEEE80211_STA_AUTHORIZED)
loop in __sta_info_Destroy_part. If sta_info_move_state does not
make progress, then it will loop forever. In my case, sta_info_move_state
fails due to the sdata-in-driver check.
With this patch, there is safety code to bail out after 1000 tries of
moving the sta state, and also I check for EIO which is returned by
the sdata-in-driver failure case and treat that as success as far as
changing sta state goes.
Console logs look like this in the failure case, and aside from the ax200
radio that went phantom, the rest of the system is usable:
iwlwifi 0000:12:00.0: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
iwlwifi 0000:12:00.0: Firmware error during reconfiguration - reprobe!
iwlwifi 0000:12:00.0: Failed to start RT ucode: -5
wlan2: Failed check-sdata-in-driver check, flags: 0x0 count: 1
wlan2: Failed check-sdata-in-driver check, flags: 0x0 count: 1
wlan2: Failed check-sdata-in-driver check, flags: 0x0 count: 1
iwlwifi 0000:12:00.0: Failed to trigger RX queues sync (-5)
wlan2: Failed check-sdata-in-driver check, flags: 0x0 count: 1
wlan2: drv_sta_state failed with EIO (sdata not in driver?), state: 4 new-state: 3
wlan2: drv_sta_state failed with EIO (sdata not in driver?), state: 3 new-state: 2
wlan2: drv_sta_state failed with EIO (sdata not in driver?), state: 2 new-state: 1
wlan2: Failed check-sdata-in-driver check, flags: 0x0 count: 1
iwlwifi 0000:12:00.0: iwl_trans_wait_txq_empty bad state = 0
iwlwifi 0000:12:00.0: dma_pool_destroy iwlwifi:bc, 00000000d859bd4c busy
Signed-off-by: Ben Greear <email address hidden>
(cherry-picked from https://patchwork.kernel<email address hidden>/)
Signed-off-by: You-Sheng Yang (vicamo) <email address hidden>
We found that with the latest mainline kernel (5.12.0-051200rc8) on
some KVM instances / bare-metal systems, the following tests will take
longer than the kselftest framework default timeout (45 seconds) to
run and thus got terminated with TIMEOUT error:
* xfrm_policy.sh - took about 2m20s
* pmtu.sh - took about 3m5s
* udpgso_bench.sh - took about 60s
Bump the timeout setting to 5 minutes to allow them have a chance to
finish.
https://bugs.launchpad.net/bugs/1856010
Signed-off-by: Po-Hsu Lin <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit b881d089c7c9c7032da812cda1b4b0818f477780)
Signed-off-by: Po-Hsu Lin <email address hidden>
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
Fixes: e1f32190cf7d ("tipc: add support for AEAD key setting via netlink")
Signed-off-by: Eric Dumazet <email address hidden>
Cc: Tuong Lien <email address hidden>
Cc: Jon Maloy <email address hidden>
Cc: Ying Xue <email address hidden>
Reported-by: syzbot <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 0217ed2848e8538bcf9172d97ed2eeb4a26041bb)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
8cd9280...
by
Dmitry Baryshkov <email address hidden>
misc: fastrpc: restrict user apps from sending kernel RPC messages
CVE-2021-28375
Verify that user applications are not using the kernel RPC message
handle to restrict them from directly attaching to guest OS on the
remote subsystem. This is a port of CVE-2019-2308 fix.
Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Cc: Srinivas Kandagatla <email address hidden>
Cc: Jonathan Marek <email address hidden>
Cc: <email address hidden>
Signed-off-by: Dmitry Baryshkov <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit 20c40794eb85ea29852d7bc37c55713802a543d6)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
69c51e5...
by
Dan Carpenter <email address hidden>
net/x25: prevent a couple of overflows
CVE-2020-35519
The .x25_addr[] address comes from the user and is not necessarily
NUL terminated. This leads to a couple problems. The first problem is
that the strlen() in x25_bind() can read beyond the end of the buffer.
The second problem is more subtle and could result in memory corruption.
The call tree is:
x25_connect()
--> x25_write_internal()
--> x25_addr_aton()
The .x25_addr[] buffers are copied to the "addresses" buffer from
x25_write_internal() so it will lead to stack corruption.
Verify that the strings are NUL terminated and return -EINVAL if they
are not.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: a9288525d2ae ("X25: Dont let x25_bind use addresses containing characters")
Reported-by: "kiyin(尹亮)" <email address hidden>
Signed-off-by: Dan Carpenter <email address hidden>
Acked-by: Martin Schiller <email address hidden>
Link: https://lore.kernel.org/r/X8ZeAKm8FnFpN//B@mwanda
Signed-off-by: Jakub Kicinski <email address hidden>
(cherry picked from commit 6ee50c8e262a0f0693dad264c3c99e30e6442a56)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Chia-Lin Kao (AceLan) <email address hidden>
