Incrementing the reference count of a packet as a means of granting ownership
is unsafe when the packet is shared across gorountines. The underlying buffer's
reference count is unchanged since it "technically" has the same owning
PacketBuffer, which means different goroutines operating on the underlying
buffer (and packet itself) race.
Clones are roughly as fast as IncRefs because the PacketBuffers allocate from
a pool and the underlying buffers are cloned with copy-on-write
semantics.
I've left IncRef in places where the original packet in obviously going out of
scope at the end of the function or in some tests.
Reported-by: syzbot+e026046f4bf8ad09ae1f@syzkaller.appspotmail.com
Reported-by: syzbot+559365d6050db4b30e0f@syzkaller.appspotmail.com
Reported-by: syzbot+63c78a2c88a5744c636b@syzkaller.appspotmail.com
PiperOrigin-RevId: 705676806
While testing docker-in-gvisor, we found that veth devices with enabled
CapabilityTXChecksumOffload don't work as expected. Packets issued from the
gvisor sandbox have incorrect checksum-s.
PiperOrigin-RevId: 651157380
The buffers from the buffer package are meant to be copy-on-write, but IP
headers still work with the underlying []byte, so writes are not tracked.
This allows data races in situations where packet buffers are shared
across goroutines.
PiperOrigin-RevId: 650429239
The veth devices are virtual Ethernet devices. They can act as
tunnels between network namespaces to create a bridge to a
physical network device in another namespace, but can also be
used as standalone network devices.
More information can be found here:
https://man7.org/linux/man-pages/man4/veth.4.html
PiperOrigin-RevId: 638853289
Lucas ManningandgVisor bot
Jing ChenandgVisor bot
Andrei VaginandgVisor bot
Jing Chen
Nayana BidariandgVisor bot