From: Takashi Iwai <redacted>
[ Upstream commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 ]
The sco_send_frame() also takes lock_sock() during memcpy_from_msg()
call that may be endlessly blocked by a task with userfaultd
technique, and this will result in a hung task watchdog trigger.
Just like the similar fix for hci_sock_sendmsg() in commit
92c685dc5de0 ("Bluetooth: reorganize functions..."), this patch moves
the memcpy_from_msg() out of lock_sock() for addressing the hang.
This should be the last piece for fixing CVE-2021-3640 after a few
already queued fixes.
Signed-off-by: Takashi Iwai <redacted>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/sco.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
@@ -1337,6 +1340,9 @@ static void l2cap_sock_teardown_cb(struct l2cap_chan *chan, int err)structsock*sk=chan->data;structsock*parent;+if(!sk)+return;+BT_DBG("chan %p state %s",chan,state_to_string(chan->state));/* This callback can be called both for server (BT_LISTEN)
From: Jonas Dreßler <redacted>
[ Upstream commit c2e9666cdffd347460a2b17988db4cfaf2a68fb9 ]
We currently handle changing from the P2P to the STATION virtual
interface type slightly different than changing from P2P to ADHOC: When
changing to STATION, we don't send the SET_BSS_MODE command. We do send
that command on all other type-changes though, and it probably makes
sense to send the command since after all we just changed our BSS_MODE.
Looking at prior changes to this part of the code, it seems that this is
simply a leftover from old refactorings.
Since sending the SET_BSS_MODE command is the only difference between
mwifiex_change_vif_to_sta_adhoc() and the current code, we can now use
mwifiex_change_vif_to_sta_adhoc() for both switching to ADHOC and
STATION interface type.
This does not fix any particular bug and just "looked right", so there's
a small chance it might be a regression.
Signed-off-by: Jonas Dreßler <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210914195909.36035-4-verdre@v0yd.nl
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/marvell/mwifiex/cfg80211.c | 22 ++++---------------
1 file changed, 4 insertions(+), 18 deletions(-)
From: Jonas Dreßler <redacted>
[ Upstream commit c606008b70627a2fc485732a53cc22f0f66d0981 ]
When creating a new virtual interface in mwifiex_add_virtual_intf(), we
update our internal driver states like bss_type, bss_priority, bss_role
and bss_mode to reflect the mode the firmware will be set to.
When switching virtual interface mode using
mwifiex_init_new_priv_params() though, we currently only update bss_mode
and bss_role. In order for the interface mode switch to actually work,
we also need to update bss_type to its proper value, so do that.
This fixes a crash of the firmware (because the driver tries to execute
commands that are invalid in AP mode) when switching from station mode
to AP mode.
Signed-off-by: Jonas Dreßler <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210914195909.36035-9-verdre@v0yd.nl
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
From: Stephen Suryaputra <redacted>
[ Upstream commit 61e18ce7348bfefb5688a8bcd4b4d6b37c0f9b2a ]
When addr_gen_mode is set to IN6_ADDR_GEN_MODE_NONE, the link-local addr
should not be generated. But it isn't the case for GRE (as well as GRE6)
and SIT tunnels. Make it so that tunnels consider the addr_gen_mode,
especially for IN6_ADDR_GEN_MODE_NONE.
Do this in add_v4_addrs() to cover both GRE and SIT only if the addr
scope is link.
Signed-off-by: Stephen Suryaputra <redacted>
Acked-by: Antonio Quartulli <redacted>
Link: https://lore.kernel.org/r/20211020200618.467342-1-ssuryaextr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv6/addrconf.c | 3 +++
1 file changed, 3 insertions(+)
From: Johannes Berg <redacted>
[ Upstream commit e5322b9ab5f63536c41301150b7ce64605ce52cc ]
Just like we have default SMPS mode as dynamic in powersave,
we should not enable RX-diversity in powersave, to reduce
power consumption when connected to a non-MIMO AP.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20211017113927.fc896bc5cdaa.I1d11da71b8a5cbe921a37058d5f578f1b14a2023@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 3 +++
1 file changed, 3 insertions(+)
From: Tuo Li <redacted>
[ Upstream commit 4b6012a7830b813799a7faf40daa02a837e0fd5b ]
kzalloc() is used to allocate memory for cd->detectors, and if it fails,
channel_detector_exit() behind the label fail will be called:
channel_detector_exit(dpd, cd);
In channel_detector_exit(), cd->detectors is dereferenced through:
struct pri_detector *de = cd->detectors[i];
To fix this possible null-pointer dereference, check cd->detectors before
the for loop to dereference cd->detectors.
Reported-by: TOTE Robot <redacted>
Signed-off-by: Tuo Li <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210805153854.154066-1-islituo@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
From: Brian Norris <briannorris@chromium.org> Date: 2021-11-09 18:07:10
On Mon, Nov 8, 2021 at 5:18 PM Sasha Levin [off-list ref] wrote:
From: Jonas Dreßler <redacted>
[ Upstream commit c2e9666cdffd347460a2b17988db4cfaf2a68fb9 ]
...
This does not fix any particular bug and just "looked right", so there's
a small chance it might be a regression.
I won't insist on rejecting this one, but especially given this
sentence, this doesn't really pass the smell test for -stable
candidates. It's stuff like this that pushes me a bit toward the camp
of those who despise the ML-based selection methods here, even though
it occasionally (or even often) may produce some good.
Brian
On Tue, Nov 09, 2021 at 10:06:19AM -0800, Brian Norris wrote:
On Mon, Nov 8, 2021 at 5:18 PM Sasha Levin [off-list ref] wrote:
quoted
From: Jonas Dreßler <redacted>
[ Upstream commit c2e9666cdffd347460a2b17988db4cfaf2a68fb9 ]
...
quoted
This does not fix any particular bug and just "looked right", so there's
a small chance it might be a regression.
I won't insist on rejecting this one, but especially given this
sentence, this doesn't really pass the smell test for -stable
candidates. It's stuff like this that pushes me a bit toward the camp
of those who despise the ML-based selection methods here, even though
it occasionally (or even often) may produce some good.
I have hundreds of examples of patches that claim they are just an
improvement but fix a serious bug :)
--
Thanks,
Sasha