tags 330592 -unreproducible +etch -help
severity 330592 critical
found 330592 2.86.ds1-20
thanks
The reason for the critical level is that this bug has the potential to
render the entire system unbootable unless glibc catches the invalid
free() calls. See description below for further details.
James Westby wrote:
However it did not cause a segfault, and I got a completed boot. I did
however get
*** glibc detected *** free(): invalid pointer: 0x0804feb5 ***
*** glibc detected *** free(): invalid pointer: 0x0804feb5 ***
so maybe this is what was the segfault before.
I think I've nailed it.
in src/init.c:150, after selinuxfs has been sucessfully mounted (but
only if it has been succesfully mounted, which would explain why the
problem appeared after the /selinux dir was created), is the following
step:
selinux_mnt = SELINUXMNT; /* set manually since we mounted it */
(and SELINUXMNT is already defined as "/selinux/")
However, with changes made to libselinux1 since the selinux patch was
written for sysvinit, selinux_mnt is now a variable internal to the
selinux1 library.
In src/init.c:70 of libselinux1 (1.32), we have this line:
free(selinux_mnt);
So when the children fork:ed by init exit (in the spawn() function from
src/init.c), the exit function of the libselinux1 library will also be
called and try to free selinux_mnt which has not been allocated with
malloc.
The result is of course that the child blows up or, due to unrelated
changes in glibc, survives with a warning. If it blows up, the error
handlers will ensure that it continues respawning over and over.
So, the fix would be to apply the selinux patch to sysvinit that is
already included in more recent versions (which use the
selinux_init_load_policy function instead of manipulating selinux_mnt).
Thus I'll close the bug as fixed in sysvinit 2.86.ds1-34.
I still suspect that #344471 is a dupe of this bug, but I'll leave that
up to the maintainers to deal with.
--
David Härdeman
