Remove the explicit u16 casts for u16 argument in the function call. This
function has declared its parameter to be of type u16, so the argument
given to that parameter will be automatically coerced to u16. Therefore,
an explicit cast is unnecessary.
Signed-off-by: Solomon Tan <wjsota@gmail.com>
Link: https://lore.kernel.org/r/20220423130150.161903-6-wjsota@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the unnecessary explicit u8 casts for u8 arguments in function
calls. These functions have declared their parameters to be of type u8,
so the arguments given to those parameters will be automatically coerced
to u8. Therefore, an explicit cast is unnecessary.
Signed-off-by: Solomon Tan <wjsota@gmail.com>
Link: https://lore.kernel.org/r/20220423130150.161903-3-wjsota@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The rtllib_rx_assoc_resp() function has a signedness bug because it's
a declared as a u16 but it return -ENOMEM. When you look at it more
closely it returns a mix of error codes including 0xcafe, -ENOMEM, and
a->status which is WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG. This is a mess.
Clean it up to just return standard kernel error codes. We can print
out the a->status before returning a regular error code. The printks
in the caller need to be adjusted as well.
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Haowen Bai <baihaowen@meizu.com>
Link: https://lore.kernel.org/r/1650529277-7893-1-git-send-email-baihaowen@meizu.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a deadlock in rtllib_beacons_stop(), which is shown
below:
(Thread 1) | (Thread 2)
| rtllib_send_beacon()
rtllib_beacons_stop() | mod_timer()
spin_lock_irqsave() //(1) | (wait a time)
... | rtllib_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, rtllib_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/20220417141641.124388-1-duoming@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tasklets have long been deprecated as being too heavy on the system
by running in irq context - and this is not a performance critical
path. If a higher priority process wants to run, it must wait for
the tasklet to finish before doing so.
rtllib_sta_ps() and ieee80211_sta_ps() will now run in process context
and have further concurrency (tasklets being serialized among themselves),
but this is done holding the ieee->lock, so it should be fine.
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Link: https://lore.kernel.org/r/20220411151620.129178-7-dave@stgolabs.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull staging driver updates from Greg KH:
"Here's the big set of staging driver updates for 5.17-rc1
Nothing major in here at all, just lots and lots of tiny cleanups.
Overall more code was removed than added, which is always nice, but
not a huge change.
Majority of the work happened in the r8188eu driver, that had hundreds
of cleanups happen on it, but almost all other staging drivers had
cleanups as well. No new functionality was added, cleanups only.
All of these have been in linux-next for a while with no reported
problems"
* tag 'staging-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (308 commits)
staging: r8188eu: rename camelcase variable uintPeerChannel
staging: r8188eu: make BW20_24G_Diff a 1-D array
staging: r8188eu: make OFDM_24G_Diff a 1-D array
staging: r8188eu: BW40_24G_Diff is set but not used
staging: r8188eu: CCK_24G_Diff is set but not used
staging: r8188eu: make Index24G_BW40_Base a 1-D array
staging: r8188eu: make Index24G_CCK_Base a 1-D array
staging: r8188eu: rfPath is always 0
staging: r8188eu: remove unneeded parameter from rtl8188e_SetHalODMVar
staging: pi433: add comment to rx_lock mutex definition
staging: pi433: fix frequency deviation check
staging: vc04_services: rename BM2835 to BCM2835 in headers comments
staging: vc04_services: rename string literal containing bm2835_* to bcm2835*_
staging: vc04_services: rename variables containing bm2835_* to bcm2835_*
staging: vc04_services: rename functions containing bm2835_* to bcm2835_*
staging: vc04_services: rename structures bm2835_mmal_dev and bm2835_mmal_v4l2_ctrl
staging: greybus: audio: Check null pointer
staging: r8188eu: add spaces around P2P_AP_P2P_CH_SWITCH_PROCESS_WK
staging: r8188eu: turbo scan is always off for r8188eu
staging: r8188eu: cmd_issued_cnt is set but not used
...
In following patches, dev_watchdog() will no longer stop all queues.
It will read queue->trans_start locklessly.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 406f42fa0d ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Convert staging from ether_addr_copy() to eth_hw_addr_set():
@@
expression dev, np;
@@
- ether_addr_copy(dev->dev_addr, np)
+ eth_hw_addr_set(dev, np)
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20211019171243.1412240-3-kuba@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).
rtllib_read_qos_param_element() copies a struct rtllib_info_element
into a struct rtllib_qos_information_element, but is actually wanting to
copy into the larger struct rtllib_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 rtllib_info_element {
u8 id;
u8 len;
u8 data[];
} __packed;
struct rtllib_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 rtllib_qos_parameter_info {
struct rtllib_qos_information_element info_element;
u8 reserved;
struct rtllib_qos_ac_parameter ac_params_record[QOS_QUEUE_NUM];
} __packed;
Cc: Darshan D V <darshandv10@gmail.com>
Cc: Aditya Srivastava <yashsri421@gmail.com>
Cc: devel@driverdev.osuosl.org
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210806201106.2871169-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. The safe replacement is strscpy().
It is also dangerous a strcpy() followed by a strcat(). In this case,
refactor the code using scnprintf() and avoid this combination.
Signed-off-by: Len Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210723173216.12157-1-len.baker@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 bytes of data using memcpy():
(In rtllib_rx.c:1972)
memcpy(network->CcxRmState, &info_element->data[4], 2)
With "info_element->data[]" being a u8 array, if 2 bytes are written
into "CcxRmState" (whose one element is u16 size), then the 2 u8
elements from "data[]" gets squashed and written into the first element
("CcxRmState[0]") while the second element ("CcxRmState[1]") is never
fed with any data.
Same in file rtllib_rx.c:2522:
memcpy(dst->CcxRmState, src->CcxRmState, 2);
The above line duplicates "src" data to "dst" but only writes 2 bytes
(and not 4, which is the actual size). Again, only 1st element gets the
value while the 2nd element remains uninitialized.
This later makes operations done with CcxRmState unpredictable in the
following lines as the 1st element is having a squashed number while the
2nd element is having an uninitialized random number.
rtllib_rx.c:1973: if (network->CcxRmState[0] != 0)
rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07;
network->MBssidMask is also of type u8 and not u16.
Fix this by changing the type of "CcxRmState" from u16 to u8 so that the
data written into this array and read from it make sense and are not
random values.
NOTE: The wrong initialization of "CcxRmState" can be seen in the
following commit:
commit ecdfa44610 ("Staging: add Realtek 8192 PCI wireless driver")
The above commit created a file `rtl8192e/ieee80211.h` which used to
have the faulty line. The file has been deleted (or possibly renamed)
with the contents copied in to a new file `rtl8192e/rtllib.h` along with
additional code in the commit 94a799425e (tagged in Fixes).
Fixes: 94a799425e ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
Cc: stable@vger.kernel.org
Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com>
Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
