In cases where sendRaw runs concurrently with a setsocketopt that sets
the experiment option, it's possible to read a zero experiment option when
adjusting reserved header space and a non-zero experiment option when
sending the packet. This causes the sentry to panic when adding the IPv6
header.
PiperOrigin-RevId: 723303802
There is a race in the test between WritePacketToRemote and FindFDBEntry, even
though it rarely happens, we just enforce FindFDBEntry to wait for
WritePacketToRemote's completion here.
PiperOrigin-RevId: 721747159
- Added a new Stats() method in inet.Stack to get the saved stats
during restore.
- Mark stack.nic, tcpip.Route and stack.addressState structs as "nosave".
These fields should not be saved because the IP addresses and routes can
change during restore and new configuration of routes and IP addresses will be
extracted from the restore spec and initialized in the saved stack.
- Changes in Restore() method in icmp, udp, tcp, packet and raw endpoint files
to support save restore of these endpoints. These changes are flag guarded by
the TESTONLY-save-restore-netstack flag.
PiperOrigin-RevId: 707639274
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
insecureRNG and secureRNG stack fields are restored in stack.afterLoad()
tcp processor fields are restored in tcp endpoint.Restore()
PiperOrigin-RevId: 704477536
The annotations are a bit messy, but:
- It's worth it for the safety.
- Annotations could be removed by flattening tcp.Endpoint. Its current layout
is, I believe, related to the old "protocol goroutine" architecture.
- The annotations could be cut down by improving checklocksalias.
PiperOrigin-RevId: 704315794
It happens along with the other issue when the veth device buffer is full,
then the task is stuck and still have the bridge's lock (RLock) via
DeliverNetworkPacket. When the second task reads the bridge's MAC address,
it waits forever for the first task to release the rlock. Using RLock can
allow the concurrent access to the MAC address, it dones't have to be
blocked until the messages are sent.
Reported-by: syzbot+1d6d1d8f47eae4e308dc@syzkaller.appspotmail.com
PiperOrigin-RevId: 704163976
Lucas ManningandgVisor bot
Nayana BidariandgVisor bot
Ayush RanjanandgVisor bot
Jing ChenandgVisor bot
Andrei Vagin
Kevin KrakauerandgVisor bot