[ Upstream commit 6a0c054930d554ad8f8044ef1fc856d9da391c81 ]
There are sleep in atomic context bugs when dm_fsync_timer_callback is
executing. The root cause is that the memory allocation functions with
GFP_KERNEL or GFP_NOIO parameters are called in dm_fsync_timer_callback
which is a timer handler. The call paths that could trigger bugs are
shown below:
(interrupt context)
dm_fsync_timer_callback
write_nic_byte
kzalloc(sizeof(data), GFP_KERNEL); //may sleep
usb_control_msg
kmalloc(.., GFP_NOIO); //may sleep
write_nic_dword
kzalloc(sizeof(data), GFP_KERNEL); //may sleep
usb_control_msg
kmalloc(.., GFP_NOIO); //may sleep
This patch uses delayed work to replace timer and moves the operations
that may sleep into the delayed work in order to mitigate bugs.
Fixes: 8fc8598e61 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Link: https://lore.kernel.org/r/20220710103002.63283-1-duoming@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 806c7b53414934ba2a39449b31fd1a038e500273 ]
There is a deadlock in ieee80211_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2)
| ieee80211_send_beacon()
ieee80211_beacons_stop() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | ieee80211_send_beacon_cb()
del_timer_sync() | spin_lock_irqsave() //(2)
(wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use
del_timer_sync() to wait timer to stop, but timer handler
also need ieee->beacon_lock in position (2) of thread 2.
As a result, ieee80211_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of
spin_lock_irqsave(), which could let timer handler to obtain
the needed lock.
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Link: https://lore.kernel.org/r/20220417135407.109536-1-duoming@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrapping around and a smaller allocation being made than the
caller was expecting. Using those allocations could lead to linear
overflows of heap memory and other misbehaviors.
In this case these aren't actually dynamic sizes: both sides of the
multiplication are constant values. However it is best to refactor these
anyway, just to keep the open-coded math idiom out of code.
So, use the purpose specific kcalloc() function instead of the argument
size * count in the kzalloc() function.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Len Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210824090039.GA7999@titan
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clang warns:
drivers/staging/rtl8192u/r8192U_core.c:4268:20: warning: bitwise and of
boolean expressions; did you mean logical and? [-Wbool-operation-and]
bpacket_toself = bpacket_match_bssid &
^~~~~~~~~~~~~~~~~~~~~
&&
1 warning generated.
Replace the bitwise AND with a logical one to clear up the warning, as
that is clearly what was intended.
Fixes: 8fc8598e61 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20210814235625.1780033-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
Split the 3 addr memcpy() into 3 memcpy() calls so the compiler doesn't
think an overflowing memcpy() happens against the addr1 field (the
neighbors are intended to be copied as well).
ieee80211_read_qos_param_element() copies a struct ieee80211_info_element
into a struct ieee80211_qos_information_element, but is actually wanting to
copy into the larger struct ieee80211_qos_parameter_info (the contents of
ac_params_record[] is later examined). Refactor the routine to perform
centralized checks, and copy the entire contents directly (since the id
and len members match the elementID and length members):
struct ieee80211_info_element {
u8 id;
u8 len;
u8 data[];
} __packed;
struct ieee80211_qos_information_element {
u8 elementID;
u8 length;
u8 qui[QOS_OUI_LEN];
u8 qui_type;
u8 qui_subtype;
u8 version;
u8 ac_info;
} __packed;
struct ieee80211_qos_parameter_info {
struct ieee80211_qos_information_element info_element;
u8 reserved;
struct ieee80211_qos_ac_parameter ac_params_record[QOS_QUEUE_NUM];
} __packed;
Additionally replace old-style zero-element arrays with flexible arrays.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Pascal Terjan <pterjan@google.com>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: devel@driverdev.osuosl.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210806201208.2871467-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following sparse warning:
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c:798:32: warning: symbol 'tcb_desc' shadows an earlier one
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c:550:24: originally declared here
Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz>
Link: https://lore.kernel.org/r/20210527192149.29686-1-t@laumann.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following sparse warnings:
drivers/staging/rtl8192u/r8192U_core.c:2306:21: warning: symbol 'i' shadows an earlier one
drivers/staging/rtl8192u/r8192U_core.c:2254:13: originally declared here
drivers/staging/rtl8192u/r8192U_core.c:2371:29: warning: symbol 'i' shadows an earlier one
drivers/staging/rtl8192u/r8192U_core.c:2254:13: originally declared here
Signed-off-by: Cláudio Maia <clrrm@isep.ipp.pt>
Link: https://lore.kernel.org/r/20210514230459.15752-1-clrrm@isep.ipp.pt
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes the following W=1 kernel build warning(s):
drivers/staging/rtl8192u/r8192U_core.c:3714: warning: Function parameter or member 'dev' not described in 'UpdateRxPktTimeStamp8190'
drivers/staging/rtl8192u/r8192U_core.c:3714: warning: Function parameter or member 'stats' not described in 'UpdateRxPktTimeStamp8190'
drivers/staging/rtl8192u/r8192U_core.c:3714: warning: expecting prototype for Function(). Prototype was for UpdateRxPktTimeStamp8190() instead
drivers/staging/rtl8192u/r8192U_core.c:4314: warning: Function parameter or member 'dev' not described in 'UpdateReceivedRateHistogramStatistics8190'
drivers/staging/rtl8192u/r8192U_core.c:4314: warning: Function parameter or member 'stats' not described in 'UpdateReceivedRateHistogramStatistics8190'
drivers/staging/rtl8192u/r8192U_core.c:4314: warning: expecting prototype for Function(). Prototype was for UpdateReceivedRateHistogramStatistics8190() instead
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrea Merello <andrea.merello@gmail.com>
Cc: Jerry chuang <wlanfae@realtek.com>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210414181129.1628598-5-lee.jones@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The for-loop iterates with a u8 loop counter i and compares this
with the loop upper limit of riv->ieee80211->LinkDetectInfo.SlotNum
that is a u16 type. There is a potential infinite loop if SlotNum
is larger than the u8 loop counter. Fix this by making the loop
counter the same type as SlotNum.
Addresses-Coverity: ("Infinite loop")
Fixes: 8fc8598e61 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210407150308.496623-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver has a few disabled diagnostics, which can probably
just get removed, or might still be helpful:
drivers/staging/rtl8192u/r8192U_core.c: In function 'rtl8192_set_rxconf':
drivers/staging/rtl8192u/r8192U_core.c:767:45: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
767 | DMESG("NIC in promisc mode");
| ^
drivers/staging/rtl8192u/r8192U_core.c: In function 'rtl819xusb_rx_command_packet':
drivers/staging/rtl8192u/r8192U_core.c:883:80: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
883 | DMESG("rxcommandpackethandle819xusb: It is a command packet\n");
| ^
Changing the empty macro to no_printk() to shut up the compiler warnings
and add format string checking.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210322103545.704121-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpatch warnings from:
5dbdb2d87c ("checkpatch: prefer strscpy to strlcpy")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://lore.kernel.org/r/20210131172838.146706-11-memxor@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 453431a549 ("mm, treewide: rename kzfree() to
kfree_sensitive()") renamed kzfree() to kfree_sensitive(),
but it left a compatibility definition of kzfree() to avoid
being too disruptive.
Since then a few more instances of kzfree() have slipped in.
Just get rid of them and remove the compatibility definition
once and for all.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
