login
Search
We (the -stable team) are announcing the release of the 2.6.25.10
kernel.
It contains a number of assorted bugfixes all over the tree. And once
again, any users of the 2.6.25 kernel series are STRONGLY encouraged to
upgrade to this release.
I'll also be replying to this message with a copy of the patch between
2.6.25.9 and 2.6.25.10
The updated 2.6.25.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=summary
thanks,
greg k-h
-------------
Makefile | 2
arch/x86/kernel/i387.c | 4 -
arch/x86/kernel/ptrace.c | 45 +++++++------
arch/x86/kernel/smpboot_64.c | 1
drivers/char/drm/i915_drv.c | 1
drivers/infiniband/hw/mthca/mthca_memfree.c | 6 +
drivers/net/hamradio/6pack.c | 2
drivers/net/hamradio/mkiss.c | 8 +-
drivers/net/irda/irtty-sir.c | 4 -
drivers/net/ppp_async.c | 3
drivers/net/ppp_synctty.c | 3
drivers/net/slip.c | 14 +++-
drivers/net/wan/x25_asy.c | 10 ++-
drivers/net/wireless/strip.c | 3
include/asm-x86/msr.h | 2
kernel/futex.c | 93 +++++++++++++++++++++-------
kernel/sched.c | 1
17 files changed, 147 insertions(+), 55 deletions(-)
Alan Cox (1):
TTY: fix for tty operations bugs
Dmitry Adamushko (1):
sched: fix cpu hotplug
Eli Cohen (1):
IB/mthca: Clear ICM pages before handing to FW
Greg Kroah-Hartman (1):
Linux 2.6.25.10
Jie Luo (1):
DRM: enable bus mastering on i915 at resume time
Max Asbock (1):
x86: shift bits ...diff --git a/Makefile b/Makefile
index 3eb71f8..e26eb7d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 25
-EXTRAVERSION = .9
+EXTRAVERSION = .10
NAME = Funky Weasel is Jiggy wit it
# *DOCUMENTATION*
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index d2e39e6..5f04579 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -130,7 +130,7 @@ int xfpregs_get(struct task_struct *target, const struct user_regset *regset,
void *kbuf, void __user *ubuf)
{
if (!cpu_has_fxsr)
- return -ENODEV;
+ return -EIO;
init_fpu(target);
@@ -145,7 +145,7 @@ int xfpregs_set(struct task_struct *target, const struct user_regset *regset,
int ret;
if (!cpu_has_fxsr)
- return -ENODEV;
+ return -EIO;
init_fpu(target);
set_stopped_child_used_math(target);
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 9003e0b..a10ba65 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1309,42 +1309,49 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
break;
case PTRACE_GETREGS: /* Get all gp regs from the child. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_GENERAL,
- 0, sizeof(struct user_regs_struct32),
- datap);
+ ret = copy_regset_to_user(child, &user_x86_32_view,
+ REGSET_GENERAL,
+ 0, sizeof(struct user_regs_struct32),
+ datap);
+ break;
case PTRACE_SETREGS: /* Set all gp regs in the child. */
- return copy_regset_from_user(child, &user_x86_32_view,
- REGSET_GENERAL, 0,
- sizeof(struct user_regs_struct32),
- datap);
+ ret = copy_regset_from_user(child, &user_x86_32_view,
+ REGSET_GENERAL, 0,
+ sizeof(struct user_regs_struct32),
+ datap);
+ break;
case PTRACE_GETFPREGS: /* Get the child FPU state. */
- return copy_regset_to_user(child, &user_x86_32_view,
- REGSET_FP, ...Hello Greg, Thanks for all the work you and the stable team are doing on the stable series. To me the above message is a little bit cryptic however -- which bugs have been fixed, and what was their impact ? I know it takes time to write down such information, sometimes called release notes. But I think including this information with the announcements of the stable releases would be a great service to the people reading these announcements. Bart. --
The release notes are there in the shortlog in the email announcement and full Changelog on the kernel.org site for exactly what specifically was fixed: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25.10 If you have any specific questions about any of the individual changes, please let us, and the developers who made those fixes know. thanks, greg k-h --
Adding 2 more addresses to this thread, as they were said to have questions about this kernel release. Again, if the above information is somehow insufficient as to what exactly is fixed in the -stable releases, and anyone has questions about how these release announcements are created, please let me know. thanks, greg k-h --
[spender's asked to be off the CC] not only this one, but every commit for the past few years that fixed bugs with security impact. for reference: http://lwn.net/Articles/285438/ http://lwn.net/Articles/286263/ http://lwn.net/Articles/287339/ what is the disclosure policy used for commits fixing bugs with security impact (both vanilla and -stable, especially if there's a difference)? what do you include/omit? how does it relate to what is declared in Documentation/SecurityBugs? --
Sorry for the delay, was on vacation... As I'm somewhere there is no web access, mind summarizing these if they Personally, I omit posting full "and here is explicitly how to exploit this problem" notices as that is foolish. But also remember that -stable releases are just a compilation of patches that developers have sent to the stable developers, we use the original commit messages as published in the main kernel tree, except where the patch differs, which is rare. So it's not like these releases are any different than the main kernel releases on descriptions of That deals with how security bugs that are sent to security@kernel.org are handled, which is totally different from -stable releases, right? thanks, greg k-h --
a collective one, i take it, as noone else bothered to respond either ;). anyway, you must have been at an interesting place i suppose as you even managed to slip a mail through a wormhole that somehow arrived they're very relevant and rather long, you should take your time and read them whenever you're back on the normal net. or you can do like RMS and so it's full disclosure for both vanilla and -stable, there's no difference? now are they totally different or not? ;) in any case, you say the full disclosure policy applies. what does that mean for you? does it mean omitting security impact information you know about (not 'here is a working exploit' but 'this is a buffer overflow' or 'this is an exploitable bug')? because such omissions have repeatedly occured for the past many years (you'll find several examples pointed out at those LWN do you also omit any of the usual security related words, such as, say, 'buffer overflow', 'security' when describing a bug? say, look at today's 2.6.25.11 and its single fix that doesn't say anything about 'security', heck, not even its announcement does. do you think it's what constitutes you at least add CVE IDs on occasion, mainline commits are even worse in yes, the real and more important problem is with the mainline development itself, you're mostly suffering collateral damage, so to speak. but since you're also part of that development process, you can't hide behind that. so guys (meaning not only Greg but Andrew, Linus, et al.), when will you publicly explain why you're covering up security impact of bugs? and even more importantly, when will you change your policy or bring your process in line with what you declared? cheers, PaX Team --
We went through this discussion a couple of weeks ago, and I had absolutely zero interest in explaining it again. I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no _point_ in letting people know any more. So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special. So there is no "policy". Nor is it likely to change. Linus --
i don't follow you here. you're making 4 statements essentially:
A. 'i want to fix bugs asap'
B. 'i can let people know only when it's not an issue any more'
C. 'there is no point in letting people know when it's not an issue any more'
D. A implies B and/or C
let's see them one by one.
A: fine and even commendable.
B: that's part of the disclosure policy, so be it, although it raises
the question of *when* a bug is no longer an issue. when the fix is
in your git tree? in all/some affected vendor trees? in all affected
linux trees in existence? or does it depend on when x % of the
affected machines is running it? what's your criterion?
C: do you realize what you just said? effectively, 'there's no point
in disclosure'. that's diametrically opposite to what you previously
argued for (rather vehemently, as vendor-sec readers surely remember).
to remind yourself of your own words:
http://lkml.org/lkml/2005/1/12/205
http://lkml.org/lkml/2005/1/12/363
http://lkml.org/lkml/2005/1/13/305
in any case, who decided this? you? did you ask anyone actually
affected (vendors, users, whatnot)? in case you missed about two
decades of security problems and their (mis)handling by proprietary
vendors, this was the *exact* reason why they got shamed repeatedly
in public (does bugtraq mean anything to you?) and why we have
public security mailing lists and a whole industry nowadays.
D: this one is a non-sequitur, the timeline (or even willingness) of
fixing bugs does not imply their disclosure policy. you can surely
fix a bug independently of telling about it. so the question stays:
why do you think not disclosing security impact info at all is good,
security bugs aren't just 'normal bugs', the more serious of them
allow to completely break the security model of the kernel. the world
at large has long ago decided that such bugs *are* special and there's
an entire industry dedicated to finding/fixing/exploiting/etc ...Yes. Because the only place I consider appropriate is the kernel changelogs, and since those get published with the sources, there is no way I can convince myself that it's a good idea to say "Hey script Umm. And they mostly do a crap job at it, only focusing on a small percentage (the ones that were considered to be "big issues"), and because they do the reporting they also feel they have to have embargoes in place. That's why I don't do reporting - it almost inevitably leads to embargoes. So as far as I'm concerned, "disclosing" is the fixing of the bug. It's the "look at the source" approach. Linus --
Btw, and you may not like this, since you are so focused on security, one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior. It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking. Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them. To me, security is important. But it's no less important than everything *else* that is also important! Linus --
True, there are other serious types of bugs (silent data corruption is one particularly nasty one). However, for *any* serious bug, it's important to be clear on what the likely impact is and what's affected. This goes particularly for the ones that might otherwise not be obvious to the person affected until it's too late, such as security and silent data corruption bugs, but really it applies to all serious bugs. I'm not convinced these descriptions are clear enough. Aidan --
if you worry about script kiddies (btw, for someone not bothering with the whole security circus you surely do use their terms as bogeymen to rationalize your stand) triggering or even exploiting local kernel bugs then you imply that they're already local users on that box and that in turn means they have already been having fun all that time. just remember how Andrew put it: But there are so many ways to cripple a Linux box once you have local access. (http://lkml.org/lkml/2005/1/12/379) in other words, try a better argument, possibly without bogeymen. next, what about, say, sysadmins , bigger and smaller distro maintainers, etc trying to figure out whether they need to backport a given fix or not? do you think you're helping them too? on a sidenote, what do you know about script kiddies? how do you think they operate? do you think they're watching a real-time rss from kernel.org to catch the latest and greatest security fixes? do you think they can write PoC or actual exploit code based on commits? last but not least, if i submitted a security fix with the commit message actually saying that it fixes a security problem, would you remove that information before committing? based on the above that sounds as a 'yes', people consider and backport patches that come to their attention, which in turn happens by their scanning the changes, following various threads of discussions (both public and private, depending on what they have access to), etc. if you withhold security impact information then you're skewing their 'big issue' detector as well, further reducing i don't see you embargo normal bug fixes, why would you embargo security when you fix a bug, the commit describes what it fixes without omitting anything relevant. when you fix a security bug, its commit doesn't say what it fixes (not even that it's a security fix, never mind actual impact information), that is, you omit relevant information (based on some ill-conceived argument that i deconstructed at ...
You know what - when nobody does embargoes, I'll consider your argument to have a point. In the meantime, I'm not in the least interested in your idiotic Exactly. I don't embargo them. I refuse to have anything to even _do_ with organizations like vendor-sec that I think is a corrupt cluster-fuck of people who just want to cover their own ass. They're just normal bugs. But that also doesn't mean that I see any reason to make it obvious what to do to trigger them, and cause problems at universities and such. So I don't do "here's how to exploit it" commit logs, for example. (If you haven't been at a univerisity, you don't know how many smart young people want to "try it to see". And if you have been there, and don't think it's a problem when they do and wouldn't be happier if they didn't, you probably don't know what the word "empathy" means). Linus --
Hi, so I'm guessing you're new to the Linux kernel. What you are missing is while *Linus* is unwilling to play the disclosure game, there are kernel developers (many of whom work for distributions, and who *do* want some extra time to prepare a package for release to their customers) who do. So what Linus has expressed is his personal opinion, and he is simply is not on any of the various mailing lists that receive limited-disclosure information, such as the general vendor-sec@lst.de mailing list, or the security@kernel.org list mentioned in Documentation/SecurityBugs. Both vendor-sec and security@kernel.org are not formal organizations, so they can not sign NDAs, but they will honor non disclosure requests, and the subscription list for both lists is carefully controlled. People like Linus who have a strong, principled stand for Full Disclosure simply choose not to request to be placed on those mailing lists. And if Linus finds out about a security bug, he will fix it and check it into the public git repository right away. But he's very honest in telling you that is what he will do --- so you can choose whether or not to include him in any disclosures that you might choose to make. The arguments about whether or not Full Disclosure is a good idea or not, and whether or not the "black hat" and "grey hat" and "white hat" security research firms are unalloyed forces for good, or whether they have downsides (and some might say very serious downsides) have been arguments that I have personally witnessed for over two decades (Speaking as someone who helped to dissect the Robert T. Morris Internet Worm in 1988, led the Kerberos development team at MIT for many years, and chaired the IP SEC Working Group for the IETF, I have more than my fair share of experience). It is clear that we're not going settle this debate now, and certainly not on the Linux Kernel Mailing List. Suffice it to say, though, that there are people whose views on these matters span the entire gamut, ...
Hello! not that new, just not a subscriber, but i've been following it on and Linus has just explained that he does *not* have any stand on full yes, he does that. what he doesn't do is mention the fact that he's Ted, the discussion is *not* about what the best disclosure policy would be for the kernel. the problem i raised was that there's one declared policy in Documentation/SecurityBugs (full disclosure) yet actual actions are completely different and now Linus even admitted it. the problem arising from such inconsistency is that people relying on the declared disclosure policy will make bad decisions and potentially endanger their users. there're two ways out of this sitution: either follow full disclosure in practice or let the world at large know that you (well, Linus) don't want to. in either case people will adjust their security bug handling processes and everyone will be better off. cheers, PaX Team --
Huh? How does what is described there differ from what Linus said, or the -stable team has been doing so far? What specifically are you asking for that is different? The -stable commits are exactly the same as they are in mainline (Linus's tree). Are you upset by the fact that I am not saying, "Hey, look, here's a bugfix that might be security related and here's how to reproduce it!" in big flashing letters? thanks, greg k-h --
From: Greg KH <greg@kroah.com> Don't sweat it Greg. This complaint about "full disclosure" is coming from someone who isn't even willing to communicate with the world using his real name. The ultimate irony, in my book :-) --
Does a symbolic reference change the truth behind it? No, it doesn't. Nor does "David Miller" change the utter idiocy of your commentary. --t --
From: Tiago Assumpcao <tiago@assumpcao.org> That's not the point. The point is that he's a hypocrit because he's not willing to give the world what he expects the world to give back to him. That's, basically, unreasonable. --
where did i expect the world to give out his/her/its real name? also, i'm not talking in my own name really, i don't personally care whether you cheat in your security bug statistics or not, i know better than that and so do many people in the security industry and elsewhere. the actual damage is done to innocent users who may not get timely fixes because you covered them up despite having promised not to do so. any other discussion is irrelevant, --
The point that is not is that of his identity. Be it true or false the inadequacy of his anonymity. BTW, it seems like one previous e-mail regarding the relevant point of the discussion has never arrived. I'll give it a try on resending. --t --
you too are welcome to read the thread. the issue is not full disclosure per se, but your not practicing what you promised. that can be changed either way. as for my real name, it's John Smith. will you take me now your using of this anonymous person's code is probably an even bigger irony ;) http://lkml.org/lkml/2004/7/1/30 --
From: pageexec@freemail.hu It's not about whether your code is correct or not, in that particular case it was, and I therefore merged it. And at the time, if you recall, I did give you a piece of my mind about having to attribute your work using an email that didn't refer to a real person's name. --
read his mails and my responses, it's all in there. basically, he said so himself that he knowingly withholds information. no matter how you spin that, that's not full disclosure. note that i'm not advocating for using that disclosure policy for kernel bugs, it's what *you* guys chose and i'm just asking why you're not practicing it. you're also free to change that doc says full disclosure, it doesn't say 'but withholding this or that'. if you don't know what 'full disclosure' means then you're welcome to ask on proper security mailing lists such as bugtraq or yes, you should include that at least. i didn't say that btw, your fellow -stable maintainer did: 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. (http://lkml.org/lkml/2008/6/10/328) the 2.4 maintainer agreed with him: I don't like obfuscation at all WRT security issues, it does far more harm than good because it reduces the probability to get them picked and fixed by users, maintainers, distro packagers, etc... (http://lkml.org/lkml/2008/6/10/452) i think you're outgunned here Greg. and no, i'm not upset (after all, i'm the one catching you cover up security bugs, right? you're not hurting me), no, that doesn't really belong there but it's a nice addition for certain people. Greg, instead of pretending to be surprised and upset or whatever, go read the whole thread first. cheers, PaX Team --
The only plausible solution people have found to this problem is "letting the world know", so everyone involved in the different stages of IT maintenance can do their part and properly spread the solution throughout the assets. Unless you have a better idea, the full-disclosure policy must remain or Either someone classify and inform it as it is, a *security problem*, or the issue is likely to pass unnoticed by the majority or to not receive the necessary attention by the involved parts. Right. You don't want your developers to be responsible for classifying bugs towards security. Fine. Even though my intuition and personal experience tell that the question must be approached by those deeply involved in the development life-cycle, which, on their side, are responsible for finding, classifying, advising and fixing the security issues. This seems appropriate. Further, this appears to be what the big software houses nowadays do: from early design and development stages, have people to [security] review their applications before deployment, up to giving high attention and adequate support to any reported security problem, afterwards release. Maybe this is all silly and the world is swimming in the wrong direction. Opinions apart, what really matters: we have an ultimate declaration about Linus' tree -- we may forget the pre-official (?) announcement [Documentation/SecurityBugs] and know that someone else must, eventually, classify and inform the world about security bugs existent in their software. From our consumer side, every time an issue of this nature is found, let's pray for some intermediate, gray, angel to send us an "warning" message. Not more I can do but to make sure that all my peers are informed of such a grave reality. Sincerely, Tiago --
The only plausible solution people have found to this problem is "letting the world know", so everyone involved in the different stages of IT maintenance can do their part and properly spread the solution throughout the assets. Unless you have a better idea, the full-disclosure policy must remain or Either someone classify and inform it as it is, a *security problem*, or the issue is likely to pass unnoticed by the majority or to not receive the necessary attention by the involved parts. Right. You don't want your developers to be responsible for classifying bugs towards security. Fine. Even though my intuition and personal experience tell that the question must be approached by those deeply involved in the development life-cycle, which, on their side, are responsible for finding, classifying, advising and fixing the security issues. This seems appropriate. Further, this appears to be what the big software houses nowadays do: from early design and development stages, have people to [security] review their applications before deployment, up to giving high attention and adequate support to any reported security problem, afterwards release. Maybe this is all silly and the world is swimming in the wrong direction. Opinions apart, what really matters: we have an ultimate declaration about Linus' tree -- we may forget the pre-official (?) announcement [Documentation/SecurityBugs] and know that someone else must, eventually, classify and inform the world about security bugs existent in their software. From our consumer side, every time an issue of this nature is found, let's pray for some intermediate, gray, angel to send us an "warning" message. Not more I can do but to make sure that all my peers are informed of such a grave reality. Sincerely, Tiago --
The Security Comunity as a whole (especially the commercial service offices who gat paied to make up new security leaks) is very good in finding, tracking and classifying bugs. This together with the distributors works Well, since most often the developers rely on the same source to be notified about it, its not really a problem. Gruss Bernd --
That means only people with the time, energy, and expertise to create an exploit will have an exploit. This includes probably 90% of the people who would use the exploit maliciously and 100% of the people who pose a real thread to the community. It does, however, ensure that the majority of ordinary users won't be able to test their systems to see if they're vulnerable or if the vulnerability is fixed. So at least it will have some effect. DS --
haven't you ever heard of script-kiddies? they are by far the majority of attacks on systems but do not have the expertise to create exploits. it takes someone else writing the exploit for them and packaging it to make them a threat. in the meantime there's a chance for the fix to get propogated out to a released version and for people to upgrade their systems. providing exploit code along with the bugfix means that the script kiddies have the exploit immediatly, but the fix isn't in any released version (not even a how many people run exploits against their production systems to 'see if they are fixed', very few, and those only on strict schedules with lots of adnvance notice and other safeguards. David Lang --
Nobody is saying you should package the exploit. If they need someone else to package it, they'll still need that. So the question is not if this will deter script kiddies but whether it will deter the people who package exploits for them. And from experience, I can tell you that answer is no. Manys attacks that were believed too difficult for the script kiddies to do were packaged by people who had the expertise and then used by script I can tell you how many run exploits against their production systems when they don't know the exploits exist -- zero. It takes, at a minimum, the knowledge that an exploit is possible. In the cases being discussed, even this was withheld. Fixes will not be widely deployed on a timely basis unless, at an absolute minimum, it is known that there is an exploitable bug that has been fixed. DS --
Obvious exploits are generally written by random "joe hackers" to get a name. However, most kernel exploits are really complex, and written by the person who discover them because they're the only ones with enough People generally don't run kernel exploits on their production systems, simply because either the exploit works as expected and the system remains safe, or it fails, and it generally means system crashes, freezes, or will need a reboot very soon. The same is generally true for proof-of-concepts, but those tend to touch less things and have less side effects in case of To be clear, *I* am for telling people that they might be facing a problem (and for not releasing exploits). This is probably because I work on slow-moving code that people upgrade once a year or so. I know that when you're wondering whether you'll upgrade your system after that long, you need to what it will really fix, otherwise you don't upgrade it. That's why I include indicators when I have them, whether they are about security, or stability. In fact, for people always running latest version and upgrading fast, having all the details or not does not matter much. But as soon as the code starts to stabilize, they don't upgrade that often, and they need justifications for an upgrade. Right now, people running 2.6.25 would have no reason not to upgrade, considering the variety of fixes each version still carries. People running 2.4 or 2.6.16 *need* details. And that's even more true for people maintaining their own kernels or backporting fixes. However, there is a point nobody has evocated here about backports. For a long time I've been annoyed by not finding enough information in some commit logs. But I finally figured that it was as simple as asking privately either the reporter or the patch author to get that sensible information sorted out. So the only remaining hard part of the problem is to identify possible candidates in the huge patch flow that 2.6 mainline it. That's true too for pure ...
Sometimes I have to backport bugfixes to older kernels. In that case it's important to know in which kernel version the bug was introduced. This info is included for some of the bugfix patches in the changelog, but not for all. Bart. --
That's because sometimes no one digs through the code to find this out. I would recommend using 'git blame' to determine this if it is something that you need to have. But for the most part, -stable doesn't really care about older kernel versions, we have to draw the line somewhere, sorry. thanks, greg k-h --
