On Wed, Oct 20, 2021 at 12:44:01PM -0500, Eric W. Biederman wrote:
> The function try_to_clear_window_buffer is only called from
> rtrap_32.c. After it is called the signal pending state is retested,
nit: rtrap_32.S
> and signals are handled if TIF_SIGPENDING is set. This allows
> try_to_clear_window_buffer to call force_fatal_signal and then rely on
> the signal being delivered to kill the process, without any danger of
> returning to userspace, or otherwise using possible corrupt state on
> failure.
The TIF_SIGPENDING test happens in do_notify_resume(), though I see
other code before that:
...
call try_to_clear_window_buffer
add %sp, STACKFRAME_SZ, %o0
b signal_p
...
signal_p:
andcc %g2, _TIF_DO_NOTIFY_RESUME_MASK, %g0
bz,a ret_trap_continue
ld [%sp + STACKFRAME_SZ + PT_PSR], %t_psr
mov %g2, %o2
mov %l6, %o1
call do_notify_resume
Will the ret_trap_continue always be skipped?
Also I see the "tp->w_saved = 0" never happens due to the "return" in
try_to_clear_window_buffer. Is that okay? Only synchronize_user_stack()
uses it, and that could be called in do_sigreturn(). Should the "return"
be removed?
--
Kees Cook
