| Summary: | sys-apps/util-linux-2.19.1 mount utillity segfaults under SELinux with v2ref profiles | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Chris Richards <gizmo> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | coolio, selinux |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
stack dump
system emerge info Fix the double-free issue |
||
|
Description
Chris Richards
2011-06-28 16:44:15 UTC
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 |
