Re: Bug#573531: drbd8-modules-2.6.26-2-amd64: Can not load drbd module
On Mon, Mar 15, 2010 at 07:39:58PM +0100, Moritz Muehlenhoff wrote:
> On Mon, Mar 15, 2010 at 12:13:06PM -0600, dann frazier wrote:
> > On Mon, Mar 15, 2010 at 06:50:58PM +0100, Moritz Muehlenhoff wrote:
> > > On 2010-03-15, dann frazier <dannf@debian.org> wrote:
> > > > On Mon, Mar 15, 2010 at 11:30:31AM -0400, David Miller wrote:
> > > >> I've also been bitten by this bug - noticed it last Friday and it
> > > >> doesn't seem to be fixed this morning.
> > > >>
> > > >> Is there an ETA on a fix with packages?
> > > >
> > > > Packages are now available in the security repo (an apt-get upgrade
> > > > should suffice).
> > > >
> > > > I'm hoping to get a CVE ID before sending out a formal DSA.
> > >
> > > Why? That should be covered by the CVE ID for the original connector
> > > security bug.
> >
> > Just to make sure we're talking about the same thing...
> >
> > One reason for this upload is to deal with the ABI breakage from the
> > kernel upload which fixed CVE-2009-3725. I agree that no additional
> > CVE is warranted to deal with that.
> >
> > However, as part of fixing this, we discovered that drbd contains a
> > security issue as well. This issue is in the same class as the issues
> > covered by CVE-2009-3725. However, CVE-2009-3725 has an explicit list
> > of 4 subsystems it covers, and drbd is not one of them.
>
> Ack. But since the underlying issue is identical I don't think a separate
> CVE ID is warranted. The CVE description can still be updated later if
> needed.
I would agree with the above if the same fix for issues 1-4 also fixed
this issue - but in this case, it doesn't.
All of these fixes required an underlying change in the connector
subsystem (allowing the passing of creds into the callback). But,
*using* that change requires a separate change in each subsystem. It
is completely possible to fix one subsystem and leave the others
unfixed. They will compile fine, though there would be a non-fatal
compiler warning that could go unnoticed.
I don't think it makes sense to go back and add drbd to the CVE after
the fact, because it changes the semantics. It is quite possible that
some other vendor is out there shipping drbd and has already fixed
CVE-2009-3725. Doing an update instead of a new CVE may cause this
additional issue to go unnoticed/unfixed.
In other words I think that, once distros have fixed a CVE, it isn't
ok to add more fixes to that CVE which contradict the distro's
statement that the CVE is fixed. Particularly when a new CVE could be
used instead.
For some precedence, see the recent regression fixes in
CVE-2009-453[6-8]. Those are fixes for regressions introduced by
previous CVE fixes - but they chose to allocate new CVEs instead of
updating the existing ones. I'm sure we could dig up precedence to
the contrary - CVE-2010-0307 might be an example, if we consider
1dfc76ec to be a security fix vs. just a regression.
That said, it really is MITRE's call - so we'll see how they respond
to my request. If they prefer to update the existing CVE, that's fine
by me.
--
dann frazier
Reply to: