After the upgrade to 3.0.27 or applying the patch for CVE-2007-4572 to 3.0.26a I'm no longer able to mount shares.
PANIC (pid 10736): push_ascii - dest_len == -1
BACKTRACE: 14 stack frames:
#0 smbd(log_stack_trace+0x2d) [0x80214bcd]
#1 smbd(smb_panic+0x5d) [0x80214cfd]
#2 smbd [0x801fda1c]
#3 smbd(push_string_fn+0x44) [0x801fda64]
#4 smbd(srvstr_push_fn+0xa5) [0x800aa8c5]
#5 smbd [0x80095d10]
#6 smbd [0x80097566]
#7 smbd(handle_trans2+0x180) [0x80097d10]
#8 smbd(reply_trans2+0x69c) [0x8009ddac]
#9 smbd [0x800b9e8e]
#10 smbd(smbd_process+0x84b) [0x800bb26b]
#11 smbd(main+0xa18) [0x802c5d78]
#12 /lib/libc.so.6(__libc_start_main+0xe0) [0xb7b9cf90]
#13 smbd [0x80044aa1]
push_sec_ctx(500, 100) : sec_ctx_stack_ndx = 1
push_conn_ctx(100) : conn_ctx_stack_ndx = 0
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
NT user token: (NULL)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
dumping core in /var/log/samba/cores/smbd
Please provide more information about your environment,
configuration, details of how to reproduce the crash, and
an attachment (not inline) of level 10 debug logs from
Jeremy, If you cannot take a look at this, please pass off
to Volker or possibly Simo.
Looking at it right now, lets see if I can reproduce it without more info.
Hmmm. Just compiled 14ecfecb (v3-0-test), with security=user I can connect from Windows XP just fine.
So I need more info like smb.conf, environment and a full debug level 10 log of the failure.
Created attachment 2974 [details]
smbd log file, debug level 10
Created attachment 2975 [details]
Debug log and smb.conf attached. I'm trying to mount from a Linux client not from Windows.
Samba built form sources, gcc 4.2.2, glibc 2.7.1.
I thought this was a bug with 3.0.27, not 3.0.26a?
Yep, it is. 3.0.27 and 3.0.26a with the securtity patches are affected. Plain 3.0.26a works fine.
Ok, i found the culprit(s) in the code.
I am going to prepare a patch...
Analysis of the problem:
The panic was introduced by the patch for CVE-2007-4572:
push_ascii() now panics when called with "-1" as dest_len parameter.
(In order to avoid buffer overflows - This -1 used to mean unlimited
dest len before.)
Now there are (at least) roughly 100 indirect callers of push_ascii
left that explicitly pass -1 for dest_len:
roughly 40 through srvstr_push and roughly 60 through clistr_push.
This is too much for a really quick fix.
I would like to hear Jeremy's opinion on this.
Seems we have some more problems related to the changes to charcnv.c.
The Ubuntu bug was for patched 3.0.22. The Ubuntu patch did not include a change to a call to push_string() in nmbd/nmbd_sendannounce.c that was introduced in 3.0.23, which caused a smb_panic in some configurations.
Michael, clistr_push_fn explicitly handles the -1 case if it's pushing into a cli->outbuf space. Check libsmb/clistr.c for details. srvstr_push_fn does the same - it ensures it's pushing into valid space for the -1 case.
I'm guessing this is smbfs not setting the max_send correctly in the sessionsetup call.
Created attachment 2976 [details]
Patch for 3.0.27a
Fix for 3.0.27a
*** Bug 5088 has been marked as a duplicate of this bug. ***
Fixed in 3.0.27a.