Let's do not freak out over the scary stories of the self-entitled Dictator from Cucumbers Country... ;)

First of all, F2FS is a Flash Filesystem, in the same bandwagon with UBIFS or YAFFS2, read: a thing for the flash memories used by (some) embedded devices for the operating system and data, i.e. the Android phones and boards. And those flash memories are physically mounted in those devices, not something plug-and-play.

So, the ability of your system to interact with a "prepared" F2FS partition is next to zero. ;)

Secondly, the CVE is about a privilege escalation method for local users.

I strive to bear attention to the words: local users.

For example, one could imagine (or invent) a Magic SDCARD, which give you a root access when it is physically inserted on system and mounted, as non-privileged user.

I strive to bear attention to the word: physically.

Because any security expert would consider that: when the hacker have physical access to a computer, it could be considered compromised from the starts.

The hack applicability?

Someone to hack your computer and steal or manipulate your data at job, when someone gives him another non-privileged user account, i.e. one of your colleagues.

Yet, I find hard to consider that a Company which need that level of confidentiality that other of your co-workers to not know and have access to your work data, to not have strong policies against hacking, a very skilled network administration and physically prepared computers against hacking or unauthorized access.

Also, in this case, would be rather stupid for them to even give a chance to you (or others) to plug even an USB memory stick in the computer.

I.e. most likely any of USB or flash memory plugs would be physically disabled. 100%

@Darth Vader it's ok to not agree with other people but can we at least handle it in a polite manner.

@Nille_kungen OK, my bad! So, I changed my post according, after all: Cucumberistan -> Cucumbers Country

Two vulnerabilities in gdk-pixbuf:

CVE-2017-2862 (https://nvd.nist.gov/vuln/detail/CVE-2017-2862)
CVE-2017-2870 (https://nvd.nist.gov/vuln/detail/CVE-2017-2870)

These have been fixed in gdk-pixbuf 2.36.7. I've posted more details at http://security.cucumberlinux.com/se...ails.php?id=10 and http://security.cucumberlinux.com/se...ails.php?id=11.

A race condition in the Linux kernel allowing for local privilege escalation:

CVE-2017-12146 (https://nvd.nist.gov/vuln/detail/CVE-2017-12146)

Fixed in Linux 4.4.77.

perl 5.22.2 and CVE-2016-1238
 

Does Perl 5.22.4 correct CVE-2016-1238?
Perl 5.22.4 was released in July 2017.
I defer to the Perl experts.

I'm no Perl expert, but I have done some research and it appears that the answer is yes. Here is what I have found (quoted from http://security.cucumberlinux.com/se...ails.php?id=16):

Can anyone confirm or deny this?

Should be fixed in 5.22.4. See also https://security-tracker.debian.org/.../CVE-2016-1238

Well, that was a grisly read. https://rt.perl.org/Public/Bug/Display.html?id=127834

libxml2-2.9.5 was released with security fixes
 

libxml2-2.9.5 was released on 4 September with security fixes:
http://xmlsoft.org/news.html

Security:
Detect infinite recursion in parameter entities (Nick Wellnhofer),
Fix handling of parameter-entity references (Nick Wellnhofer),
Disallow namespace nodes in XPointer ranges (Nick Wellnhofer),
Fix XPointer paths beginning with range-to (Nick Wellnhofer)

Version 2.9.4 in Slackware 14.2 has a number of CVE:
CVE-2016-5131 CVE-2016-9318 CVE-2017-5969 CVE-2017-8872

libxslt 1.1.30 was released on 4 Sept.
 

libxslt-1.1.30 was released on 4 Sept.
http://xmlsoft.org/XSLT/news.html

Slackware 14.2 has libxslt-1.1.29.

http://cve.circl.lu/cve/CVE-2015-9019
CVE-2015-9019
In libxslt 1.1.29 and earlier, the EXSLT math.random function was not initialized with a random seed during startup, which could cause usage of this function to produce predictable outputs.

It appears that this vulnerability has still not been fixed in libxslt 1.1.30. The patch claiming to fix it is available at https://bug758400.bugzilla-attachmen....cgi?id=349240 . I just checked in the official 1.1.30 source code, and it has not been applied there. No mention in the 1.1.30 changelog of it either.

I've done some research on these CVEs:

CVE-2016-5131 - Fixed in 2.9.5
The patch fixing this ( https://git.gnome.org/browse/libxml2...3c5c2e9aaedd9e ) has been applied in 2.9.5.

CVE-2016-9318 - I don't believe it to be fixed
The upstream developers have restricted all information on this bug, leaving us in the dark and forcing us to turn to third parties. Debian (https://security-tracker.debian.org/.../CVE-2016-9318) claims this has been fixed by the patch https://git.gnome.org/browse/libxml2...326aeef6f0e0d0 , which has not been applied in 2.9.5.

CVE-2017-5969 - Fixed in 2.9.5
The bugzilla page (https://bugzilla.gnome.org/show_bug.cgi?id=778519) claims this was fixed by https://git.gnome.org/browse/libxml2...b4bb92fe7fe882 . This patch has been applied in 2.9.5.

CVE-2017-8872 - Not sure
I can't find much information on this one. All I could find was a bugzilla page (https://bugzilla.gnome.org/show_bug.cgi?id=775200) which proved to be inconclusive.

I wish the upstream Gnome developers would be more transparent about these vulnerabilities and disclose more information about them. Really, all it would take is adding a couple of lines to the changelog stating which CVEs they have fixed. But no. Instead they force us distro maintainers to go digging around for information.

Hi,

How are we about BlueBorne?

--
Best regards,
Andrzej Telszewski

Mitigated against remote code execution since Slackware 13.1, due to CONFIG_CC_STACKPROTECTOR=y in the kernel configs, but a remotely triggered crash is still possible. Waiting on proper upstream fixes.