[Pkg-sysvinit-devel] Bug#330592: init segfault when /selinux exists but a policy can't be loaded

[David Härdeman]

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