UBUNTU-CVE-2023-52611
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: sdio: Honor the host max_req_size in the RX path Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. This allows receiving a buffer that's larger than the hosts max_req_size (number of bytes which can be transferred in one MMC/SDIO transfer). As a result of this the skb_over_panic error is gone as the rtw88 driver is now able to receive more than 1536 bytes from the card (either because the incoming packet is larger than that or because multiple packets have been aggregated). In case of an receive errors (-EILSEQ has been observed by Lukas) we need to drain the remaining data from the card's buffer, otherwise the card will return corrupt data for the next rtw_sdio_read_port() call.
02 / AFFECTED SOFTWARE
Affected packages
29 explicit affected versions
1 explicit affected versions
16 explicit affected versions
7 explicit affected versions
26 explicit affected versions
37 explicit affected versions
10 explicit affected versions
10 explicit affected versions
13 explicit affected versions
13 explicit affected versions
37 explicit affected versions
8 explicit affected versions
4 explicit affected versions
8 explicit affected versions
23 explicit affected versions
7 explicit affected versions
10 explicit affected versions
33 explicit affected versions
16 explicit affected versions
12 explicit affected versions
38 explicit affected versions
51 explicit affected versions
13 explicit affected versions
10 explicit affected versions
9 explicit affected versions
10 explicit affected versions
7 explicit affected versions
13 explicit affected versions
1 explicit affected versions
10 explicit affected versions
8 explicit affected versions
21 explicit affected versions
6 explicit affected versions
13 explicit affected versions
12 explicit affected versions
1 explicit affected versions
7 explicit affected versions
12 explicit affected versions
9 explicit affected versions
7 explicit affected versions
26 explicit affected versions
23 explicit affected versions
14 explicit affected versions
5 explicit affected versions
10 explicit affected versions
3 explicit affected versions
26 explicit affected versions
12 explicit affected versions
44 explicit affected versions
4 explicit affected versions
4 explicit affected versions
16 explicit affected versions
9 explicit affected versions
12 explicit affected versions
13 explicit affected versions
7 explicit affected versions
7 explicit affected versions
10 explicit affected versions
14 explicit affected versions
18 explicit affected versions
3 explicit affected versions
16 explicit affected versions
43 explicit affected versions
7 explicit affected versions
11 explicit affected versions
9 explicit affected versions
35 explicit affected versions
12 explicit affected versions
10 explicit affected versions
6 explicit affected versions
12 explicit affected versions
50 explicit affected versions
12 explicit affected versions
27 explicit affected versions
12 explicit affected versions
7 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: sdio: Honor the host max_req_size in the RX path Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth combo card. The error he observed is identical to what has been fixed in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem. Lukas found that disabling or limiting RX aggregation works around the problem for some time (but does not fully fix it). In the following discussion a few key topics have been discussed which have an impact on this problem: - The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller which prevents DMA transfers. Instead all transfers need to go through the controller SRAM which limits transfers to 1536 bytes - rtw88 chips don't split incoming (RX) packets, so if a big packet is received this is forwarded to the host in it's original form - rtw88 chips can do RX aggregation, meaning more multiple incoming packets can be pulled by the host from the card with one MMC/SDIO transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation and BIT_EN_PRE_CALC makes the chip honor the limits more effectively) Use multiple consecutive reads in rtw_sdio_read_port() and limit the number of bytes which are copied by the host from the card in one MMC/SDIO transfer. This allows receiving a buffer that's larger than the hosts max_req_size (number of bytes which can be transferred in one MMC/SDIO transfer). As a result of this the skb_over_panic error is gone as the rtw88 driver is now able to receive more than 1536 bytes from the card (either because the incoming packet is larger than that or because multiple packets have been aggregated). In case of an receive errors (-EILSEQ has been observed by Lukas) we need to drain the remaining data from the card's buffer, otherwise the card will return corrupt data for the next rtw_sdio_read_port() call.
05 / REFERENCES
Further evidence
- https://git.kernel.org/linus/00384f565a91c08c4bedae167f749b093d10e3fe
- https://git.kernel.org/stable/c/00384f565a91c08c4bedae167f749b093d10e3fe
- https://git.kernel.org/stable/c/0e9ffff72a0674cd6656314dbd99cdd2123a3030
- https://git.kernel.org/stable/c/5b5ddf21b978ec315cab9d9e7e6ac7374791a8c7
- https://ubuntu.com/security/CVE-2023-52611
- https://ubuntu.com/security/notices/USN-6818-1
- https://ubuntu.com/security/notices/USN-6818-2
- https://ubuntu.com/security/notices/USN-6818-3
- https://ubuntu.com/security/notices/USN-6818-4
- https://ubuntu.com/security/notices/USN-6819-1
- https://ubuntu.com/security/notices/USN-6819-2
- https://ubuntu.com/security/notices/USN-6819-3
- https://ubuntu.com/security/notices/USN-6819-4
- https://www.cve.org/CVERecord?id=CVE-2023-52611