cve/2024/CVE-2024-56593.md

### [CVE-2024-56593](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56593)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2%3C%20342f87d263462c2670b77ea9a32074cab2ac6fa1%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = 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 SKBis 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 returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/cku-heise/euvd-api-doc