Stable kernel 2.6.25.9

Care to talk about:
David S. Miller (1):
      sctp: Make sure N * sizeof(union sctp_addr) does not overflow.

Specifically regarding the CVE already allocated to the issue already (CVE-2008-2826, which
doesn't seem to exist, but the candidates CVE-2008-237[2/3] do), or is even mentioning such
information, or even that anything security related was fixed, in the stable changelogs
"currently debated"?

Seems somewhat hypocritical given this recent post by Chris Wright:
http://marc.info/?l=linux-kernel&m=121312896523183&...
"Had I realized there was a security issue, I would highlight it in the announce message.  In
fact, that's our standard procedure for -stable."

Do you really think you're helping security by withholding this information?

---
Subject: two linux kernel security related fixes now upstream

FYI, these two git commits are probably something that people should
backport to older kernel releases, as they fix problems that were
reported to the security@kernel.org group:

       89f5b7da2a6bad2e84670422ab8192382a5aeb9f
       735ce972fbc8a65fb17788debd7bbe7b4383cc62

I'll be doing a -stable release in a day or so with them in it as well.

thanks,

greg k-h

---

---
> >     89f5b7da2a6bad2e84670422ab8192382a5aeb9f
>
> This SCTP problem exists in all 2.6 kernels I suspect.

Yes.  Note there is also another sctp problem that will be fixed in a
day or so in this same area with the same problem.  That too is public
knowledge.

> >     735ce972fbc8a65fb17788debd7bbe7b4383cc62
>
> Is this a resource starvation?

Yes, you can take down a box as a local unprivileged user.  Also note
that it seems to break vmware, and that a possible work around is being
developed right now on the linux-kernel mailing list.  So if people care
about vmware, then they might hold off with this one.

thanks,

greg k-h
------

------
>>      89f5b7da2a6bad2e84670422ab8192382a5aeb9f
>>      735ce972fbc8a65fb17788debd7bbe7b4383cc62
>
> Greg, do you want CVE names for these two (for your -stable changelog)?

Well, they will need to be created eventually, the value of them being
added to the -stable changelog seems to be currently debated :)

So sure, feel free to create them, and note that another one will need
to be added for sctp in the near future, if you need to reserve it as
well.

thanks,
----

---
>        CVE-2008-2373
>

Looks like the reporter already assigned this CVE-2008-2826, so use
CVE-2008-2826 and not CVE-2008-2373 :(
---

-Brad

Greg,

I can't tell if you're being facetious.  I could build a new kernel easily on 2.6.25.7,
2.6.24.5, or 2.6.18.3 if there were some reason to, such as incipient file system corruption
in 2.6.25.8.  If Brad's characterization is correct, the only consequential reason to switch
is vulnerabilities in SCTP, which I don't use.  That would have been helpful to know.  It
would be helpful to know if there are other consequential reasons.  

E.g., I noted changes to the b43 driver in (was it?) .8, and that seemed worth trying, because
signal quality on my Dell D620 w/ Broadcom 4311 has always been miserably poor.  I can't tell
by looking whether other changes might affect core system behavior.  On my Shuttle Xpc, I
never succeeded in getting a text console until I upgraded to a Debian 2.6.25 kernel, and
still have no idea why not, but am glad I upgraded.

I know it would be extra work figuring out and expressing consequences, but some are just more
... consequential ... than others, for all the obvious reasons. Those seem worth noting in the
release announcement.