On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote:
> On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@xxxxxxxxxxxxx>
> wrote:
> > [cc xfs list, cc stable@xxxxxxxxxxxxxxx]
> >
> > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> >> <luis.henriques@xxxxxxxxxxxxx> wrote:
> >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote:
> >> >> Hi,
> >> >>
> >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c
> >> >> ("xfs: add capability check to free eofblocks ioctl") is a
> >> >> security fix that was never sent to -stable? From what I can
> >> >> see, it was introduced in 3.8 by
> >> >> 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add
> >> >> XFS_IOC_FREE_EOFBLOCKS ioctl").
> >> >>
> >> >> I don't see this in the 3.8.y tree. Should it be added there
> >> >> and newer?
> >> >
> >> > Thanks Kees, I'm queuing it for the 3.11 kernel.
> >>
> >> There's also this one:
> >>
> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> >>
> >> It fixes CVE-2013-6382
> >
> > First I've heard about it there being a CVE for that bug. Since
> > when has it been considered best practice to publish CVEs
> > without first (or ever) directly contacting the relevant
> > upstream developers?
>
> We got a Fedora bug for it, and there are similar RHEL bugs open.
> I had assumed you would be informed either via upstream or
> through those.
I've not been cc'd on any of those bugs internally at RH, so I don't
have visibility of the problems unless someone specifically adds me
to those bugs. As it is, raising fedora/RHEL bugs is not informing
upstream - it is a distro process for tracking the distro issue
through to closure.
> The CVE request was submitted by Kees here:
> http://seclists.org/oss-sec/2013/q4/330
Ugh, no, I'm not going to subscribe to a high noise list where the
only way I might be informed of a CVE being raised is by following
links to git commit IDs....
Upstream is not magically informed about CVEs, and relying on
upstream developers to scan or poll *anything* just to find if a
CVE on their subsystem has been released is not reliable and
does not scale. If anyone raises a CVE against a kernel subsystem,
then the relevant list in the MAINTAINERS file for that subsystem
should be on the cc list of any discussion about the CVE, and on the
announcement of the CVE.
Security processes are not something that should be hidden away in
it's own private corner - if there's a problem upstream needs to
take action on, then direct contact with upstream is necessary. We
need to know about security issues - even ones that are classified
post-commit as security issues - so we are operating with full
knowledge of the issues in our code and the impact of our fixes....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html