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
Seems somewhat hypocritical given this recent post by Chris Wright:
"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 firstname.lastname@example.org group:
I'll be doing a -stable release in a day or so with them in it as well.
> > 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
> > 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.
> 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
Looks like the reporter already assigned this CVE-2008-2826, so use
CVE-2008-2826 and not CVE-2008-2373 :(