FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 03-15-2010, 05:13 PM
dann frazier
 
Default Bug#573531: drbd8-modules-2.6.26-2-amd64: Can not load drbd module

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.

--
dann frazier


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100315181306.GC15324@lackof.org">http://lists.debian.org/20100315181306.GC15324@lackof.org
 
Old 03-15-2010, 06:39 PM
dann frazier
 
Default 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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100315193908.GD15324@lackof.org">http://lists.debian.org/20100315193908.GD15324@lackof.org
 
Old 03-15-2010, 10:41 PM
dann frazier
 
Default Bug#573531: drbd8-modules-2.6.26-2-amd64: Can not load drbd module

On Mon, Mar 15, 2010 at 08:45:46PM +0100, Moritz Muehlenhoff wrote:
> On Mon, Mar 15, 2010 at 01:39:08PM -0600, dann frazier wrote:
> > 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.
>
> Ok. But I recommend against holding back the update until a CVE is
> assigned. MITRE isn't working properly these days, we already needed
> to release several DSA w/o CVE IDs being assigned so far. Just write
> "Not yet available" as done for DSA 2013, DSA 2016 and DSA 2008.

ok, I'll do that.
fyi, it should go out in a couple hours (last build just completed).

--
dann frazier


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100315234127.GF15324@lackof.org">http://lists.debian.org/20100315234127.GF15324@lackof.org
 

Thread Tools




All times are GMT. The time now is 08:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org