bug#24138: SIGSEGV of useradd (from shadow package)

[Tomáš Čech]

On Wed, Aug 03, 2016 at 06:56:19PM +0200, Ludovic Courtès wrote:
> Hello!
>
> Tomáš Čech <address@hidden> skribis:
>
> > It seems to be easy to crash useradd (from shadow package).
>
> Is it on GuixSD?

Yes. \o/

> > from strace:
> >
> > read(3, "account required pam_deny.so \nau"..., 4096) = 223
> > open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
> >  O_RDONLY|O_CLOEXEC) = 5
> > read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\6\0\0\0\0\0\0"..., 
> > 832) = 832
> > fstat(5, {st_mode=S_IFREG|0555, st_size=6728, ...}) = 0
> > mmap(NULL, 2100200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
> > 0x7fb8b447c000
> > mprotect(0x7fb8b447d000, 2093056, PROT_NONE) = 0
> > mmap(0x7fb8b467c000, 4096, PROT_READ|PROT_WRITE, 
> > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0) = 0x7fb8b467c000
> > close(5)                                = 0
> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb8b3d1bda8} ---
>
> Could you check in the ‘strace’ output whether PAM modules build with
> another libc are being loaded?

It doesn't seem to be that case:

# grep linux-pam ~/useradd.strace  | grep -v ENOENT
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam_misc.so.0",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_unix.so",
 O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_rootok.so",
 O_RDONLY|O_CLOEXEC) = 4
19555 stat("/gnu/store/m4xna3zq2il5an61wxbmfv82ndvz70f6-linux-pam-1.2.1/lib", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5

On the other hand it seems to load part of the libraries from 2.22,
part from 2.23 and that is not healthy.

# grep glibc ~/useradd.strace  | grep -v ENOENT
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libc.so.6", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/share/locale/locale.alias",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_compat.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnsl.so.1", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_nis.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_files.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libcrypt.so.1",
 O_RDONLY|O_CLOEXEC) = 4
19555 stat("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libm.so.6", 
O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/librt.so.1", 
O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libpthread.so.0",
 O_RDONLY|O_CLOEXEC) = 4

It seems to be more serious than I thought:

# login
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])

S_W

signature.asc
Description: Digital signature