A timed brlock with 2 locks comes in and the second one blocks,
file is closed. smbd_cancel_pending_lock_requests_by_fid sets
blr->fsp to NULL. reply_lockingX_error (called via
MSG_SMB_BLOCKING_LOCK_CANCEL) deferences blr->fsp because
blr->lock_num==1 (the second one blocked).
This patch fixes the bug by only undoing the locks if fsp!=NULL.
fsp==NULL is the close case where everything is undone anyway.
Thanks to Peter Somogyi, somogyi@hu.ibm.com for this bug report.
Fix bug #9084 - Blocking lock followed by close can crash smbd.
(cherry picked from commit
d80fbbea8ec77c0bda0e3fb9eaed2f170784ea7d)
obtained first.
*****************************************************************************/
obtained first.
*****************************************************************************/
-static void reply_lockingX_error(struct blocking_lock_record *blr, NTSTATUS status)
+static void undo_locks_obtained(struct blocking_lock_record *blr)
{
files_struct *fsp = blr->fsp;
uint16 num_ulocks = SVAL(blr->req->vwv+6, 0);
{
files_struct *fsp = blr->fsp;
uint16 num_ulocks = SVAL(blr->req->vwv+6, 0);
-
- generic_blocking_lock_error(blr, status);
}
/****************************************************************************
}
/****************************************************************************
switch(blr->req->cmd) {
case SMBlockingX:
switch(blr->req->cmd) {
case SMBlockingX:
- reply_lockingX_error(blr, status);
- break;
+ /*
+ * This code can be called during the rundown of a
+ * file after it was already closed. In that case,
+ * blr->fsp==NULL and we do not need to undo any
+ * locks, they are already gone.
+ */
+ if (blr->fsp != NULL) {
+ undo_locks_obtained(blr);
+ }
+ generic_blocking_lock_error(blr, status);
+ break;
case SMBtrans2:
case SMBtranss2:
reply_nterror(blr->req, status);
case SMBtrans2:
case SMBtranss2:
reply_nterror(blr->req, status);