summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Tridgell <tridge@samba.org>1998-09-01 01:10:01 +0000
committerAndrew Tridgell <tridge@samba.org>1998-09-01 01:10:01 +0000
commit9fee8c2eb7bd05431cd9bcfbed3804c8ca1ee593 (patch)
tree871041741b486d15a27950bd6a72b74340d54ad6
parent3d9ec96de5e04e83abafe9c5d980bd39eee856ea (diff)
downloadsamba-9fee8c2eb7bd05431cd9bcfbed3804c8ca1ee593.tar.gz
check that a valid pipe is passed before doing a pipe close.
I made this change after getting a segv in reply_pipe_close(). The funny thing was that pipes_open was 1 and Pipes was NULL. That "can't happen" and suggests that we have a wild pointer somewhere. I suspect the rpc code, as I was playing with long share names (a share called "averylongusername") at the time and the logs show lots of srvsvc operations. I bet there is a buffer in the rpc code somewhere that is overflowing and trashing bits of the data segment.
-rw-r--r--source/smbd/pipes.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/source/smbd/pipes.c b/source/smbd/pipes.c
index fed5c2bd17c..97df3abfc35 100644
--- a/source/smbd/pipes.c
+++ b/source/smbd/pipes.c
@@ -121,6 +121,8 @@ int reply_pipe_read_and_X(char *inbuf,char *outbuf,int length,int bufsize)
char *data;
BOOL ok = False;
+ if (!p) return(ERROR(ERRDOS,ERRbadfid));
+
set_message(outbuf,12,0,True);
data = smb_buf(outbuf);
@@ -148,6 +150,8 @@ int reply_pipe_close(connection_struct *conn, char *inbuf,char *outbuf)
pipes_struct *p = get_rpc_pipe_p(inbuf,smb_vwv0);
int outsize = set_message(outbuf,0,0,True);
+ if (!p) return(ERROR(ERRDOS,ERRbadfid));
+
DEBUG(5,("reply_pipe_close: pnum:%x\n", p->pnum));
if (!close_rpc_pipe_hnd(p, conn)) return(ERROR(ERRDOS,ERRbadfid));