cve/2024/CVE-2024-41066.md

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

### Description

In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Add tx check to prevent skb leakBelow is a summary of how the driver stores a reference to an skb duringtransmit:    tx_buff[free_map[consumer_index]]->skb = new_skb;    free_map[consumer_index] = IBMVNIC_INVALID_MAP;    consumer_index ++;Where variable data looks like this:    free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]                                               	consumer_index^    tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]The driver has checks to ensure that free_map[consumer_index] pointed toa valid index but there was no check to ensure that this index pointedto an unused/null skb address. So, if, by some chance, our free_map andtx_buff lists become out of sync then we were previously risking anskb memory leak. This could then cause tcp congestion control to stopsending packets, eventually leading to ETIMEDOUT.Therefore, add a conditional to ensure that the skb address is null. Ifnot then warn the user (because this is still a bug that should bepatched) and free the old pointer to prevent memleak/tcp problems.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/fkie-cad/nvd-json-data-feeds