summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/socket/netlink/socket.go
diff options
context:
space:
mode:
authornewmanwang <wcs1011@gmail.com>2018-09-14 17:38:16 -0700
committerShentubot <shentubot@google.com>2018-09-14 17:39:25 -0700
commitde5a590ee203b4ee217da68dbec8e58a7753e520 (patch)
tree528840952692a76a9559806086f69bdb6da94ea8 /pkg/sentry/socket/netlink/socket.go
parent75c66f871b56a8f4e83dc9ccec29cf3d2c38fea4 (diff)
Avoid reuse of pending SignalInfo objects
runApp.execute -> Task.SendSignal -> sendSignalLocked -> sendSignalTimerLocked -> pendingSignals.enqueue assumes that it owns the arch.SignalInfo returned from platform.Context.Switch. On the other hand, ptrace.context.Switch assumes that it owns the returned SignalInfo and can safely reuse it on the next call to Switch. The KVM platform always returns a unique SignalInfo. This becomes a problem when the returned signal is not immediately delivered, allowing a future signal in Switch to change the previous pending SignalInfo. This is noticeable in #38 when external SIGINTs are delivered from the PTY slave FD. Note that the ptrace stubs are in the same process group as the sentry, so they are eligible to receive the PTY signals. This should probably change, but is not the only possible cause of this bug. Updates #38 Original change by newmanwang <wcs1011@gmail.com>, updated by Michael Pratt <mpratt@google.com>. Change-Id: I5383840272309df70a29f67b25e8221f933622cd PiperOrigin-RevId: 213071072
Diffstat (limited to 'pkg/sentry/socket/netlink/socket.go')
0 files changed, 0 insertions, 0 deletions