fix(tty): handle SendSignal error to prevent infinite loop

[GHOryy5]

The Issue
In CheckChange, the code ignores the error from SendSignal and returns ERESTARTSYS.
In Linux, TIF_SIGPENDING is set unconditionally, ensuring the loop breaks.
In gVisor, if SendSignal fails, no signal is pending. Returning ERESTARTSYS causes the syscall to restart immediately, leading to an infinite loop (DoS).

The Fix
I added an error check. If SendSignal fails, we return EIO to abort the syscall safely.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ayushr2]

@GHOryy5 could you sign the CLA?

In gVisor, if SendSignal fails, no signal is pending.

From what I can see, ProcessGroup.SendSignal() => tg.leader.sendSignalLocked() => Task.sendSignalTimerLocked(), which does enqueue the signal onto Task.pendingSignals.

Regarding TIF_SIGPENDING, we explicitly don't set it per this comment:

gvisor/pkg/sentry/kernel/tty.go

Lines 150 to 155 in 466fd4e

	// Note that Linux also unconditionally sets TIF_SIGPENDING on current,
	// but this isn't necessary in gVisor because the rationale given in
	// https://github.com/torvalds/linux/commit/040b6362d58f "tty: fix
	// leakage of -ERESTARTSYS to userland" doesn't apply: the sentry will
	// handle -ERESTARTSYS in kernel.runApp.execute() even if the
	// kernel.Task isn't interrupted.

This comment was first added in 0a41ea7. cc @nixprime @nlacasse

[nixprime]

In Linux, TIF_SIGPENDING is set unconditionally, ensuring the loop breaks.

Can you clarify what loop you're referring to? AFAIU, in Linux, TIF_SIGPENDING is required for the syscall exit path to observe that -ERESTARTSYS is being returned, but (without signal delivery to a handler) it will restart the syscall, resulting in the same behavior as in gVisor. Do you have a repro for the problem you're observing?