Code paths setting gso_size
Subsystems (2)
This is a new thread dedicated to a specific topic, spawned by an earlier discussion. I've CC'd only those that participated recently.
I've written:
# In this particular instance, I suggest that you take a look at all the
# places that gso_size is set, and cross index with all the code paths that # place these TCP headers onto the txq without a check of doff -- as I did! # # I'll specifically mention the tun and virtio_net devices, but I'm also # particularly concerned with af_packet.c and skbuff.c -- and the general # problem with inet_lro.c, too. # # Amazingly enough, folks sometimes use Linux for routers.... #
Eric (and David) have written:
# Only *locally* generated trafic by linux kernel can enter this path. #
So, let us begin with the tun device, and work our way through the others.
Quoted 15 lines · William Allen Simpson
This is a new thread dedicated to a specific topic, spawned by an earlier discussion. I've CC'd only those that participated recently.
I've written:
# In this particular instance, I suggest that you take a look at all the# places that gso_size is set, and cross index with all the code paths that # place these TCP headers onto the txq without a check of doff -- as I did! # # I'll specifically mention the tun and virtio_net devices, but I'm also # particularly concerned with af_packet.c and skbuff.c -- and the general # problem with inet_lro.c, too. # # Amazingly enough, folks sometimes use Linux for routers.... #
Quoted 6 lines
Eric (and David) have written:
# Only *locally* generated trafic by linux kernel can enter this path. #So, let us begin with the tun device, and work our way through the others.
Thats a really good idea William, I'll start another thread to study all the paths setting skb->len to a possible wrong value. But I'll do this in my own time, and if I find something, I'll post a patch.
Sure we'll find some bugs by this studies, since in average we find 100 bugs per month, and introduce 90 new ones, thanks God for this.