Slashdot Mirror
Data Corrupting ext3 Bug In Latest Linux 2.4.20
An anonymous reader writes "Andrew Morton alerted readers of the Linux Kernel mailing list today that ext3 in the 2.4.20 kernel has a new bug that can easily cause file data corruption at unmount time. The bug will only affect people using ext3 in "data=journal" mode, which fortunately is not the default... Full details can be read on KernelTrap."
I hope this bug doesn't corrupt the Slashdot datab%(@#LJASLO)aojda2
Forgive me for gloating, but I'm once again elated at how quickly this bug was squashed. Literally hours after the kernel was released, we have a fix available. Meanwhile, Windorks are still getting hammered by the Klez and ILOVEYOU virii. It's a miracle Linux and less popular open source programs like *BSD haven't wiped out the competition entirely.
Of course, I'm sure some of the more bleeding-edge types were bitten by this buglet, but I guess that comes with the territory; backup backup backup! I hope no Slashdotters lost any of their porn collections.
Karma: Good (despite my invention of the Karma: sig)
November 26, 2002 | Paul Thurrott
According to a new Aberdeen Group report, open-source solution Linux has surpassed Windows as the most vulnerable OS, contrary to the high-profile press Microsoft's security woes receive. Furthermore, the Aberdeen Group reports that more than 50 percent of all security advisories that CERT issued in the first 10 months of 2002 were for Linux and other open-source software solutions. The report muddles the argument that proprietary software such as Windows is inherently less secure than open solutions. And here's another blow to the status quo: Proprietary UNIX solutions were responsible for just as many security advisories as Linux in the same time period. Could Windows be the most secure mainstream OS available today?
"Open-source software, commonly used in many versions of Linux, UNIX, and network routing equipment, is now the major source of elevated security vulnerabilities for IT buyers," the report reads. "Security advisories for open-source and Linux software accounted for 16 out of the 29 security advisories--about one of every two advisories--published for the first 10 months of 2002. During this same time, vulnerabilities affecting Microsoft products numbered seven, or about one in four of all advisories."
The stunning report makes several claims that seem to fly in the face of widely accepted beliefs. First, the Aberdeen Group says that Windows-based Trojan horse attacks peaked in 2001, when CERT released six such advisories, then bottomed out this year, when CERT didn't issue any alerts. However, Trojan horse-based attacks on Linux, UNIX, and open-source projects jumped from one in 2001 to two in 2002. The Aberdeen Group says this information proves that Linux and UNIX are just as prone to Trojan horse attacks as any other OS, despite press reports to the contrary, and that Mac OS X, which is based on UNIX, is also vulnerable to such attacks. Even more troubling, perhaps, is the use of open-source software in routers, Web servers, firewalls, and other Internet-connected solutions. The Aberdeen Group says that this situation sets up these devices and software products to be "infectious carriers" that intruders can easily usurp.
According to the Aberdeen Group, the open-source community's claim that it can fix security vulnerabilities more quickly than proprietary developers can means little. The group says that the open-source software and hardware solutions need more rigorous security testing before they're released to customers. This statement is particularly problematic because many Linux distributions lack the sophisticated automatic-update technologies modern Windows versions contain.
We can rail against Microsoft and its security policies, but far more people and systems use Microsoft's software than the competition's software. I believe that we'll never know how secure Linux is, compared with Windows, until a comparable number of people and systems use Linux. But despite the fact that Linux isn't as prevalent as Windows, we're still seeing a dramatic increase in Linux security advisories today. I think the conclusion is obvious.
In 2.4.20-pre5 an optimisation was made to the ext3 fsync function
/* In writeback mode, we need to force out data buffers too. In /*
e read the FAQ at http://www.tux.org/lkml/
which can very easily cause file data corruption at unmount time. This
was first reported by Nick Piggin on November 29th (one day after 2.4.20 was
released, and three months after the bug was merged. Unfortunate timing)
This only affects filesystems which were mounted with the `data=journal'
option. Or files which are operating under `chattr -j'. So most people
are unaffected. The problem is not present in 2.5 kernels.
The symptoms are that any file data which was written within the thirty
seconds prior to the unmount may not make it to disk. A workaround is
to run `sync' before unmounting.
The optimisation was intended to avoid writing out and waiting on the
inode's buffers when the subsequent commit would do that anyway. This
optimisation was applied to both data=journal and data=ordered modes.
But it is only valid for data=ordered mode.
In data=journal mode the data is left dirty in memory and the unmount
will silently discard it.
The fix is to only apply the optimisation to inodes which are operating
under data=ordered.
--- linux-akpm/fs/ext3/fsync.c~ext3-fsync-fix Sat Nov 30 23:37:33 2002
+++ linux-akpm-akpm/fs/ext3/fsync.c Sat Nov 30 23:39:30 2002
@@ -63,10 +63,12 @@ int ext3_sync_file(struct file * file, s
*/
ret = fsync_inode_buffers(inode);
-
- * the other modes, ext3_force_commit takes care of forcing out
- * just the right data blocks. */
- if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)
+
+ * If the inode is under ordered-data writeback it is not necessary to
+ * sync its data buffers here - commit will do that, with potentially
+ * better IO merging
+ */
+ if (!ext3_should_order_data(inode))
ret |= fsync_inode_data_buffers(inode);
ext3_force_commit(inode->i_sb);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
-- Note: If you don't agree with me, don't bother replying. I won't read it.
In fact, there is a reply to that on LKM:
In fact it was reported on lkml on 18th July IIRC before 2.4.19 was
released if that is any help to you. 2.4.19 and 2.4.20 are affected
and I haven't tested previous releases. I was going to re-report it
sometime, but Alan brought it to light just the other day.
Nick
-- Note: If you don't agree with me, don't bother replying. I won't read it.
So, I'm clueless. But there's a lot of smart people on Slashdot. No, really, how often does one actually unmount a volume at home? In a production environment? When you shut down, is an unmount performed? If so, is the cached metadata and data flushed manually beforehand? Does this mean it's safer to simply reboot one's computer rather than carefully shut it down?
You like splinters in your crotch? -Jon Caldara
JUST DON'T SHUT YOUR SYSTEM OFF! MUWAHAHAHAHAA!!
just kiddin'
Fortunately, this bug didn't make it into 2.5 so it won't be propogated forward. Hint: the quick fix ISN'T a quick fix, it doesn't work.
Either stick with 2.4.19, don't use journaled file data, or sync before umounting (I do that anyway... just superstitious I guess ^_^).
It will take a few days to add some extra magic to the umount logic to flush all buffers in an intelligent way. Hopefully this optimization is worth the effort for dudes with high-uptime.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Oh well, I'm sure there's a story about IE not rendering a page right out there somewhere.
Why didn't this make it to the front page? It would be prudent to warn the visitors who don't regularly check the developers section, so that they can take appropriate measures to avoid corruption. This is just plain irresponsible.
I think the answer here is simply to avoid any Linux kernels released close to Thanksgiving.
Tarsnap: Online backups for the truly paranoid
Let's have a close look at the costs involved when running a Linux system.
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.
I just got a similar report of a bug from a Accounting software vendor alerting us to a bug in Windows.
Apparently in W2k SP1 MS broke something that caused data not to be writen from disk cache to the actual disk, which caused data corruption. This was only fixed in SP3.
I just find it interesting that this bug was not common knowledge as it is not really a "security" issue so they can't hide behind that smoke screen.
Ironically, yes. Since it only affects you when unmount a disk, and the only reason i unmounted a disk was to reboot the kernel after recompiling with the bug fix!
Oh well, it's not as if i have anything better to do than surf for porn. And my dick could use a rest from the constant masturbation.
Do you even lift?
These aren't the 'roids you're looking for.
Windows has bugs.
Linux people fix bugs.
Microsoft people fix bugs.
Linux users don't patch.
Microsoft users don't patch.
There's still a key difference. We've the ability to set many more eyes upon our code. Remember kids, download a development kernel today!
Troll? Bear with me here T-R-O-L-L. I've never had any ext2 filesystem damage after using this kernel.
BTW, if you use ext3 with the default mount options, you will not run into this problem. Its only if you override the mount default of data=ordered and use the data=journal option that the problem even occurs.
Hell, it took me several minutes of searching to even find out what the option was to even cause the problem. Something tells me this won't affect many people. Maybe someone who knows ext3 internals will enlighten us with why someone would want to use data=journal.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
can I get around this shyte by using alan cox's developmental tree?
I always wait several days now before I even start to experiment with a new kernel. Probably good practice anyway :-)