Created attachment 72238 [details]
User space code demonstrating the issue into a loopback scenario

This problem appears to occur both with sending packets over a network and with the loopback device, though the specifics vary slightly. The simplest case is a loopback. When task A sends a big buffer to task B, an sk_buff will be set up with the mapped buffer as sk_bufs data. The problem is that vmsplice appears to return to task A at that point, even though task B may not have read any or all of the data. When task A writes to the buffer, it overwrites the data being sent to task B, even though task B has not read the data. Thus, task B gets corrupted data.

The scenario with TCP appears similar, but can be worse because of the requirement to keep the buffer around for quite a while in order to retransmitted if necessary.

So long as task A is writing data into the buffer area intended for task B, this is only a data corruption issue. This may not be the case, however. Should task A write data intended for some other use into the memory that had been used for the buffer, that data can leak to task B.

One possible fix would be to add the ability to support sk_buff- or page-specific notifiers to handle buffer freeing, rather like Ian Campbell's recent proposal (http://lwn.net/Articles/474791/)