From 54eb79b6e80a13df1fbe08a6eb2578a6adb065dd Mon Sep 17 00:00:00 2001 From: Jing Chen Date: Sun, 8 Dec 2024 23:45:13 -0800 Subject: [PATCH] Acquire rlock when reading link address from the bridge. 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 --- pkg/tcpip/stack/bridge.go | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pkg/tcpip/stack/bridge.go b/pkg/tcpip/stack/bridge.go index 5692d164c..e3ef36a05 100644 --- a/pkg/tcpip/stack/bridge.go +++ b/pkg/tcpip/stack/bridge.go @@ -223,8 +223,8 @@ func (b *BridgeEndpoint) MaxHeaderLength() uint16 { // LinkAddress implements stack.LinkEndpoint.LinkAddress. func (b *BridgeEndpoint) LinkAddress() tcpip.LinkAddress { - b.mu.Lock() - defer b.mu.Unlock() + b.mu.RLock() + defer b.mu.RUnlock() return b.addr }