[PATCH] Patchset for bug #10344 - SessionLogoff on a signed connection with an outstanding notify request crashes smbd.

[Jeremy Allison]

On Wed, Feb 26, 2014 at 07:44:15PM +0100, Stefan (metze) Metzmacher wrote:
> Am 26.02.2014 19:05, schrieb Jeremy Allison:
> > On Wed, Feb 26, 2014 at 07:01:23AM +0100, Stefan (metze) Metzmacher wrote:
> >>
> >> I think we need to solve this a bit more generic,
> >> a close on a file handle will also trigger this
> > 
> > OK, more thoughts :-).
> > 
> > Actually a close on a file handle won't trigger
> > a signing crash. Currently a close doesn't cancel
> > out a pending notify and we should (I'm sure Windows
> > does) but all that will occur is the notify
> > will notice an invalid handle once it gets
> > scheduled after the close.
> > 
> > I can add a follow-up patch here that
> > walks the pending request list and
> > issues tevent_req_cancel()'s for all
> > outstanding notifies on the fsp being
> > closed, in the same way I'm doing in
> > the patchset for tdis (or using the
> > tevent_wait_XXX functions that the
> > current asyncIO uses).
> > 
> > Remember it's only logoff that tears
> > down the signing data, so that's the
> > only urgent one for crash fixes. The
> > tdis part of my fix is for correctness
> > (Windows cancels the notify on tdis)
> > but won't cause a crash due to missing
> > signing pointers.
> 
> If it's only the signing can't we use the
> somehow set the req->last_key or req->first_key (or similar) field
> of the pending request?
> 
> If so is it enough to do that just for session for now
> in order to fix the urgent bug?

Yeah I actually had a quick hacky fix that I did
first (it's in one of the superceeded attachments
in the bug report), however once I realized that
Windows correctly cancels the notify first I thought
you'd never accept the hack fix and so decided
to do it 'right' instead :-).

Jeremy.