| |||||||||||||
UnionfsUnionfsPosted Jan 13, 2007 0:33 UTC (Sat) by giraffedata (subscriber, #1954)In reply to: Unionfs by dlang Parent article: Unionfs
later messages in the thread indicate that the warning is (somewhat) intentionally overstating the risk of an oops Do you mean the warning is a lie and it is not in fact possible by design to oops the kernel by modifying an underlying filesystem? Because that's the only way it's sensible. You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time.
(Log in to post comments)
Unionfs Posted Jan 13, 2007 4:52 UTC (Sat) by raven667 (subscriber, #5198) [Link] You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/ hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time. That seems like how it should be but I doubt that this is true. In fact I believe one of the major fixes in 2.6.19.2 is CVE-2006-5823 a problem where a corrupte cramfs could OOPS the kernel. This same kind of think can, has and will continue to happen in the filesystem, USB, network, Firewire, block device and other subsystems where bogus data from a piece of hardware isn't sufficiently checked before being used and causes an OOPS (with potential security implications.
|
|||||||||||||