On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> 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.
Agreed. We should probably fix the bug thing anyway though.
>> 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....
Agreed. I'm going to interpret your comments at being directed to the
general audience because otherwise you're just shooting the messenger
:).
josh
--
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