[netdrvr] fix skb_padto bugs introduced when skb_padto was introduced
It seems that skb_padto security fixes in 2.4 and 2.5 trying to fix "CAN-2003-0001:Multiple ethernet NID device drivers do not pad frames with null bytes", do not put the skb_padto blocks in proper places in the 3c527, eth16i, fmv18x, seeq8005, yellowfin device drivers. In case a driver calls skb_padto(), it is possible that the space available in the original skb buffer tailroom is less than the space to pad. In this case, in short, the skb_padto() will create a new skb buffer, copy data from the original skb buffer to a new skb buffer, free the original buffer, and finally return the new buffer. If this happens to the aforementioned device drivers, they come to point to wrong data. And, for 3c527 and yellowfin, the drivers can unexpectedly double free the original skb buffers since they still point to the original skb buffers. The attached patch against 2.4.23pre1 fixes these issues.
Showing
Please register or sign in to comment