Re: Re[2]: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)

2001-08-07 Thread Boris Popov

On Sat, 4 Aug 2001, Dimitry Andric wrote:

 Okay, this patch seems to solve the panic problem for me. On the
 previously crashing box, I cvsup'd today (to 4.4-PRERELEASE) and
 rebuilt everything, including the kernel with your patch, and the
 smbfs-1.4.1 port. Since then, I haven't been able to get it to crash
 anymore. :) (Keeping my fingers crossed.)

Fine, then thats it! Many thanks to Conrad Minshall who found this
bug. There is also some more fixes to merge from Darwin project.

 1. When I mount_smbfs(8) a share, the mountpoint is owned by
 root:wheel and mode 755 by default. However, as a normal user I can
 _create_ files in this mountpoint, but not delete them! I would
 suppose that a normal user doesn't have write access with mode 755?

Yes, this is a known bug and there is open PR on it. Fix is ready,
and will be committed after I get access to that hard disk again.

--
Boris Popov
http://www.butya.kz/~bp/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message



Re[2]: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)

2001-08-04 Thread Dimitry Andric

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2001-08-03 at 17:04:37 Boris Popov wrote:

BP Please try the attached patch. It fixes a nasty buffer overflow
BP which may cause this panic.

Okay, this patch seems to solve the panic problem for me. On the
previously crashing box, I cvsup'd today (to 4.4-PRERELEASE) and
rebuilt everything, including the kernel with your patch, and the
smbfs-1.4.1 port. Since then, I haven't been able to get it to crash
anymore. :) (Keeping my fingers crossed.)

I have some other remarks, though, if you don't mind:

1. When I mount_smbfs(8) a share, the mountpoint is owned by
root:wheel and mode 755 by default. However, as a normal user I can
_create_ files in this mountpoint, but not delete them! I would
suppose that a normal user doesn't have write access with mode 755?

2. I searched for an answer to this phenomenon in the mount_smbfs(8)
manpage, and it says with the -M option: Assign access rights to the
newly created connection.  See nsmb(8) for theory.  However, there's
no nsmb(8) manpage to be found anywhere, at least not on a freshly
rebuilt system. Maybe this manpage was left out while integrating
smbfs into the main kernel sources?

Cheers,
- --
Dimitry Andric [EMAIL PROTECTED]
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBO2wjgrBeowouIJajEQLtXwCg16tS7WhijvzFke/TkP33JDArXeMAoIgz
FFhftYgBLJGr3IW4shs3H3Q0
=2Swi
-END PGP SIGNATURE-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message



Re: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)

2001-08-03 Thread Boris Popov

On Wed, 25 Jul 2001, Tim Zingelman wrote:

 This is a known bug, but not fixed.  I worked with the maintainer, Boris
 Popov on it a little, but in my case it took some time between the mount
 and the panic, and I was not able to give him login access to the
 machines involved.  As a result it remains unfixed.  If you have a case
 that panics immediately and can work with him, I think he would be
 interested in getting this fixed.  (I know I would :)

Please try the attached patch. It fixes a nasty buffer overflow
which may cause this panic.

  I'd recommend contacting the smbfs maintainer. It seems the kernel
  module for smbfs is now integrated into the main sources, but you
  still need to install a port. So I'm guessing it's now in some sort of
  transitional status (and thus quite unstable).

Hear, hear :) All userland code for smbfs was planned to be
included before 4.4 comes out. But, life is life - it has its own plans,
and I hope to finish import after 4.4...

--
Boris Popov
http://www.butya.kz/~bp/


Index: smb.h
===
RCS file: /home/ncvs/src/sys/netsmb/smb.h,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 smb.h
--- smb.h   2001/05/22 08:32:33 1.1.2.1
+++ smb.h   2001/08/03 13:32:25
@@ -68,7 +68,7 @@
  */
 #defineSMB_SIGNATURE   \xFFSMB
 #defineSMB_SIGLEN  4
-#defineSMB_HDRMID(p)   (*(u_short*)((u_char*)(p) + 30))
+#defineSMB_HDRMID(p)   (letohs(*(u_short*)((u_char*)(p) + 30)))
 #defineSMB_HDRLEN  32
 /*
  * bits in the smb_flags field
Index: smb_crypt.c
===
RCS file: /home/ncvs/src/sys/netsmb/smb_crypt.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 smb_crypt.c
--- smb_crypt.c 2001/05/22 08:32:33 1.1.2.1
+++ smb_crypt.c 2001/08/03 13:32:25
@@ -120,7 +120,7 @@
int len;
 
len = strlen(apwd);
-   unipwd = malloc(len * sizeof(u_int16_t), M_SMBTEMP, M_WAITOK);
+   unipwd = malloc((len + 1) * sizeof(u_int16_t), M_SMBTEMP, M_WAITOK);
/*
 * S21 = concat(MD4(U(apwd)), zeros(5));
 */
Index: smb_rq.c
===
RCS file: /home/ncvs/src/sys/netsmb/smb_rq.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 smb_rq.c
--- smb_rq.c2001/05/22 08:32:33 1.1.2.1
+++ smb_rq.c2001/08/03 13:32:25
@@ -238,7 +238,7 @@
bcnt = rqp-sr_rq.mb_count;
if (bcnt  0x)
SMBERROR(byte count too large (%d)\n, bcnt);
-   *rqp-sr_bcount = bcnt;
+   *rqp-sr_bcount = htoles(bcnt);
 }
 
 int