til_stream: update tap ptr in til_stream_tap new pipe case

The tap->ptr indirection must always be updated even when we're
the driver on a fresh pipe created by us.

This bug only triggers when the caller's tap was already
on-stream, without being the driver, and the driving tap/context
has since exited the stream, untapping itself which removed the
associated pipes - even the ones it didn't own but was driving.

In that scenario when pipe is created by the previously
non-driving tap on its first update since the driver exited, its
tap->ptr still points at the stale driver.  This manifested as a
UAF bug in that case.

The fix is a simple matter of always updating tap->ptr to reflect
the driving tap.

This also fixes the real bug causing 468c78e3 to crash, such that
the syncronous gc performed there shouldn't really be necessary
to prevent crashing.  It was the awkward overlapping existence of
contexts at the same path which produced the triggering lifecycle
pattern WRT driving taps at that path.

0 files changed, 0 insertions, 0 deletions