Bug 11988 - sockets with htons(IPPROTO_RAW) and CVE-2015-8543
Summary: sockets with htons(IPPROTO_RAW) and CVE-2015-8543
Status: RESOLVED FIXED
Alias: None
Product: CTDB 2.5.x or older
Classification: Unclassified
Component: ctdb (show other bugs)
Version: 4.2.x
Hardware: All Linux
: P5 major
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on: 11705
Blocks:
  Show dependency tree / graph
 
Reported: 2016-06-23 05:44 UTC by Martin Schwenke
Modified: 2016-07-08 07:23 UTC (History)
3 users (show)

See Also:

Attachments
Patches for v4-2 branch (11.02 KB, patch)
2016-06-27 06:39 UTC, Amitay Isaacs 		no flags Details
Patches for v4-2 branch (13.41 KB, patch)
2016-06-28 02:41 UTC, Amitay Isaacs 		martins: review+
Details
Patches for 1.0.114(.9) (8.80 KB, patch)
2016-06-28 15:01 UTC, Stefan Metzmacher 		no flags Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schwenke 2016-06-23 05:44:08 UTC 
+++ This bug was initially created as a clone of Bug #11705 +++

as described on the mailinglist:
A recent kernel security update[1] caused some issues with our ctdb
cluster; messages like:
  | We are still serving a public IP 'x.x.x.x' that we should not be serving. Removing it
  | common/system_common.c:89 failed to open raw socket (Invalid argument)
  | Could not find which interface the ip address is hosted on. can not release it
and 
  | common/system_linux.c:344 failed to open raw socket (Invalid argument)

The corresponding parts in ctdb's code look like this:
  | s = socket(AF_INET, SOCK_RAW, htons(IPPROTO_RAW));
converting IPPROTO_RAW to 0xff00 (from strace):
  | socket(PF_INET, SOCK_RAW, 0xff00 /* IPPROTO_??? */) = -1 EINVAL (Invalid argument)

Removing htons() from both calls seems to fix the issue for us. To have the original behavior, one could use IPPROTO_IP which is 0.

[1] https://security-tracker.debian.org/tracker/CVE-2015-8543
Comment 1 Martin Schwenke 2016-06-23 05:44:48 UTC 
We did not backport this to 4.2
Comment 2 Amitay Isaacs 2016-06-27 06:39:00 UTC 
Created attachment 12214 [details]
Patches for v4-2 branch
Comment 3 Martin Schwenke 2016-06-28 00:46:52 UTC 
Comment on attachment 12214 [details]
Patches for v4-2 branch

Don't we also need commit f5b6a5b13406c245ab9cc8c1699483af9eb21f88?
Comment 4 Amitay Isaacs 2016-06-28 02:41:03 UTC 
(In reply to Martin Schwenke from comment #3)

Yes we do!  New patches coming up.
Comment 5 Amitay Isaacs 2016-06-28 02:41:41 UTC 
Created attachment 12227 [details]
Patches for v4-2 branch
Comment 6 Martin Schwenke 2016-06-28 02:56:06 UTC 
Hi Karolin,

This one is ready for Samba 4.2.x.

Thanks!
Comment 7 Karolin Seeger 2016-06-28 11:09:45 UTC 
(In reply to Martin Schwenke from comment #6)
4.2 is in the security fixes only mode.
Are there any special reasons why it should be included in the next 4.2 security release?
Comment 8 Stefan Metzmacher 2016-06-28 15:01:22 UTC 
Created attachment 12230 [details]
Patches for 1.0.114(.9)

Here're patches for 1.0.114.9 in case someone needs them too...
Comment 9 Amitay Isaacs 2016-06-28 17:38:57 UTC 
(In reply to Karolin Seeger from comment #7)

It seems that this bug causes linux kernel to crash in some older versions.  

Is that good enough reason?
Comment 10 Stefan Metzmacher 2016-06-29 21:08:27 UTC 
(In reply to Amitay Isaacs from comment #9)

I'd agree to include this in our next security release, otherwise
please have choose between having a broken cluster or a kernel without security patches.
Comment 11 Karolin Seeger 2016-07-04 07:15:01 UTC 
Ok, thanks.
Applied on current v4-2-stable.
Comment 12 Karolin Seeger 2016-07-08 07:23:31 UTC 
(In reply to Karolin Seeger from comment #11)
Pushed and included in 4.2.14.
Closing out bug report.

Thanks!