these ADHD kids *tsk* *tsk* they should stick to Java or something safe.
Developers have exterminated two bugs from the Linux kernel that threatened the security of people using the open-source operating system. The most serious of the two is remote denial-of-service vulnerability that made it possible for attackers to crash systems by sending them oversized packets. The underlying null pointer …
I ran the website on that. Great bug that one - while testing I had a guy from California take out my server in the UK with one ping, and I was getting email from all over the place with people telling me they'd trashed mainframes, print servers, routers, the lot. I've never seen OS vendors put out patches so fast - a kernel panic sure does sharpen their response...
Shonko Kid isn't entirely wrong, a null pointer dereference is a unforgivable error in kernel patch which should have undergone significant review. Now reviewing someone else's code isn't fun, it's not something I enjoy, but it is a requirement of all patches to the kernel so someone was asleep on the job. I'm not levelling blame at anyone in particular, but it does seem that with the pace of current kernel development this sort of thing is going to happen more frequently. Most static analysis tools will have no trouble finding simple null pointer de-reference mistakes, some even manage to find the more obscure ones with a low number of false positives, so maybe it's about time that all kernel patches are automatically put through a battery of tools before they even go to peer review.
To answer the obvious question, yes I have code in the kernel and other open source projects.
Dear God, is anyone actually using ext4 in production? There again, my illustrious predecessor used three or four different file systems on our Linux boxes, just because he could. That crappy journaling file system from IBM was the worst - memory usage through the roof as it tried to pre-cache everything by the looks of things.
Maybe I shouldn't be surprised that Ubuntu and Fedora are doing that, but I am. Someone please correct me if I'm wrong, but my impression is that Ext2 remains the best bet for Linux filesystems, unless you have a real need for filesystem performance. Ext2 is stable and well tested, and linux has plenty of recovery tools for it. Even other mature filesystems like xfs, reiser, and jfs seem to lack the same support on Linux.
If you run into a strong need, you can always upgrade ext2 to ext3 or ext4, but I don't think you can go backwards. Given Ubuntu's target demographic, do the performance benefits of ext4 really outweigh the risks, or is this just a case of some hacker geeks who are happy to have the latest and greatest on their own machines sharing the joy with everyone else? As I get old and boring, I increasingly lean towards avoiding unnecessary risk.
You're wrong. :-)
Ext2 is not a journaling filesystem so it's unacceptable for storing anything you care about. Ext3 is basically ext2 with journaling and is more the de facto standard in Linux filesystems right now. Not that it's the only one worth using - I personally have at least 4 different ones in use on my home machines and there were good reasons each one was chosen.
It should really come as no surprise to anyone at this point that Ubuntu would be shipping a bleeding edge filesystem as the default. It's more mature than a lot of the software that they include.
This post has been deleted by a moderator
Open source does not mean throwing code together and hoping for the best. A simple error like this should have been caught before the patch was accepted into the kernel and definitely before that kernel was officially released. I dare say there are some open source projects which lack proper management and follow the slipshod development style you suggest, but most project's aren't run by baboons and the kernel least of all. Someone, somewhere in the very long chain of responsibility needs a good kicking.
We're not talking about an obscure bug here which can easily escape even an experienced eye, but a rookie coding error.
Biting the hand that feeds IT © 1998–2022