Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in / Register
Toggle navigation
C
capnproto
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Packages
Packages
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
submodule
capnproto
Commits
f482cd45
Commit
f482cd45
authored
Apr 22, 2019
by
Kenton Varda
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Work around SCM_RIGHTS truncation vulnerability on MacOS and FreeBSD.
parent
15ed64b0
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
20 additions
and
1 deletion
+20
-1
async-io-unix.c++
c++/src/kj/async-io-unix.c++
+20
-1
No files found.
c++/src/kj/async-io-unix.c++
View file @
f482cd45
...
...
@@ -322,6 +322,26 @@ private:
msg
.
msg_iovlen
=
1
;
// Allocate space to receive a cmsg.
#if __APPLE__ || __FreeBSD__
// Until very recently (late 2018 / early 2019), FreeBSD suffered from a bug in which when
// an SCM_RIGHTS message was truncated on delivery, it would not close the FDs that weren't
// delivered -- they would simply leak: https://bugs.freebsd.org/131876
//
// My testing indicates that MacOS has this same bug as of today (April 2019). I don't know
// if they plan to fix it or are even aware of it.
//
// To handle both cases, we will always provide space to receive 512 FDs. Hopefully, this is
// greater than the maximum number of FDs that these kernels will transmit in one message
// PLUS enough space for any other ancillary messages that could be sent before the
// SCM_RIGHTS message to push it back in the buffer. I couldn't find any firm documentation
// on these limits, though -- I only know that Linux is limited to 253, and I saw a hint in
// a comment in someone else's application that suggested FreeBSD is the same. Hopefully,
// then, this is sufficient to prevent attacks. But if not, there's nothing more we can do;
// it's really up to the kernel to fix this.
size_t
msgBytes
=
CMSG_SPACE
(
sizeof
(
int
)
*
512
);
#else
size_t
msgBytes
=
CMSG_SPACE
(
sizeof
(
int
)
*
maxFds
);
#endif
// On Linux, CMSG_SPACE will align to a word-size boundary, but on Mac it always aligns to a
// 32-bit boundary. I guess aligning to 32 bits helps avoid the problem where you
// surprisingly end up with space for two file descriptors when you only wanted one. However,
...
...
@@ -329,7 +349,6 @@ private:
// the buffer, we need to make sure it is aligned properly (maybe not on x64, but maybe on
// other platforms), so we want to allocate an array of words (we use void*). So... we use
// CMSG_SPACE() and then additionally round up to deal with Mac.
size_t
msgBytes
=
CMSG_SPACE
(
sizeof
(
int
)
*
maxFds
);
size_t
msgWords
=
(
msgBytes
+
sizeof
(
void
*
)
-
1
)
/
sizeof
(
void
*
);
KJ_STACK_ARRAY
(
void
*
,
cmsgSpace
,
msgWords
,
16
,
256
);
auto
cmsgBytes
=
cmsgSpace
.
asBytes
();
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment