Bug 201053

Summary: capsicum: pdfork() should reject invalid values in its flags field
Product: Base System Reporter: Ed Maste <emaste>
Component: kernAssignee: Siva Mahadevan <svmhdvn>
Status: Closed FIXED    
Severity: Affects Only Me CC: drysdale, emaste, oshogbo
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 203349    

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.