OOPS! Sometimes Even Linus Gets It Wrong!

“Today, October 20, 2016, Linux kernel maintainer Greg Kroah-Hartman announced three new maintenance updates for the Linux 4.8, 4.7, and 4.4 LTS kernel series, patching a major security vulnerability.
Known as “Dirty COW,” the Linux kernel vulnerability documented at CVE-2016-5195 is, in fact, a nasty bug that could have allowed local users to write to any file they can read. The worst part is that the security flaw was present in various Linux kernel builds since at least the Linux 2.6.x series, which reached end of life in February this year.”
See Linux Kernels 4.8.3, 4.7.9 & 4.4.26 LTS Out to Patch “Dirty COW” Security Flaw
Ouch! This could be a pathway to rooting */Linux machines all over the world. At first I thought I had fixed this here but I missed one machine in the living room that used one of those series of kernels. Fixing it as I type.

Having lived for a decade with a gaping vulnerability it gives little comfort to think those who use That Other OS live with such updates almost monthly.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , . Bookmark the permalink.

26 Responses to OOPS! Sometimes Even Linus Gets It Wrong!

  1. oiaohm says:


    Ivan you need to read more vxworks also happens to be infected by Psyb0t its a two platform virus. Linux and Vxwork. So worm viruses can be multi platform.
    Symantec and others don’t provided scanning software for vxworks and other embedded platforms so they pretend infections in those platforms don’t exist so leading to people reading their documentation and attempting to remove something like Psyb0t because you are being reinfected by the vxwork device or other non Linux/Windows/OS X device that the infection you have got happens to run on.

    There are quite a few flaws in vxworks stuff. PsybOt happens to infect devices by a flaw that was duplicated between vxworks and Linux routers allowing arbitrary code to run. So after PsybOt got code running then it identified the OS and used the correct install process.

    DrLoser No Ivan challenge is complete wrong. These multi platforms worms that are a true pain to remove.

  2. DrLoser says:

    @ kurks: Psybot was a linux worm, not vxworks.

    Easy mistake to make, if you are an abject cretinous moron, Ivan.
    Let’s give Kurks that, at least.

  3. oiaohm says:

    Compared to a proprietary OS vendor who demands (and uses the proprietary license as an enforcer) that the kernel be mandatorily shipped together with the update tool?
    Do all proprietary license OS always enforce this . The answer is no and this does include Microsoft. If you have router or some other IoT based on vxworks you may not have update tool either. So this problem of updates is not Linux or Open Source only many wish it was.

    For Ivan as well
    Here is a vxworks device back in 2009 suffering from infection. They still don’t have a proper update process as part of licensing vxworks. Lets just say anything IoT has major update problems. We cannot say its Linux only but Linux is the largest OS in that segment but every OS proprietary or open development in IoT has the same problem of not deploying updates. Some of the problem is how many IoT devices and routers are one off chip and board things.

    Then when you look at Windows 10 embedded that is basically Microsoft version IoT part of the install customisation include the option to remove Windows update. So kiss good bye to you proprietary OS update provide support as soon as you under the IoT and embedded world. Attackers are finding the embedded world a gold mine of unpatched items that will never be patched.

    Is this model suitable to provide secure devices to users, compared to the “complete OS” solution Windows 10 offers and the “all in-house” solution iOS offers?
    Windows 10 mobile only on Microsoft approved SoC chips for the new versions. If you have the first generation of Windows 10 Mobile you can strike that it not updating because the OEM is in full control of the update process. So what is the difference between current Windows 10 mobile and iOS solution from a hardware point of view basically nothing. Why the only accepted SoC chips for current windows 10 mobile is Qualcomm. So you want to use arm SoC chip from vendor of your choice as a ODM/OEM you have to go Android or something else strange.

    Windows 10 Mobile is a joint development between Qualcomm and Microsoft. So its basically in-house pretending not to be.

    Thing to remember android does ship with kernel update system if it did not items Google Nexus android devices would not be able to update android versions. So Google in-house android devices work perfectly.

    Who is responsible if a security vulnerability goes unpatched and causes a security havoc on users?
    Good question and that is the one you need to answer to understand what is going wrong.

    Unfortunate due to laws in most countries the software and hardware provider is allowed to sell as is where is. So in most countries the owner of the device is responsible. This is something that does need to be changed under law big time.

    Due to the IoT mess being everyone in the market we really do need regulation that mandate update systems be included.

    Basically you need to go back and read this kurkosdr. We need a lot more durable update system. Current issue is like 90%+ of the IoT and Android Phones devices could take the updates and in reality less than 5% will get the updates. Why ODM/OEM is not game to attempt pushing out a update because of the way the laws are written. ODM/OEM leaves you with a insecure device it your problem as the owner under most countries laws no cost to the ODM/OEM for doing that. ODM/OEM/software vendor pushed out an update that happens to brick your device they have to repair the device under law so costing them money. So the 10% of failures would cost them money.

    So we need a 100 percent dependable update system for IoT devices and Phones that never fails to the point ODM/OEM has to pay money or the laws have to change so it costs ODM/OEM money leaving insecure devices out in the market.
    Otherwise we will never see updates dependably on IoT or Phones.

    Focusing in on Linux as something to blame in the IoT and Phones is being a idiot. The way the laws are written have caused the mess. There is no fully developed update solution good enough to be used in the phone or IoT segments with the varieties of SoC involved so if all IoT and Phone makers changed OS today the problem with the new OS they changed to would be exactly the same.

    When I say good enough is a update system that you can push out to a device something that does not work on that device and the device detects the failure reboots and undoes the update so keeps on working and informs user device cannot be updated and for owner of device to check if the device is end of life or not. So OEM/ODM would not have to fear pushing out updates or letting third parties push out updates.

    Debian might be a complete OS but it update system is not good enough for the phone or IoT market. Only update systems that currently in work phone market are restricted to a very limited number of SoC chips where the vendors have the resources to-do quality assurance every update on each individual SoC chip.

    Think debian desktop/server it update a kernel it leave the old kernel installed in the bootloader. so if new kernel fails you sit at the machine boot up choose the old kernel and you system stays working. This process is what dooms you on a IoT or Phone. This must be done automatically because until the kernel fire up there is no network or user input. So there is a unique headache to a IoT or a Phone and this is causing updates not to be deployed. Currently there is no fully functional solution to this problem. Work to find solution to this problem only started end of 2015.

  4. Deaf Spy wrote, “if APT was such a hot thing, why do you compile from source?”

    Because it’s:

    • easy,
    • allowed by the software licence,
    • is the quickest way to distribute a critical security update, and
    • keeps an old man relevant.

    UPDATE The latest kernel update, to 4.7.10, took 8.5h to build thanks to Intel’s anemic Atom processor. We have a really feeble CPU in one machine. An Odroid-C2 will soon replace it. A build on that only takes about 30 minutes.

    “dpkg-deb: building package `linux-firmware-image-4.7.10′ in `../linux-firmware-image-4.7.10_4.7.10-1_amd64.deb’.
    dpkg-deb: building package `linux-headers-4.7.10′ in `../linux-headers-4.7.10_4.7.10-1_amd64.deb’.
    dpkg-deb: building package `linux-libc-dev’ in `../linux-libc-dev_4.7.10-1_amd64.deb’.
    dpkg-deb: building package `linux-image-4.7.10′ in `../linux-image-4.7.10_4.7.10-1_amd64.deb’.
    dpkg-deb: building package `linux-image-4.7.10-dbg’ in `../linux-image-4.7.10-dbg_4.7.10-1_amd64.deb’.
    dpkg-genchanges: binary-only upload (no source code included)
    real 502m40.704s
    user 1179m52.232s
    sys 85m6.232s”

  5. DrLoser wrote, “glom on to an underprivileged area as a totally unqualified “teacher,” rip that area off, and leave total devastation in your wake.”

    I was a very respected and valued teacher in most places I went. There were a few exceptions but just like IT has BOFH, there are a few bad principals/directors of education. I did the best I could with meagre resources and the IT I developed in the North worked very effectively for students and teachers. I guess Easterville is overdue for a refresh but the methods I used are still valuable today. Some installations I did worked flawlessly for many years without an in-house guru.

  6. kurkosdr wrote, “Who is responsible if a security vulnerability goes unpatched and causes a security havoc on users?”

    M$ doesn’t guarantee perfect code either… They don’t even hurry when their OS is falling down and breaking into shards of glass. Smartphones and IoT are still a new tech with new players who have to learn the hard way how to keep and grow their base of customers. M$ did it by lock-in. The smartphone makers would be wise to form a cooperative group to take care of software so they don’t have to do their own poor job but can develop a robust and flexible system. Google kind of short-circuited steps for their own reasons and left the OEMs dangling along with users. Google should take a lot of the blame for that starting with not using GPL for a licence. Linus chose the GPL for good reason. It automatically shares the load and allows the best code to float to the top because it’s all visible. Hidden code is far from optimal. The Linux Foundation missed the train on this too. They concentrated too much on servers for too long and Google pushed them aside. There are plenty of mistakes to go around but by now everyone knows these issues and have good reasons to do the right thing sooner or later. If Google had adapted GNU/Linux for smartphones instead of reinventing the wheel, the world would be a much better place.

  7. kurkosdr says:

    Just to be clear with my question:

    Is dropping a pile of open source kernel code without any kind of provisions for patching ethically right towards end users? Is conveniently blaming OEMs (while acting as an enabler for their carelessness) right? Compared to a proprietary OS vendor who demands (and uses the proprietary license as an enforcer) that the kernel be mandatorily shipped together with the update tool?

    Did I just hit you right in the ideology?

  8. kurkosdr says:

    compared to the “complete OS” solution Windows 10 offers = compared to the “complete OS” solution Windows 10 Mobile offers

  9. kurkosdr says:

    Yes it’s called APT in Debian GNU/Linux, Advanced Packaging Tool.

    Because Debian GNU/Linux is a complete OS (a crappy one, not supporting switchable graphics and having bad battery life even on single-gpu systems and all, but complete OS nevertheless) .

    Thing is, I am referring to the unpatchable mess that IoT and smartphone vendors have created, built on top of the Linux kernel. Do we really want OEMs to take just a kernel and built and unpatchable mess on top of it? Who is responsible if a security vulnerability goes unpatched and causes a security havoc on users? The kernel community or the vendor? Theoretically the vendor is responsible but what if the community has made the new version of the kernel not run well on the vendor’s hardware for whatever reason? Is this model suitable to provide secure devices to users, compared to the “complete OS” solution Windows 10 offers and the “all in-house” solution iOS offers? Did I just hit you right in the ideology?

  10. dougman says:

    Fanboi’s be bashing Linux, but bash be running on Windows 10.


    Which, brings me back to some earlier statements that I made. I can see both OS’s merging down the road.

  11. Ivan says:

    it gives little comfort to think those who use That Other OS live with such updates almost monthly

    Meanwhile, all of those cheap security cameras, dvrs, modems, routers, and thermostats that stupidly use linux are being used to compromise sites. Good job.


  12. Deaf Spy says:

    Be not so harsh, dear Doctor. Poor Robert had no way of knowing his bet “year X (1990-) will be the year of Linux on desktop” will always be a losing one. Of course, he’d say all his students were thrilled with joy by seeing “no re-re-reboots, no malware, no blah-blah, yackety-smackety”. And no so thrilled some years later, when they show up on their job-seeking mission with totally irrelevant IT skills.

    I am actually more interested in how many of Robert’s students made a notable career in Robert’s professional area of teaching. That’s Physics, isn’t it, Robert? What can you say about your students?

  13. DrLoser says:

    What is the number, then, Robert? I notice you are suspiciously quiet on the subject.

    10 potential IT careers in Northern Manitoba wrecked? Fifty? A hundred or more?

    Or maybe you can point to a single solitary success, wherein one of your students gained useful employment cleaning floss out of a dumpster-dived PC (and as I recall, this particular bit of your “teaching” experience went down very well with your Principal, according to you).

    Tell us about this.

    Or perhaps you managed to eke out a single student who contributes to the FLOSS economy. There are obviously several ways to do this.

    Tell us about this.

    You can’t, can you? All you did is to glom on to an underprivileged area as a totally unqualified “teacher,” rip that area off, and leave total devastation in your wake.

    Standard Freetard behaviour, if you ask me.

  14. Deaf Spy says:

    Kurks speaks of Android (Linux kernel), Robert speaks of Debian (Linux kernel)… “Is you is, or is you ain’t my babe”.

    Btw, Robert, what is exactly the use of APT when there is no fix for the issue over last few years? And, if APT was such a hot thing, why do you compile from source?

  15. oiaohm says:

    The biggest issue is not how to distribute updates. Its how to distribute updates and be able to fix the device if they fail. Because in a soc diverse world there is always going to be the update that fails to boot.

    Really the idea of doing proper atomic updates on IoT things only started in 2015. With a lot more work required in 2016. So system attempts update it fails to boot you reboot device and the device returns to what it had before. Failure need to equal return to prior working state.

    Windows update is this thing atomic update system the answer is no it not. Is the update system in iphones and OS X machines atomic no they are not.

    The solution to the android and IoT update problem we cannot look to Microsoft or Apple for answers because they don’t have the answer. Can we look at what Debian does today no because that does not have the answer either.

    Devices where when they fail to be able boot you may not be able to repair them is a lot different problem to a PC where you can put in a disc with a OS on and boot from that to fix. In fact a phone/IoT device has a lot in common with a remote server somewhere and attempting to update it and there be no support staff or automatic watchdog to restart it if the thing goes wrong. Yes most phones and IoT soc chips lack a watchdog timer to force reboot the device if OS fails to start correctly and report to the boot-loader that a boot failure happened.

    kurkosdr so some of the problem is the ODM and SoC chip designer fault not including useful hardware for safe software updating. Yes watchdog can be third party chip or in the SoC.

    Old saying it take two to tango. When it comes to making a device that can be software updated safely with min risk of failure(preference zero no booting failures yes automatic roll back is acceptable). Its not two to tango any more a square dance of ODM, OEM, SoC and Software provider all doing the right things. Currently the square dance for IoT and Android phones looks like all parties have had way too much to drink and cannot walk straight let alone dance. Ok only a little less drunk than Symbian OS phone makers square dance who were basically completely drunk who could not get up to even attempt to do a update.

    I will give you that OSi and Windows 10 Phone updates square dance does look more sober but the number of people dancing is quite min as well. What they are doing will not scale the way that is required.

    Remember the ODM and SoC can make the device then the OEM sets the boot signing keys using a method that does not let anyone else update. Can this happen if the software is from Microsoft. Answer yes even that Microsoft current rules so call forbid it. Some of the reason Microsoft has limited SoCs and limited OEMs.

    All we can do is hope atomic updating systems become more common and OEMs come more accepting of users updating from software vendor directly. Of course OEM will not want to let users update from software vendors if the result will be lots of complaints from end users that their device does not boot and is now bricked.

    It is so simple to say OEM should let go of control. The big thing people always forget is how simple it is to brick a Phone or IoT that a normal user cannot fix it. The bug that needs solving is making Phones and IoT devices absolutely resistant to bricking due to a invalid update then it will be way simpler to get OEM to reduce controls.

  16. kurkosdr wrote, “Is there a consistent, OEM-independent patching mechanism in place?”

    Yes it’s called APT in Debian GNU/Linux, Advanced Packaging Tool. It works very well. I guess you’re concerned about hardware/software but that’s all being merged into Linux and will be as smooth as x86/amd64 sooner or later.

  17. kurkosdr wrote, “it is this “contact your OEM, not our fault” nonsense that gives me revulsions when I think of Linux.”

    You’re digging a little deep to find mud to sling. GNU/Linux is pretty smooth on x86/amd64. It’s still a bit rough on the little Odroid-C2 but this too shall pass. My OEM has had nothing to do about it since I bought it. That’s OK for me. It just keeps working smoothly.

  18. oiaohm says:


    kurkosdr first thing to remember until Windows 10 mobile updates did not come directly from Microsoft on mobile devices instead had to come by OEM. Yes early Windows 10 phones still only get updates when OEM decides to provide them.

    How can Microsoft now provide Windows 10 mobile phone updates is Windows 10 mobile new phones have a restricted list of SOC chips they are allowed to use. How does iphone do it the same way. Restrict the SOC chips allowed to be used.

    IoT and Android phones have a hugely diverse SOC chip collection so making updating insanely hard.

    Big issue is how to fix events like this in a soc or a phone. This is why windows update for windows phone until new windows 10 phones did not in fact alter kernel or drivers. Google has move more parts of Android to google play to allow those parts to be updates without touching the kernel so very much the old Microsoft phone model. So we cannot look to Microsoft or Apple to the solution to this problem. They solve the problem by simply saying you will only use X make of chips.

    DrLoser due to how long bugs are lasting from introduction to runtime detection of the most common with Linux kernel 4.9. Then they will do the next most common and so on. So those numbers guide kernel design alterations.

    Of course, five years is good, isn’t it?
    Under 9 years is in fact good. There are quite a few bugs on Windows that turn up this year that if you test backwards they have been in Windows for over 10 years. You can swap windows for OS X as well.

    Reality is there is security flaws coming out of almost everything and most have been present for years and not detected.

    The dirty cow fault is bad but story behind the function is even worse and sadly cross platform.

    get_user_pages() that Linus was attempting to fix when the bug was created and this is to attempt to prevent drivers from doing something.

    If you look up “Kernel Self Protection Project” you will see introduction of alterations to covering the following “Do not allow direct physical memory access”.

    There is a little bit of evil here that is really scary. Different drivers under Windows, OS X and Linux have had the habit for so called performance reasons(NVIDIA, ATI/AMD, Intel…) of having kernel driver directly using physical memory access to send data to userspace and read data from userspace. So yes a few Nvidia driver busts on newer Linux kernel at times was the Linux kernel putting in runtime enforcement to prevent drivers from directly going to physical memory write. Now this bring a problem why do older Nvidia drivers still work under Windows. That right that protection has not be implemented yet.

    This is the problem Linux is not perfect but Windows and OS X can in fact be worse. Some of the break thing issues complained about with Linux is that it not possible to get from our current grade of OS security to improve OS security without breaking a few things.

  19. kurkosdr says:

    BTW, it is this “contact your OEM, not our fault” nonsense that gives me revulsions when I think of Linux.

  20. kurkosdr says:

    That Other OS live with such updates almost monthly

    Glad you mentioned updates. No matter how many such updates Windows needs (I will take your word it needs them monthly), all versions of Windows (even Windows Phone) come with Windows Update which distributes patches in an OEM-independent manner.

    BUT, how are all those Android devices running all those OEM Android “ROMs”, and all those Linux IoT devices going to be patched? Is there a consistent, OEM-independent patching mechanism in place? You know, something like Windows Update? No? If so, maybe it was a awful idea to make Linux the base of smartphones and IoT devices and not using a Windows base, which is a complete OS with its own updating mechanism, instead of leaving the task of updating to the OEM who baked the ROM or kludged together the IoT firmware (hint: bad idea)

  21. DrLoser says:

    Of course, five years is good, isn’t it?

    After all, as Robert sagely observes, it’s better than having monthly updates disrupting whatever Robert was doing, which presumably wasn’t very much apart from destroying what few IT career opportunities you get as a Native American kid in Northern Manitoba.

    How many children’s futuresdid you destroy through your utter and total ineptitude, Robert?

    100? 500? Am I close?

  22. DrLoser says:

    It’s obnoxious. More so because even while sites like The Guardian, just to pick on one, usually refuse to cover GNU/Linux at all, not even for the 25th anniversary of the kernel, they fall over themselves to publish these logos and gaudy names.

    Or then again, not.
    Do you read the Guardian or the Observer, Modwit? Both Naughton and Schofield have covered Linux extensively. I’d even say that Naughton in particular is heavily predisposed to FLOSS – read one of his books, if you don’t believe me.

    Here, for general Guardian Linux coverage

    Here, for an example of Schofield’s approach

    Apparently you’re just another insane FLOSS conspiracy theorist, aren’t you? Never mind. The first link, amongst other things, leads us to an interesting little site that monitors the metrics of Linux Kernel Bugs.
    An average of five years, apparently. The Toe-Fungus Dude Abides!
    Incidentally, those stats are from a Linux supporter, as you can see from the penguin in the top right of your screen. Apparently the commenters don’t quite get it …
    As usual for freeloading ignorant freaks.

  23. dougman says:

    I updated to kernel 4.8.3 the other day.

  24. Yes, and Debian still does not have an update for linux-image-4.7. I’m building from source to fix that and my affected machine is a slowpoke.

  25. Modular sunfish says:

    It’s a real bug. The real name is CVE-2016-5195

    M$ minions have started giving fancy names to CVEs to stir up Fear, Uncertainty, and Doubt regarding use of GNU/Linux. CVE-2014-0160 and some related CVEs even get their own fancy logo and their own web site. With CVE-2014-0160 and company, the custom web site was actually marketing for the second group to find the bugs. They even went as far as to hire a graphics designer for the logo prior to the public announcement of the bug.

    It’s obnoxious. More so because even while sites like The Guardian, just to pick on one, usually refuse to cover GNU/Linux at all, not even for the 25th anniversary of the kernel, they fall over themselves to publish these logos and gaudy names.

    The cause of the bug is one thing but the reaction, the marketing, is another. That marketing is probably distracting from something important. It usually is when M$ is concerned.

Leave a Reply