Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
> Does this mean I shouldn't build 18.104.22.168 on a machine running the 22.214.171.124
Don't be silly, how else would you be able to build it?
Stable kernel 126.96.36.199
Posted Jun 24, 2008 23:59 UTC (Tue) by spender (subscriber, #23067)
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 email@example.com 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 :(
Posted Jun 25, 2008 4:17 UTC (Wed) by gregkh (subscriber, #8)
> Care to talk about:
As I have stated before, I will be glad to discuss anything, on the
linux-kernel mailing list, as that is the proper and correct place for such a
discussion, not in a thread on some random (although very nice) web site.
Posted Jun 25, 2008 0:40 UTC (Wed) by ncm (subscriber, #165)
I can't tell if you're being facetious. I could build a new kernel easily on 188.8.131.52,
184.108.40.206, or 220.127.116.11 if there were some reason to, such as incipient file system corruption
in 18.104.22.168. 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
Posted Jun 25, 2008 4:19 UTC (Wed) by proski (subscriber, #104)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds