SWAT segfaults when trying to view full configuration

[Kai Blin]

When running swat on a 32bit 12.04 install, swat segfaults when the user clicks on the "Full View" button in the configuration menu. This only happens on the 32bit install, the 64bit install seems fine.

This was reported to upstream under https://bugzilla.samba.org/show_bug.cgi?id=8999 but can only be reproduced with the distro packages.

swat crashes with the following backtrace (sorry for the missing debug symbols, the samba-dbg package doesn't seem to help gdb getting debug symbols for swat):

(gdb) bt
#0 0xb72340c0 in ?? ()
#1 0xb7d7923c in _talloc_free () from /usr/lib/i386-linux-gnu/libtalloc.so.2
#2 0x80215875 in smb_iconv_close ()
#3 0x80204d65 in ?? ()
#4 0x802051d8 in smb_iconv_convenience_reinit ()
#5 0x801f2bf5 in init_iconv ()
#6 0x801f2c32 in lazy_initialize_conv ()
#7 0x801f35e5 in convert_string_talloc ()
#8 0x80074c99 in cgi_load_variables ()
#9 0x80071e3c in main ()

A relatively straightforward way to reproduce the crash in gdb is running gdb swat, and then typing in
GET /viewconfig HTTP/1.1
Authorization: Basic <base64 of user:pass>

then grab the xsrf and xsrf_time values in the form displayed...

GET /viewconfig?full_view=Full+View&xsrf=<xsrf>&xsrf_time=<xsrf_time> HTTP/1.1
Authorization: Basic <base64 of user:pass>

and the segfault happens.
With the current v3-6-test git HEAD from the samba git, this doesn't happen. The last time this code was touched upstream was in 2009, so I'm not sure a code change caused this.

You cannot reproduce the crash if you start swat with -a to skip the authentication logic, so you need to set up a root password for this to work.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: swat 2:3.6.3-2ubuntu2.3
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic-pae 3.2.18
Uname: Linux 3.2.0-25-generic-pae i686
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
Date: Wed Jun 20 13:41:39 2012
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release i386 (20120424.1)
NmbdLog:
 Packet send failed to 10.0.2.255(138) ERRNO=Invalid argument
   Packet send failed to 10.0.2.255(138) ERRNO=Invalid argument
OtherFailedConnect: Yes
ProcEnviron:
 LANGUAGE=en_IE:en
 TERM=linux
 PATH=(custom, no user)
 LANG=en_IE.UTF-8
 SHELL=/bin/bash
SambaServerRegression: Yes
SmbConfIncluded: Yes
SourcePackage: samba
UpgradeStatus: No upgrade log present (probably fresh install)

[Marc Cluet (lynxman)]

Can reproduce with a fresh Precise install from CD and selecting "samba" at the install time.
Can't reproduce installing samba directly, looks like a failure related to the added packages "samba, cifs-utils, smbclient,
smbfs, winbind"
This looks like an auth interaction bug between different packages

[Kai Blin (kai.blin)]

Right, our bug reporter investigated this a bit further, and it turns out that removing libpam-smbpass fixes the crash, and reinstalling libpam-smbpass causes the crash to happen again.
This also explains why starting swat without the authentication check doesn't trigger the crash.
As a next step, I'll install libpam-smbpass for a from source build to see if _that_ reproduces the crash.

[Kai Blin (kai.blin)]

Ok, this actually is a bug in libpam-smbpass, not in swat.

When recompiling the packages with debug info, the backtrace from swat is:

#0 0xb7217600 in ?? ()
#1 0xb7d7923c in _talloc_free () from /usr/lib/i386-linux-gnu/libtalloc.so.2
#2 0x8027fae1 in smb_iconv_close (cd=0x8081f768) at ../lib/util/charset/iconv.c:337
#3 0x8026ee61 in close_iconv_convenience (data=0x80812228) at ../lib/util/charset/codepoints.c:203
#4 0x8026f08c in smb_iconv_convenience_reinit (mem_ctx=0x0, dos_charset=0x80816c08 "CP850", unix_charset=0x80816bc8 "UTF-8",
    display_charset=0xb745930c "UTF-8", native_iconv=true, old_ic=0x80812228) at ../lib/util/charset/codepoints.c:265
#5 0x8025b037 in init_iconv () at lib/charcnv.c:78
#6 0x8025af8c in lazy_initialize_conv () at lib/charcnv.c:55
#7 0x8025bb59 in convert_string_talloc (ctx=0x80816b90, from=CH_UTF8, to=CH_UNIX, src=0x8081cd60, srclen=9, dst=0xbffff670, converted_size=0xbffff674,
    allow_bad_conv=true) at lib/charcnv.c:480
#8 0x8007207d in cgi_load_variables () at web/cgi.c:214
#9 0x80079c4c in main (argc=1, argv=0xbffff824) at web/swat.c:1581

Note the call to close_iconv_convenience() in frame 3.

Now, when looking at libpam-smbpass.so symbols with nm, this gives the following iconv-related output:

0008fe20 t close_iconv_convenience
0008fd4c T get_iconv_convenience
00207a80 B global_iconv_convenience
         U iconv@@GLIBC_2.1
         U iconv_close@@GLIBC_2.1
000a111b t iconv_copy
         U iconv_open@@GLIBC_2.1
000a1057 t iconv_swab
0007c01a T init_iconv
000a0364 t lazy_initialize_iconv
000a03ff T smb_iconv
000a0af6 T smb_iconv_close
00090085 T smb_iconv_convenience_reinit
000a0abc T smb_iconv_open
000a0686 T smb_iconv_open_ex
000a0600 t smb_iconv_t_destructor
000a0389 t sys_iconv

Again, note the t close_iconv_convenience, which as far as I understand says that libpam-smbpass contains close_iconv_convenience in it's text section, so there's a copy of that call in libpam-smbpass.
Now, if libpam-smbpass is loaded, it seems like swat uses the wrong version of that call, and things go wrong.
If you comment out the libpam-smbpass line in /etc/pam.d/common-auth, The crash is gone.

[Jelmer Vernooij (jelmer)]

SWAT has been discontinued.