Using mount -a with the following /etc/fstab entry results in mount segfaulting with message: *** glibc detected *** mount: double free or corruption (fasttop): This has the effect of stopping the entire server. 2.18-r1 does not exhibit this behavior. Neither does the problem occur when SELinux is disabled. Further, problem only manifests when using 'mount -a' or 'mount mount-point-name' with the following entry in /etc/fstab none /var/tmp/portage tmpfs noauto,nr_inodes-1m,size=1024m 0 0 Note: removing noauto will cause system to halt when mounting filesystems. Note2: Executing 'mount -t tmpfs -o nr_inodes=1m,size=1024m none /var/tmp/portage' works just fine. Reproducible: Always Steps to Reproduce: 1. Enable SELinux (enforcing or permissive, doesn't matter, just has to be enabled) 2.Add an entry to your /etc/fstab as follows: none /var/tmp/portage tmpfs noauto,nr_inodes-1m,size=1024m 0 0 3. 'mount -a' or 'mount /var/tmp/portage' Actual Results: mount segfaults with following: *** glibc detected *** mount: double free or corruption (fasttop): 0x00007fec31e1d1c0 *** Expected Results: mount completes successfully
Created attachment 278517 [details] stack dump
This may be another facet of bug 366213
Created attachment 278521 [details] system emerge info
Problem has been reproduced on both hardened-sources-2.6.36-r9 and hardened-sources-2.6.38-r2
works on my system, but i'm not using selinux
give 2.19.1-r1 a try. i dont think it'll fix this particular crash, but who knows ... maybe we'll get lucky.
I'm in Westford Mass until 1 August training with my new employer, with brief trips home on the weekends. I'll try to check with 2.19.1-r1 when I get home this weekend, otherwise, it'll probably be 1st of August before I can spend much time on this.
It's the same with #366213 in a way. I added the following line to /etc/fstab and it works fine... udev /dev tmpfs nosuid,noexec,size=1M 0 0
Got a chance to play with this. It is still giving the same behavior with 2.19.1-r1 (crash when automouting).
pretty sure it's going to be up to the selinux guys to debug it a bit more
Well, I'm not able to really deduce where the problem is at. Amateurish debugging tells me that the problem situates itself between mount.c:1924 & 1925: . if (extra_opts1 != mount_opts) . my_free(mount_opts) -> my_free(extra_opts1) . my_free(spec1) Perhaps that mount_opts is "part" of extra_opts1 (but not starting at the same position), but by the time gdb shows the backtrace the symbols can't be resolved... Again, I'm an amateur :-( Behavior-wise, the following might be interesting to know for those wanting to take a stab at it... (1.) If /var/tmp/portage is labeled tmp_t instead of portage_tmp_t, then there is no issue. (2.) If, in /etc/fstab, you set "rootcontext=system_u:object_r:portage_tmp_t" as a mount option as well, then there is no issue (3.) Having portage_tmp_t not be of type "mountpoint" in SELinux isn't the cause. Labelling /var/tmp/portage as other mountpoint types (including tmpfs_t) still gives the segfault So as a workaround, set the rootcontext= option (as in 2.)
*** Bug 375875 has been marked as a duplicate of this bug. ***
I originally had in fstab: tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 which caused a segmentation fault upon boot up for local filesystems. I took away the mode=1777 and no more segmentation faults. for system information see bug 375875
For some reason, the segfault during the mount operation is triggered when a tmpfs-mounted location in fstab has a mount option with "=" in it (like mode=1777).
Created attachment 280809 [details, diff] Fix the double-free issue The problem lays within mount.c's additional SELinux code... In the function try_mount_one (mount.c:1520) additional options as found in /etc/fstab are stored in extra_opts, and additional pointers towards this are created: 1549 parse_opts (opts, &flags, &extra_opts); 1550 extra_opts1 = extra_opts; 1551 mount_opts = extra_opts; Later in this function, we encounter the following: 1595 } else if (types && strcmp(types, "tmpfs") == 0 && is_selinux_enabled() > 0 && 1596 !has_context_option(mount_opts)) { 1597 /* 1598 * Add rootcontext= mount option for tmpfs 1599 * https://bugzilla.redhat.com/show_bug.cgi?id=476964 1600 */ 1601 security_context_t sc = NULL; 1602 1603 if (getfilecon(node, &sc) > 0 && strcmp("unlabeled", sc)) 1604 append_context("rootcontext=", (char *) sc, &mount_opts); 1605 freecon(sc); 1606 } In other words, if the type is "tmpfs" and SELinux is enabled and there is no context mount option, then a context is added. Here however lays the problem. The append_context() function (mount.c:374) uses xstrconcat4() against its first argument, which in this case is &mount_opts. The xstrconcat4 function (defined in sundries.c:64) might free its first option (depending on the size of the original string). This is why the segfault does not always occur: a context label for "tmp_t" is small enough, but "portage_tmp_t" will cause xstrconcat4 to free this space and allocate new one. However, the pointers extra_opts and extra_opts1 are still referring to this (old) location. When the try_mount_one() function at its end wants to free the memory fragments, it encounters a double-free: 1922 if (extra_opts1 != mount_opts) 1923 my_free(mount_opts); 1924 my_free(extra_opts1); // <-- here it occurs 1925 my_free(spec1); The attached patch will set these pointers to the new location right after the append_context() call. Putting this in util-linux' src_prepare() method fixes the problem: epatch "${FILESDIR}/util-linux-2.19.1-fix-doublefree-mount_opts.patch"
Also found (right after of course) that fedora has another approach on this issue: http://osdir.com/ml/scm-fedora-commits/2011-07/msg02967.html
Also fixed in upstream git: http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commitdiff;h=400459e897045b40eb3711fa4814176f7422a76a
2.20 is in the tree now and should contain the fix
