Chromium 49 packages address security issues; no more 32-bit binary plugins

chromium_iconChromium 49 was announced on the Google Chrome Releases blog. I needed some time to compile package for my ‘ktown’ repository containing the KDE Plasma 5 environment. In fact it took more time than anticipated because I had upgraded my QEMU from 1.2.0 to 2.5.0 and that had unepected side effects: it severely affected the performance of the host server (running Slackware64 13.37 and a kernel) and decreased the Virtual Machine speed to almost half. And when the VM froze while I was compiling chromium in it, I had enough. I reverted to QEMU 1.2.0 and all is well again.

Anyway, the new chromium 49.0.2623.75 release addresses a couple of security issues – some of these have a CVE number:

  • [$8000][560011] High CVE-2016-1630: Same-origin bypass in Blink. Credit to Mariusz Mlynski.
  • [$7500][569496] High CVE-2016-1631: Same-origin bypass in Pepper Plugin. Credit to Mariusz Mlynski.
  • [$5000][549986] High CVE-2016-1632: Bad cast in Extensions. Credit to anonymous.
  • [$3000][572537] High CVE-2016-1633: Use-after-free in Blink. Credit to cloudfuzzer.
  • [$3000][559292] High CVE-2016-1634: Use-after-free in Blink. Credit to cloudfuzzer.
  • [$2000][585268] High CVE-2016-1635: Use-after-free in Blink. Credit to Rob Wu.
  • [$2000][584155] High CVE-2016-1636: SRI Validation Bypass. Credit to Ryan Lester and Bryant Zadegan.
  • [$500][560291] High CVE-2015-8126: Out-of-bounds access in libpng. Credit to joerg.bornemann.
  • [$2000][555544] Medium CVE-2016-1637: Information Leak in Skia. Credit to Keve Nagy.
  • [$1000][585282] Medium CVE-2016-1638: WebAPI Bypass. Credit to Rob Wu.
  • [$1000][572224] Medium CVE-2016-1639: Use-after-free in WebRTC. Credit to Khalil Zhani.
  • [$1000][550047] Medium CVE-2016-1640: Origin confusion in Extensions UI. Credit to Luan Herrera.
  • [$500][583718] Medium CVE-2016-1641: Use-after-free in Favicon. Credit to Atte Kettunen of OUSPG.
  • [591402] CVE-2016-1642: Various fixes from internal audits, fuzzing and other initiatives.

It is advised to upgrade to this version of Chromium.

Please note that Google has stopped providing 32-bit versions of Chrome for Linux. This means that I will no longer be able to supply 32-bit plugins for Pepper Flash and for Widevine CDM support. The 32-bit plugins currently in my repository are taken from the Chrome 48 RPM and they will probably just keep functioning for a while. However I have no idea when they break, and particularly the Pepper Flash plugin will age pretty fast, considering the fact that Adobe releases security updates for Flash almost every month. YMMV.

Get my chromium packages in one of the usual locations:

The widevine and pepperflash plugin packagess for chromium can be found in the same repository.

Have fun! Eric

19 thoughts on “Chromium 49 packages address security issues; no more 32-bit binary plugins

  1. Hi Eric,
    I upgraded this morning, and Chromium actually reverted to 37xxx from 13.37. That was weird. I had to manually upgrade sbbdeps because of an md5sum error. I am using the UK mirror. I do run -current.

  2. It’s just a guess, but I think I remember one QEMU upgrade where the names of the qemu executables changed, resulting in my VMs accidentally starting in some sort of software emulation mode (i.e. no KVM) after the upgrade, which made everything *very* slow. Explicitly running “qemu-system-x86_64” and adding “–enable-kvm” (is it needed?) fixed that.

  3. Yes, “–enable-kvm -machine type=pc,accel=kvm” was required to get it back up to speed, but the strain on the host was unacceptable even when the VM was running in idle mode. I assume this is because the newer QEMU releases are not written for the KVM in this old 2.6 kernel but are exploiting the capabilities of the new 4.x kernels.
    The VM itself had barely half the performance of my old qemu-1.2.0 instances, so the choice to revert was an easy one.

  4. Eric, Re: qemu, I actually have qemu-kvm-1.2.0-x86_64-1alien and qemu-2.3.0-x86_64-1sl installed.

    I believe I reinstalled you package because of the same problem (Slack 14.1 64 bits here), should remove qemu-2.3.0 and reinstall you package to make sure I only use bits from yours and not slacky’s.

    Are you using qemu direclty or through libvirt?

    I’m using libvirt (from SBo) and in my VMs I have:


    I have a vacation coming and I’m hoping to fiddle with this again, I’ll report back my findings if I can make it work with libvirt.

    Oh, and thanks for the new Chromium 🙂


  5. Hi there!

    It’s just me or this new chromiun version doesn’t respect the mouse scroll direction anymore?

    It doesn’t matter what the system wide setting says (regular/inverted), it always scroll regular.

    All other software (incl. firefox) respect that scroll direction. Just chromiun is off.

    This was not the case with version 48.

  6. For those facing regular scrolling after chromiun 49, this have fixed it to me:

    In that page, all other methods before this one have failed.

    It’s a per user setting (the post is wrong about the system wide part). Luckily, it’s consistent across all applications if you remember to disable any inverted scroll setting in your DE.

  7. Hi Eric “chromium current” seems there may be something wrong with your build not detecting cubeutil. if flash it will read chromium and or no sound in pavucontrol because no playback.
    I do not have this problem with my CEF3 builds of the chrome 49 . CEF you actually build chromium then build the embedded part. Going to rebuild yours and look at your config.

  8. Drakeo – don’t even know what cubeutil is, how does it relate to Chromium?
    Also your sentence “if flash it will read chromium and or no sound in pavucontrol because no playback” does not make sense to me.

  9. Pingback: Links 8/3/2016: Future Kodi Veraions, Solus 1.1 | Techrights

  10. It is stuck at linking so I am unable to finish the build.
    I am unable to get any feed back. but after 30 minute wait for it to link there is an issue.
    I will get back with you I will figure it out turn up the Verbose a tad.

  11. OK figured it out Was testing MIXXX builds left a .asoundrc
    file down. Everything works great.
    About the linking I will look into that that is after today’s latest update.
    I am sure it is on my end.

  12. The final linking stage of chromium can take a long while and especially it takes a _lot_ of RAM. If you get errors during the linking stage, consider adding more swap.

  13. hi,
    well done as always, but you may want to update the development version too, since it is now quite older than the stable version now. tanx, and cheers

  14. Hey, it’s the development version, so I added it only for people to play with; it should not be used in production anyway.
    You can build a new version using my SlackBuild but currently it is not high on my own priority list.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.