| Message ID | 20241105204011.1603148-1-norbert.vanbolhuis@ev-box.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | wifi: brcmfmac: Fix oops due to NULL pointer dereference in 'brcmf_sdiod_sglist_rw' | expand |
Norbert van Bolhuis <nvbolhuis@gmail.com> writes: > This patch fixes a NULL pointer dereference bug in brcmfmac that occurs > when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs > are sent from the pkt queue. > > The problem is the number of entries in the pre-allocated sgtable, it is > nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. > Given the default [rt]xglom_size=32 it's actually 35 which is too small. > Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB > is added for each original SKB if tailroom isn't enough to hold tail_pad. > At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" > in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return > NULL and this causes the oops. BTW it would be good to fix (in a separate patch) the sg handling so that the kernel won't oops when sg entries rung. That's not really robust behaviour. > The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle > the worst-case. > Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 > additional bytes of memory. s-o-b missing, please read our documentation from the link below.
On 11/7/2024 9:07 AM, Kalle Valo wrote: > Norbert van Bolhuis <nvbolhuis@gmail.com> writes: > >> This patch fixes a NULL pointer dereference bug in brcmfmac that occurs >> when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs >> are sent from the pkt queue. >> >> The problem is the number of entries in the pre-allocated sgtable, it is >> nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. >> Given the default [rt]xglom_size=32 it's actually 35 which is too small. >> Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB >> is added for each original SKB if tailroom isn't enough to hold tail_pad. >> At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" >> in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return >> NULL and this causes the oops. > > BTW it would be good to fix (in a separate patch) the sg handling so > that the kernel won't oops when sg entries rung. That's not really > robust behaviour. > >> The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle >> the worst-case. >> Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 >> additional bytes of memory. > > s-o-b missing, please read our documentation from the link below. I have not seen the actual patch. Which mailing list was it sent to? Regards, Arend
Arend van Spriel <arend.vanspriel@broadcom.com> writes: > On 11/7/2024 9:07 AM, Kalle Valo wrote: > >> Norbert van Bolhuis <nvbolhuis@gmail.com> writes: >> >>> This patch fixes a NULL pointer dereference bug in brcmfmac that occurs >>> when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs >>> are sent from the pkt queue. >>> >>> The problem is the number of entries in the pre-allocated sgtable, it is >>> nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. >>> Given the default [rt]xglom_size=32 it's actually 35 which is too small. >>> Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB >>> is added for each original SKB if tailroom isn't enough to hold tail_pad. >>> At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" >>> in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return >>> NULL and this causes the oops. >> BTW it would be good to fix (in a separate patch) the sg handling so >> that the kernel won't oops when sg entries rung. That's not really >> robust behaviour. >> >>> The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle >>> the worst-case. >>> Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 >>> additional bytes of memory. >> s-o-b missing, please read our documentation from the link below. > > I have not seen the actual patch. Which mailing list was it sent to? Only to linux-wireless, adding brcm80211 now. But the patch is in patchwork: https://patchwork.kernel.org/project/linux-wireless/patch/20241105204011.1603148-1-norbert.vanbolhuis@ev-box.com/
On 11/7/2024 10:51 AM, Kalle Valo wrote: > Arend van Spriel <arend.vanspriel@broadcom.com> writes: > >> On 11/7/2024 9:07 AM, Kalle Valo wrote: >> >>> Norbert van Bolhuis <nvbolhuis@gmail.com> writes: >>> >>>> This patch fixes a NULL pointer dereference bug in brcmfmac that occurs >>>> when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs >>>> are sent from the pkt queue. >>>> >>>> The problem is the number of entries in the pre-allocated sgtable, it is >>>> nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. >>>> Given the default [rt]xglom_size=32 it's actually 35 which is too small. >>>> Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB >>>> is added for each original SKB if tailroom isn't enough to hold tail_pad. >>>> At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" >>>> in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return >>>> NULL and this causes the oops. >>> BTW it would be good to fix (in a separate patch) the sg handling so >>> that the kernel won't oops when sg entries rung. That's not really >>> robust behaviour. >>> >>>> The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle >>>> the worst-case. >>>> Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 >>>> additional bytes of memory. >>> s-o-b missing, please read our documentation from the link below. >> >> I have not seen the actual patch. Which mailing list was it sent to? > > Only to linux-wireless, adding brcm80211 now. But the patch is in > patchwork: > > https://patchwork.kernel.org/project/linux-wireless/patch/20241105204011.1603148-1-norbert.vanbolhuis@ev-box.com/ Thanks, Kalle I am also subscribed to linux-wireless, but search in thunderbird client did not come up with it. Thanks for the patchwork link. I should have checked that first. Gr. AvS
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 17f6b33beabd..42d991d9f8cb 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -770,7 +770,7 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev *sdiodev) nents = max_t(uint, BRCMF_DEFAULT_RXGLOM_SIZE, sdiodev->settings->bus.sdio.txglomsz); - nents += (nents >> 4) + 1; + nents *= 2; WARN_ON(nents > sdiodev->max_segment_count);