This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 983691 - libguestfs double free when kernel link fails during launch
libguestfs double free when kernel link fails during launch
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
:
Depends On: 983218
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-11 13:50 EDT by Richard W.M. Jones
Modified: 2014-06-17 22:00 EDT (History)
8 users (show)

See Also:
Fixed In Version: libguestfs-1.22.4-2.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 983218
Environment:
Last Closed: 2014-06-13 07:07:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Updated reproducer script. (1.25 KB, text/plain)
2013-07-11 14:15 EDT, Richard W.M. Jones
no flags Details

  None (edit)
Description Richard W.M. Jones 2013-07-11 13:50:00 EDT
+++ This bug was initially created as a clone of Bug #983218 +++

--- Additional comment from Richard W.M. Jones on 2013-07-11 12:25:20 EDT ---

I can see how a double free could occur.

The key observation is the last error message which was captured
in the guestfs handle:

(gdb) print g->last_error 
$5 = 0x7f296400c370 "link: /var/tmp/.guestfs-1002/kernel /var/tmp/.guestfs-1002/kernel.29013: Operation not permitted"

This errors occurs in hard_link_to_cached_appliance:

https://github.com/libguestfs/libguestfs/blob/af1c53d104180415a8584c48f19fd4ea7df224f5/src/appliance.c#L607

In hard_link_to_cached_appliance, along this error path
params.kernel would be allocated and then free (but not set
back to NULL).

Two levels higher up in the stack, the libvirt backend returns
from guestfs___build_appliance with an error:

https://github.com/libguestfs/libguestfs/blob/823628d41f898982979ab7dd53656377bef8ce1d/src/launch-libvirt.c#L232

and jumps to cleanup: which frees params.kernel again.  A
double-free.

The fix may be to set the kernel pointer to NULL after
freeing it the first time, but I need to systematically
check this code.

--- Additional comment from Richard W.M. Jones on 2013-07-11 12:53:49 EDT ---

Attached is a reproducer (although I think what it may be
reproducing is a related but ever so slightly different
bug in the same area of code).

It requires a working 'sudo' command in order to run
the following:

  sudo chattr +i /some/temporary/file

Install perl-Sys-Guestfs, download the attached script,
chmod +x the script, and just run it.

If it *segfaults* => bug reproduced.

If it prints "bug 983218 appears to be fixed" => bug fixed.

If it does/prints anything else, result is INVALID.  Please
let me know if this happens.

https://bugzilla.redhat.com/attachment.cgi?id=772313
Comment 1 Richard W.M. Jones 2013-07-11 14:15:07 EDT
Created attachment 772358 [details]
Updated reproducer script.

Updated reproducer script.  Ignore link in previous comment.
Comment 3 bfan 2013-07-24 04:29:20 EDT
Reproduce with libguestfs-1.22.4-1.el7.x86_64 using attached script

[root@intel-5405-32-3 home]# ./test.pl 
Segmentation fault (core dumped)
Comment 5 Lingfei Kong 2013-11-16 21:28:57 EST
Verified with libguestfs-1.22.6-15.el7

Steps:
1. Install perl-Sys-Guestfs-1.22.6-15.el7
2. Download test script from Comment 1
3. [lkong@rhel7libguestfs ~]$ sudo ./test.pl 
[sudo] password for lkong: 
bug 983218 appears to be fixed
Comment 6 Richard W.M. Jones 2013-11-17 04:32:42 EST
(In reply to Lingfei Kong from comment #5)
> 3. [lkong@rhel7libguestfs ~]$ sudo ./test.pl 

Note that the test script requires 'sudo'.  That doesn't mean
you should run the test script under sudo.  Run the
test program as you.
Comment 7 Lingfei Kong 2013-11-17 21:36:23 EST
(In reply to Richard W.M. Jones from comment #6)
> 
> Note that the test script requires 'sudo'.  That doesn't mean
> you should run the test script under sudo.  Run the
> test program as you.

Thanks for your reminding, I read the test script and understand that the test code need 'sudo' permission but not means that I should do the test under "sudo".
Comment 8 Ludek Smid 2014-06-13 07:07:34 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.