During a local security check performed by nessus on a Linux Mint Qiana 17 LTS system, even if the host is perfectly updated, I have found 34 vulnerabilities about the kernel.

For example:
USN-2946-1 ( CVE-2015-8812, CVE-2016-2085, CVE-2016-2550, CVE-2016-2847 )
USN-3018-1 ( CVE-2016-4482, CVE-2016-4565, CVE-2016-4569, CVE-2016-4578, CVE-2016-4580, CVE-2016-4913, CVE-2016-4997, CVE-2016-4998 )
USN-2359-1 ( CVE-2014-3601, CVE-2014-5077, CVE-2014-5471, CVE-2014-5472 )

All these vulnerabilities belong to the current installed kernel version: linux-image-3.13.0-24-generic_3.13.0-24.47

Linux mint is based on Ubuntu 14.04 LTS. But Ubuntu 14.04 LTS seems to use linux-image-3.13.0-96-generic.
I know that Ubuntu backport security patch, so the kernel version main number stay unchanged but the vulnerabilities are fixed.
If I'm correct when you have a vulnerability publicly exposed about linux-kernel 3.X.Y, linux make a version 3.X.Z and Ubuntu put the patch in the version 3.X.Y-1 (right?).
So If you are using linux kernel 3.13.0-24 but the last version is 3.13.0-96, you are missing all the security patches made by Canonical.

I have seen that linux-kernel 3.13.0-24 is officially the version supported by Qiana: http://mirror.metrocast.net/linuxmint-packages/list.php?release=Qiana

Qiana (linux mint 17) is a LTS version, so the security patches shall be pushed in the kernel.

My question is not about how to get a secure kernel, I know that I can use linux mint 17.1, 17.2, 18, etc. My question is about "how a LTS mint version can use a known vulnerable version of linux kernel"?

I guess possible answers are:
1. you're wrong the kernel version 3.13.0-24 is not vulnerable
2. Mint backports patches in the kernel without updating the last number (the 'Z' in 3.X.Y-Z)
3. Yes mint use an older version of the kernel without the last security patches backported by Ubuntu so Qiana 17 LTS is full of kernel vuln

Note that nessus was not ready to perform specific Mint local security check, but it detected that the OS is Ubuntu based and make its checks knowing that:

The output of "uname -a" is :
Linux Tony-PC 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The remote Debian system is :

This is a Ubuntu system

Local security checks have been enabled for this host.

We can see that the date of build make some fear. And I have checked all the parameters is the system update: depository list is correct, apt-get update is good, apt-get upgrade is good, apt-get dist-upgrade is good too.

  • Just to make sure: you are keeping your Quiana Mint up to date (apt-get update, etc) and you are running the latest kernel in /boot. i.e. file /boot/vmlinuz* does not have a more up to date kernel than what uname -a reports. Yup?
    – grochmal
    Commented Sep 20, 2016 at 21:27
  • Yes I confirm that aptitude is up to date. I don't know if there are others kernel in /boot but I really don't think so. As I said, this image is the official one reported on the mint website
    – Sibwara
    Commented Sep 20, 2016 at 21:33
  • As root file /boot/vmlinuz* should give you the version of the kernel file. Yet, if the machine has a short uptime (say, a couple of hours) then it should be using the latest kernel. In other words, when you update the kernel the OS will not automatically switch to it, you need a reboot or an explicit kexec. I do not have any Mint Quiana, so I cannot check myself, sorry.
    – grochmal
    Commented Sep 20, 2016 at 21:39
  • The system is halted every day. I cannot access to the machine anymore. But I have checked all the things that could block the kernel update and I m pretty sure that I have the last version pushed by mint qiana 17
    – Sibwara
    Commented Sep 20, 2016 at 22:00

3 Answers 3


Linux Mint disables security updates to some components (including the kernel) by default. You may want to enable them and re-try.

Read this for background:


  • 1
    It is an answer alright. But links die, making a summary here would be a much better answer.
    – grochmal
    Commented Sep 28, 2016 at 2:09

Linux Mint founder and lead developer Clement Lefebvre responded to these accusations with a blog post on segfault.linuxmint.com in 2013.

I hear [Oliver Grawert, a Canonical-employed Ubuntu developer] was more opinionated than knowledgeable and the press blew what he said out of proportion. I wouldn’t mind too much, if we weren’t finding ourselves answering questions from panicked users rather than working on what matters right now (i.e. Mint 16 RC).

So I’ll be brief.

About package updates:

We explained in 2007 what the shortcomings were with the way Ubuntu recommends their users to blindly apply all available updates. We explained the problems associated with regressions and we implemented a solution we’re very happy with. Anybody running Mint can launch Update Manager -> Edit -> Preferences and enable level 4 and 5 updates, thus making their Linux Mint as “Secure” and “Unstable” as Ubuntu.

HowToGeek.com summarizes the argument this way in their blog:

Linux Mint’s primary argument is that “blindly” updating packages like the X.org graphical server, bootloader, and Linux kernel can cause problems. Updates to these low-level packages can introduce bugs on some types of hardware, while the security problems they solve aren’t actually a problem for people who use Linux Mint casually at home.


The real disagreement here is a philosophical one. Ubuntu errs on the side of updating everything by default, eliminating all possible security vulnerabilities — even ones that are unlikely to be exploited on home user systems. Linux Mint errs on the side of excluding updates that could potentially cause problems.


Patching known vulnerabilities can introduce instabilities. Mint favors stability, Ubuntu favors security. Personally if feel this demonstrates why something as key as your OS should be backed up by a dedicated team pushing patches quickly while trying to maintain system stability.

  • This isn't exactly an answer to the question, but it isn't bad either. If you could elaborate more, e.g. using Debian's stable vs. security repositories, it would be a good answer. (What you argue is exactly the difference between debian stable and debian security repositories)
    – grochmal
    Commented Sep 28, 2016 at 23:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .