Bug 201053 - capsicum: pdfork() should reject invalid values in its flags field
Summary: capsicum: pdfork() should reject invalid values in its flags field
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Siva Mahadevan
URL:
Keywords:
Depends on:
Blocks: 203349
  Show dependency treegraph
 
Reported: 2015-06-22 20:56 UTC by Ed Maste
Modified: 2017-07-19 14:43 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer 2015-06-22 20:56:00 UTC
Test case Pdfork.InvalidFlag available in https://github.com/google/capsicum-test
Comment 1 Ed Maste freebsd_committer 2017-06-28 14:26:13 UTC
Jon, Siva (one of the Foundation's co-op students for the summer term) will take a look at this.
Comment 2 Siva Mahadevan 2017-07-19 14:17:06 UTC
The test case is passing on HEAD, it seems that the fix went unnoticed. We should be able to close this.
Comment 3 Ed Maste freebsd_committer 2017-07-19 14:18:40 UTC
(In reply to Siva Mahadevan from comment #2)
I can't see evidence of a fix though, or a test that would return EINVAL for this case: I worry the test is providing insufficient coverage.
Comment 4 Siva Mahadevan 2017-07-19 14:31:09 UTC
(In reply to Ed Maste from comment #3)

In terms of a test that would return EINVAL, I think this from sys/kern/kern_fork.c covers it:

int
fork1(struct thread *td, struct fork_req *fr)
{
        ...
        if ((flags & RFPROCDESC) != 0) {
                ...
                /* Check if we are using supported flags. */
                if ((fr->fr_pd_flags & ~PD_ALLOWED_AT_FORK) != 0)
                        return (EINVAL);
        }
        ...
}

flags will contain RFPROCDESC on a pdfork and the following definition exists:
#define	PD_ALLOWED_AT_FORK	(PD_DAEMON | PD_CLOEXEC)
Comment 5 Ed Maste freebsd_committer 2017-07-19 14:43:34 UTC
Oh indeed, addressed by Mariusz in r301573, which is in stable/11. As you say this can be closed.