linux-kernel - Re: XFS security fix never sent to -stable?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+5PVA7wso5fo11xX9kCUdbrqBQMzUnYwTOB_Qe3K7LDY4z_Cw@mail.gmail.com>
Date:	Tue, 10 Dec 2013 20:10:51 -0500
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	Luis Henriques <luis.henriques@...onical.com>,
	Kees Cook <keescook@...gle.com>,
	Dwight Engen <dwight.engen@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Brian Foster <bfoster@...hat.com>,
	Dave Chinner <dchinner@...hat.com>,
	Gao feng <gaofeng@...fujitsu.com>, Ben Myers <bpm@....com>,
	Greg KH <gregkh@...uxfoundation.org>, xfs@....sgi.com,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: XFS security fix never sent to -stable?

On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@...morbit.com> 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@...morbit.com>
>> wrote:
>> > [cc xfs list, cc stable@...r.kernel.org]
>> >
>> > 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@...onical.com> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/