Bug 1018890

Summary:	pluto leaks file descriptors
Product:	Red Hat Enterprise Linux 6	Reporter:	Philipp Reisner <philipp.reisner>
Component:	openswan	Assignee:	Paul Wouters <pwouters>
Status:	CLOSED DUPLICATE	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.4	CC:	eparis, lars.ellenberg
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-17 20:07:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Philipp Reisner 2013-10-14 15:42:13 UTC

Description of problem:


Version-Release number of selected component (if applicable):

2.6.32-20.el6_4.x86_64

How reproducible:

Always


Steps to Reproduce:
1. Establish an IPSec tunnel on a kernel that does not have fips enabled
2. Use lsof or /proc/pid to watch as pluto opens more and more FDs of 
   /proc/sys/crypto/fips_enabled

Actual results:

when pluto hits 1024 FDs, it start to bahave "strange". Sometimes
it crashes with SIGSEGV.

Expected results:

Pluto should close /proc/sys/crypto/fips_enabled after reading the 0 out
of it.

Additional info:

In /var/log/messages you will find lines like these:
Oct 14 11:51:37 xxx kernel: pluto[31031]: segfault at 288 ip 00007f314cd196e3 sp 00007fff34fb9c80 error 4 in pluto[7f314ccc9000+fc000]
Oct 14 12:14:33 xxx kernel: pluto[21862]: segfault at 288 ip 00007fba0a4106e3 sp 00007fff7218b590 error 4 in pluto[7fba0a3c0000+fc000]
Oct 14 12:56:10 xxx kernel: pluto[7841]: segfault at 288 ip 00007f6ffdf956e3 sp 00007fff2d08a4b0 error 4 in pluto[7f6ffdf45000+fc000]

Comment 1 Philipp Reisner 2013-10-14 15:44:27 UTC

The issue was fixed in pluto upstream. See commit:

commit ef4d0f4a921afe1977a02d97a9bf1b48b8aad85e
Author: Paul Wouters <paul>
Date:   Tue Aug 9 13:26:14 2011 -0400
* Fix closing fd in lib/libopenswan/oswconf.c [Avesh]

Comment 3 Eric Paris 2013-10-15 21:14:33 UTC

Thank you for filing this report.  I am going to propose this bug for 6.6.  We are way past the time frame where this could be addressed in 6.5.

Comment 4 Lars Ellenberg 2013-10-16 08:27:29 UTC

(In reply to Eric Paris from comment #3)
> Thank you for filing this report.  I am going to propose this bug for 6.6.
> We are way past the time frame where this could be addressed in 6.5.

Honestly?
That's an "obviously correct oneline patch"...

 ;)

See:
> https://github.com/xelerance/Openswan/commit/ef4d0f4a921afe1977a02d97a9bf1b48b8aad85e
>
> letoams authored 2 years ago 
>
> Author: Paul Wouters <paul>
> Date:   Tue Aug 9 13:26:14 2011 -0400
> 
>     * Fix closing fd in lib/libopenswan/oswconf.c [Avesh]
> 
> diff --git a/lib/libopenswan/oswconf.c b/lib/libopenswan/oswconf.c
> index 38ed558..63a748f 100644
> --- a/lib/libopenswan/oswconf.c
> +++ b/lib/libopenswan/oswconf.c
> @@ -199,42 +199,42 @@ secuPWData *osw_return_nss_password_file_info(void)
>  bool Pluto_IsFIPS(void)
>  {
>       char fips_flag[1];
>       int n;
>       FILE *fd=fopen("/proc/sys/crypto/fips_enabled","r");
>       
>       if(fd!=NULL) {
>  	    n = fread ((void *)fips_flag, 1, 1, fd);
>  		if(n==1) {
>  		    if(fips_flag[0]=='1') {
>  		    fclose(fd);
>  		    return TRUE;
>  		    }
>  		    else {
>  		    openswan_log("Non-fips mode set in /proc/sys/crypto/fips_enabled");
>  		    }
>  		} else {
>  			openswan_log("error in reading /proc/sys/crypto/fips_enabled, returning non-fips mode");
>  		} 
> +     fclose(fd);
>       }
>       else {
>  	openswan_log("Not able to open /proc/sys/crypto/fips_enabled, returning non-fips mode"); 
> -	fclose(fd);
>       }
>  return FALSE;
>  }
...

Comment 5 Eric Paris 2013-10-16 14:39:47 UTC

I agree it doesn't seem to make sense.  But at this point in the RHEL development cycle the only code changes we can make are to fix regressions between 6.4 and 6.5.  This does not meet that requirement and so must be queued for 6.6.  I apologize for the delay and appreciate the report.

Comment 6 Paul Wouters 2013-10-17 20:07:29 UTC


*** This bug has been marked as a duplicate of bug 1020322 ***