Understanding the Ubuntu Pro cve scan results

Ubuntu Support Template

Ubuntu version 26.04

Desktop Environment GNOME

Problem Description:

I have a subscription to Ubuntu Pro on my Ubuntu 26.04 desktop. A ‘pro status’ enquiry shows ‘esm-apps’, ‘esm-infra’ and ‘livepatch’ all enabled. I have also run a software update. When I run a ‘pro cves’ scan several things puzzle me. First, 11 vulnerabilities show up marked as critical and 6 of these occur in 12 different packages.

For example:

linux-headers-7.0.0-27-generic              critical    -       CVE-2026-31608
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-43501
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-45988
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-46043
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-46135
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-52955
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-52989
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-52993
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-53002
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-53215
linux-headers-7.0.0-27-generic              critical    -       CVE-2026-53260

When I run ‘pro fix CVE-2026-XXXXX’ on each vulnerability I get a result saying all except for the last 2 of them are fixed (or at least that’s how I interpret the message).

For example:

CVE-2026-31608: Linux kernel vulnerabilities
 - https://ubuntu.com/security/CVE-2026-31608

1 affected source package is installed: linux
(1/1) linux:
A fix is available in Ubuntu standard updates.
The update is already installed.

✔ CVE-2026-31608 is resolved.

The message for the remaining 2 vulnerabilities (CVE-2026-53215 and -53260) says an update is coming tomorrow.

After a reboot the pro cves scan results are exactly the same.

Another thing, why is there no information under the ‘Origin’ column? Does my machine have a CVE problem or not?

Cheers,

Malcolm

Question also asked at https://askubuntu.com/questions/1568763/i-am-having-a-problem-understanding-the-results-of-an-ubuntu-pro-cves-scan

I suggest you [re-read] our Support and Help posting guide, esp. rule 14

2 Likes

Your report indicates that you are not using the latest kernel

Kernel 7.0.0-28 arrived in June 2026 for Ubuntu 26.04

uname -a
Linux gmktec 7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 x86_64 GNU/Linux

Little edit:-
The date may be release date rather than install date - not sure?
Nevertheless, the kernel arrived in late June or during July 2026 via normal upgrade

sudo apt update
sudo apt upgrade

Or

sudo apt full-upgrade

N.B. This will automatically remove old or obsolete packages and install new ones to properly resolve complex software dependencies)

Unfortunately, this does not really answer the original question - why pro cves shows CVEs that has already been fixed and does not show available updates origin.

Consider:

bor@bor-Standard-PC-Q35-ICH9-2009:~$ pro cves | grep '^xxd'
xxd                                         medium      updates   CVE-2026-59856
xxd                                         medium      updates   CVE-2026-59857
xxd                                         medium      updates   CVE-2026-59858
bor@bor-Standard-PC-Q35-ICH9-2009:~$ pro cve CVE-2026-59858
name:            CVE-2026-59858
public-url:      https://ubuntu.com/security/CVE-2026-59858
published-at:    2026-07-10
cve-cache-date:  2026-07-31
apt-cache-date:  2026-08-01
priority:        medium
cvss-score:      8.4
cvss-severity:   high
description: |
  Vim is an open source, command line text editor. Prior to 9.2.0735, the C
  omni-completion script in runtime/autoload/ccomplete.vim interpolates the
  typeref: or typename: extension field of a tags entry, without escaping, into
  a :vimgrep pattern that is run through :execute. Because :vimgrep honors the
  bar as a command separator, a crafted tag field can close the search pattern
  and append an arbitrary Ex command; opening a hostile .c file whose project
  tags file contains such an entry and invoking C omni-completion runs that
  command as the editing user. This issue is fixed in version 9.2.0735.
affected_packages:
  vim:          fixed  (updates)  2:9.1.2141-1ubuntu4.7
  vim-common:   fixed  (updates)  2:9.1.2141-1ubuntu4.7
  vim-runtime:  fixed  (updates)  2:9.1.2141-1ubuntu4.7
  vim-tiny:     fixed  (updates)  2:9.1.2141-1ubuntu4.7
  xxd:          fixed  (updates)  2:9.1.2141-1ubuntu4.7
related_usns:
  USN-8541-1: Vim vulnerabilities
bor@bor-Standard-PC-Q35-ICH9-2009:~$ apt policy xxd
xxd:
  Installed: 2:9.1.2141-1ubuntu4.6
  Candidate: 2:9.1.2141-1ubuntu4.7
  Version table:
     2:9.1.2141-1ubuntu4.7 500
        500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
 *** 2:9.1.2141-1ubuntu4.6 100
        100 /var/lib/dpkg/status
     2:9.1.2141-1ubuntu4 500
        500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages
bor@bor-Standard-PC-Q35-ICH9-2009:~$ 

Here it is as it should be. There are vulnerabilities in the installed package version, these vulnerabilities are fixed in the updated version, pro cves shows the origin from where these updates can be downloaded (standard updates). We can confirm with apt policy that updated packages are indeed available.

None of this information is shown for the kernel. You say

Well, taking as example CVE-2026-31608 - according to the above page it is fixed in the 7.0.0-27.27 and the version 7.0.0-27.27 is installed, so why this CVE is even listed as affecting the system? The CVE-2026-52989 is fixed in the 7.0.0-28.28 which is available for update:

bor@bor-Standard-PC-Q35-ICH9-2009:~$ apt policy linux-tools-common
linux-tools-common:
  Installed: 7.0.0-27.27
  Candidate: 7.0.0-28.28
  Version table:
     7.0.0-28.28 500
        500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
 *** 7.0.0-27.27 500
        500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
        100 /var/lib/dpkg/status
     7.0.0-22.22 500
        500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
     7.0.0-15.15 500
        500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
     7.0.0-14.14 500
        500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages
bor@bor-Standard-PC-Q35-ICH9-2009:~$ 

so, why pro cves does not show updates origin as available fix?

If we said: “No problem” you would not believe us. Would you?

Would you believe that the process is more complicated for Linux kernels than it is for applying security patches to other FOSS applications?

Where is the origin of the fix? From the Canonical kernel team that applied the patch to the Linux kernel in its repositories? Or, is it the Linux kernel team that merged the patch from Canonical or some other distribution and then released an updated Linux kernel? Or, perhaps the patch (fix) was worked out by the Linux developers themselves.

Will you agree that the process of determining “origin” is more complicated? This is where you and I disagree:

You see these things as important. I do not. I am assured & re-assured that Linux/Ubuntu is not only a useful computer operating system but a secure operating system with methods in place to record Common Vulnerabilities and Exposures (CVE) but also methods to apply the fixes in a reasonable time frame.

Please, read what Origin column in the pro cves output means.

1 Like

@malcolmk

I personally like the overview of the patch state with Ubuntu OVAL data and OpenSCAP.

1 Like

To support the observation - we have transparency:
https://ubuntu.com/security/notices

-hard work working hard-

1 Like

Sorry about that guiverc. I should have read the guidelines more carefully.

1 Like

First of all, thanks for all the responses. I’m a complete newcomer to linux so it’s a steep learning curve.

In response to your post tea-for-one, I did run ‘sudo apt update && sudo apt upgrade’ before running the ‘pro cves’ command. Being new to linux and a bit paranoid anyway I run the upgrade command every day after booting up the machine.

After looking at the post from avb66 I ran the ‘apt policy linux-tools-common’ command and got the following output:

~$ apt policy linux-tools-common
linux-tools-common:
Installed: 7.0.0-28.28
Candidate: 7.0.0-28.28
Version table:
*** 7.0.0-28.28 500
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main i386 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main i386 Packages
100 /var/lib/dpkg/status
7.0.0-27.27 500
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main i386 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main i386 Packages
7.0.0-22.22 500
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main i386 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main i386 Packages
7.0.0-15.15 500
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
500 http://au.archive.ubuntu.com/ubuntu resolute-updates/main i386 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main amd64 Packages
500 http://security.ubuntu.com/ubuntu resolute-security/main i386 Packages
7.0.0-14.14 500
500 http://au.archive.ubuntu.com/ubuntu resolute/main amd64 Packages
500 http://au.archive.ubuntu.com/ubuntu resolute/main i386 Packages

I’m assuming this is telling me that the latest kernel is installed.

Also, the post from avb66 showed a ‘pro cves’ command output which had information in the ‘origin’ column whereas mine didn’t.

I still don’t understand why, if the updates to most of the CVEs have been installed (see my first post), why ‘pro cves’ is still flagging all these critical vulnerabilities even after running the update command and rebooting the machine.

To find installed kernels, try this:-

ls /boot | grep vmlinuz-

To find which kernel is in use

uname -a

My terminal output only has 3 columns - origin is also missing
Possibly normal behaviour?

I just ran pro cves and received an output of 9998 lines inc low, medium, high and critical.
40 are critical

critical list
linux-tools-7.0.0-27                        critical    -         CVE-2026-31608
linux-tools-7.0.0-27                        critical    -         CVE-2026-43501
linux-tools-7.0.0-27                        critical    -         CVE-2026-45988
linux-tools-7.0.0-27                        critical    -         CVE-2026-46043
linux-tools-7.0.0-27                        critical    -         CVE-2026-46135
linux-tools-7.0.0-27                        critical    -         CVE-2026-52955
linux-tools-7.0.0-27                        critical    -         CVE-2026-52989
linux-tools-7.0.0-27                        critical    -         CVE-2026-52993
linux-tools-7.0.0-27                        critical    -         CVE-2026-53002
linux-tools-7.0.0-27                        critical    -         CVE-2026-53215
linux-tools-7.0.0-27                        critical    -         CVE-2026-53260
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-31608
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-43501
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-45988
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-46043
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-46135
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-52955
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-52989
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-52993
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-53002
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-53215
linux-tools-7.0.0-27-generic                critical    -         CVE-2026-53260
linux-tools-7.0.0-28                        critical    -         CVE-2026-52955
linux-tools-7.0.0-28                        critical    -         CVE-2026-52989
linux-tools-7.0.0-28                        critical    -         CVE-2026-52993
linux-tools-7.0.0-28                        critical    -         CVE-2026-53002
linux-tools-7.0.0-28                        critical    -         CVE-2026-53215
linux-tools-7.0.0-28                        critical    -         CVE-2026-53260
linux-tools-7.0.0-28-generic                critical    -         CVE-2026-52955
linux-tools-7.0.0-28-generic                critical    -         CVE-2026-52989
linux-tools-7.0.0-28-generic                critical    -         CVE-2026-52993
linux-tools-7.0.0-28-generic                critical    -         CVE-2026-53002
linux-tools-7.0.0-28-generic                critical    -         CVE-2026-53215
linux-tools-7.0.0-28-generic                critical    -         CVE-2026-53260
linux-tools-common                          critical    -         CVE-2026-52955
linux-tools-common                          critical    -         CVE-2026-52989
linux-tools-common                          critical    -         CVE-2026-52993
linux-tools-common                          critical    -         CVE-2026-53002
linux-tools-common                          critical    -         CVE-2026-53215
linux-tools-common                          critical    -         CVE-2026-53260

I don’t worry about this for various reasons

  • I couldn’t fix any of these critical issues, even if I knew what they all mean
  • I trust the kernel developers and Canonical kernel team to diligently keep Ubuntu secure
  • Security upgrades are run as soon as available, other package upgrades updated regularly

Commercial Ubuntu users and website owners undoubtedly have to be more aware of critical security issues.
As a home user, I rely on Ubuntu/Canonical to deal efficiently with system security.

1 Like

Please show us the complete output of

sudo apt update
sudo apt upgrade

Also, be aware that you shouldn’t need to run those commands manually every day. Your system, by default, will check twice daily already…including typically right after a boot. You won’t hurt anything by doing it manually. It’s just a habit most folks haven’t needed for about 15 years.

  • Tip: use ls -lah /var/lib/apt/periodic/ to see when the last update/upgrade, whether manual or automatic, last ran.
1 Like

On my Ubuntu Resolute fresh installed last month and with kernel 7.0.0-28 after update+full-upgrade command

pro cves --unfixable

gives a list of 23681 CVE. Should I be worried? On my Ubuntu 26.10 the command is accepted also if I don’t have UbuntuPro (obviously) and the list is empty. Does “pro cves” command work also if UbuntuPro is not installed? Thanks.

Package                                     Priority    Origin  Vulnerability
accountsservice                             medium      -       CVE-2026-16743
acl                                         medium      -       CVE-2026-54369
acl                                         medium      -       CVE-2026-54370
amd64-microcode                             medium      -       CVE-2024-21953
amd64-microcode                             medium      -       CVE-2024-36347
amd64-microcode                             medium      -       CVE-2025-0031
amd64-microcode                             medium      -       CVE-2025-0033
amd64-microcode                             medium      -       CVE-2025-29939
amd64-microcode                             medium      -       CVE-2025-29946
amd64-microcode                             medium      -       CVE-2025-29948
amd64-microcode                             medium      -       CVE-2025-29952
amd64-microcode                             medium      -       CVE-2025-48509
amd64-microcode                             medium      -       CVE-2025-48514
amd64-microcode                             medium      -       CVE-2025-48517
amd64-microcode                             medium      -       CVE-2025-52536
amd64-microcode                             low         -       CVE-2023-20585
avahi-daemon                                medium      -       CVE-2025-59529
bind9-dnsutils                              medium      -       CVE-2026-10723
bind9-dnsutils                              medium      -       CVE-2026-10822
bind9-dnsutils                              medium      -       CVE-2026-11331
bind9-dnsutils                              medium      -       CVE-2026-11622
bind9-dnsutils                              medium      -       CVE-2026-11721
bind9-dnsutils                              medium      -       CVE-2026-12617
bind9-dnsutils                              medium      -       CVE-2026-13204
bind9-dnsutils                              medium      -       CVE-2026-13321
bind9-host                                  medium      -       CVE-2026-10723
bind9-host                                  medium      -       CVE-2026-10822
.....

The pro is the Ubuntu Pro client tool and I think it is always installed by default. It seems to do the right thing with Pro subscription activated for all packages except kernel related.

I am afraid that with the current rate of CVE submitted by AI this metric became quite useless.

1 Like

Note that under pro only high and critical CVEs are guaranteed to be fixed, so it isn’t a surprise that you see so many unfixed medium and low ones (these are best effort only)

4 Likes

The output of the update - upgrade command is:

$ sudo apt update && sudo apt upgrade
[sudo: authenticate] Password:
Hit:1 http://au.archive.ubuntu.com/ubuntu resolute InRelease
Hit:2 http://au.archive.ubuntu.com/ubuntu resolute-updates InRelease
Hit:3 http://au.archive.ubuntu.com/ubuntu resolute-backports InRelease
Hit:4 Index of /ubuntu resolute-security InRelease
Get:5 https://packages.cisofy.com/community/lynis/deb stable InRelease [11.5 kB]
Get:6 Index of /apps/ubuntu/ resolute-apps-security InRelease [8,356 B]
Get:7 Index of /apps/ubuntu/ resolute-apps-updates InRelease [8,226 B]
Hit:8 Index of /rockowitz/ddcutil/ubuntu resolute InRelease
Get:9 Index of /infra/ubuntu/ resolute-infra-security InRelease [8,220 B]
Get:10 Index of /infra/ubuntu/ resolute-infra-updates InRelease [8,219 B]
Fetched 44.5 kB in 2s (18.7 kB/s)
All packages are up to date.
Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

The kernel is use is:

7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 x86_64 GNU/Linux

The update - upgrade history is:

$ ls -lah /var/lib/apt/periodic/
total 8.0K
drwxr-xr-x 2 root root 4.0K Jun 28 17:21 .
drwxr-xr-x 5 root root 4.0K Aug 3 12:53 ..
-rw-r–r-- 1 root root 0 Aug 3 12:41 download-upgradeable-stamp
-rw-r–r-- 1 root root 0 Aug 4 12:27 unattended-upgrades-stamp
-rw-r–r-- 1 root root 0 Aug 3 12:41 update-stamp
-rw-r–r-- 1 root root 0 Aug 4 13:25 update-success-stamp
-rw-r–r-- 1 root root 0 Aug 4 12:27 upgrade-stamp

In response to the post from ‘mylinde’ I used OpenSCAP to evaluate the Ubuntu OVAL data and it gave my machine a clean bill of health, so that’s reassuring.

1 Like

Now you have demonstrated that your machine really is up to date (#1 way to solve most problems) and is using only a pair of curious, unusual sources (#1 cause of most problems).

Did your Pro output change when your system updated to the new kernel?
If so, that seems an indication that your system is working properly.

And has your original question been answered?

1 Like

What is the pair of curious, unusual sources?

The system updated to a new kernel this morning:

$ ls -lah /var/lib/apt/periodic/
total 8.0K
drwxr-xr-x 2 root root 4.0K Jun 28 17:21 .
drwxr-xr-x 5 root root 4.0K Aug 5 09:37 ..
-rw-r–r-- 1 root root 0 Aug 3 12:41 download-upgradeable-stamp
-rw-r–r-- 1 root root 0 Aug 5 09:44 unattended-upgrades-stamp
-rw-r–r-- 1 root root 0 Aug 3 12:41 update-stamp
-rw-r–r-- 1 root root 0 Aug 5 15:13 update-success-stamp
-rw-r–r-- 1 root root 0 Aug 5 09:44 upgrade-stamp

7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 GNU/Linux

I ran ‘pro cves’:

linux-headers-7.0.0-28 critical - CVE-2026-52955
linux-headers-7.0.0-28 critical - CVE-2026-52989
linux-headers-7.0.0-28 critical - CVE-2026-52993
linux-headers-7.0.0-28 critical - CVE-2026-53002
linux-headers-7.0.0-28 critical - CVE-2026-53215
linux-headers-7.0.0-28 critical - CVE-2026-53260

linux-headers-7.0.0-28-generic critical - CVE-2026-52955
linux-headers-7.0.0-28-generic critical - CVE-2026-52989
linux-headers-7.0.0-28-generic critical - CVE-2026-52993
linux-headers-7.0.0-28-generic critical - CVE-2026-53002
linux-headers-7.0.0-28-generic critical - CVE-2026-53215
linux-headers-7.0.0-28-generic critical - CVE-2026-53260

linux-headers-7.0.0-29 critical - CVE-2026-53215
linux-headers-7.0.0-29 critical - CVE-2026-53260

linux-headers-7.0.0-29-generic critical - CVE-2026-53215
linux-headers-7.0.0-29-generic critical - CVE-2026-53260

linux-libc-dev critical - CVE-2026-53215
linux-libc-dev critical - CVE-2026-53260

linux-modules-7.0.0-28-generic critical - CVE-2026-52955
linux-modules-7.0.0-28-generic critical - CVE-2026-52989
linux-modules-7.0.0-28-generic critical - CVE-2026-52993
linux-modules-7.0.0-28-generic critical - CVE-2026-53002
linux-modules-7.0.0-28-generic critical - CVE-2026-53215
linux-modules-7.0.0-28-generic critical - CVE-2026-53260

linux-modules-7.0.0-29-generic critical - CVE-2026-53215
linux-modules-7.0.0-29-generic critical - CVE-2026-53260

linux-perf critical - CVE-2026-53215
linux-perf critical - CVE-2026-53260

linux-tools-7.0.0-28 critical - CVE-2026-52955
linux-tools-7.0.0-28 critical - CVE-2026-52989
linux-tools-7.0.0-28 critical - CVE-2026-52993
linux-tools-7.0.0-28 critical - CVE-2026-53002
linux-tools-7.0.0-28 critical - CVE-2026-53215
linux-tools-7.0.0-28 critical - CVE-2026-53260

linux-tools-7.0.0-28-generic critical - CVE-2026-52955
linux-tools-7.0.0-28-generic critical - CVE-2026-52989
linux-tools-7.0.0-28-generic critical - CVE-2026-52993
linux-tools-7.0.0-28-generic critical - CVE-2026-53002
linux-tools-7.0.0-28-generic critical - CVE-2026-53215
linux-tools-7.0.0-28-generic critical - CVE-2026-53260

linux-tools-7.0.0-29 critical - CVE-2026-53215
linux-tools-7.0.0-29 critical - CVE-2026-53260

linux-tools-7.0.0-29-generic critical - CVE-2026-53215
linux-tools-7.0.0-29-generic critical - CVE-2026-53260

linux-tools-common critical - CVE-2026-53215
linux-tools-common critical - CVE-2026-53260

Running fix command on one of them:

$ pro fix CVE-2026-53215
CVE-2026-53215:
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: refill RX buffers before XDP or skb use
The RX error path returns the current descriptor buffer to the hardware
BM pool. That is only valid while the driver still owns the buffer.
mvpp2_rx_refill() can fail after the current buffer has been handed to
XDP or attached to an skb. In those cases mvpp2_run_xdp() may have
recycled, redirected, or queued the page for XDP_TX, and an skb free also
retires the data buffer. Returning such a buffer to BM lets hardware DMA
into memory that is no longer owned by the RX ring.
Refill the BM pool before handing the current buffer to XDP or to the
skb. If the allocation fails there, drop the packet and return the
still-owned current buffer to BM, preserving the pool depth. Once the
refill succeeds, later local drops retire/free the current buffer instead
of returning it to BM.

1 affected source package is installed: linux
(1/1) linux:
A fix is coming soon. Try again tomorrow.

1 package is still affected: linux
✘ CVE-2026-53215 is not resolved.

Reminder: pro cve and pro fix are power-user tools for enterprise-level admins for whom auditing CVEs and mitigations is part of their daily job.

  • A Security Team evaluation of ‘critical’ does not mean that any special action is needed by you. Ubuntu has been automatically pushing security updates to all users for about 15 years.

That safe-and-secure-by-default philosophy is one reason lots of new users choose Ubuntu.


Your two currently-active non-Ubuntu sources are listed in your apt update output:

Get:5 https://packages.cisofy.com/community/lynis/deb stable InRelease [11.5 kB]
Hit:8 Index of /rockowitz/ddcutil/ubuntu resolute InRelease

Now let’s look at your pro cves output:

You have 6 CVEs (multiple packages each) for the older -28 kernel. You are seeing that because the older kernel is still installed. This is normal behavior. Nothing is wrong.

  • You can have multiple kernels installed (on a properly-functioning Ubuntu system, you should have at least two kernels installed).
  • Default settings retain at least one older kernel so a broken update or hardware incompatibility doesn’t brick your system – you can always boot the last working kernel.

You have 2 CVEs on the currently-running -29 kernel.

  • CVEs track vulnerabilities, regardless of whether a fix or patch is yet available or not.
  • The fact that Pro lists the CVE means that the Ubuntu Security Team is aware of the vulnerability. That it’s listed as ‘critical’ means it’s a priority for them. Soon they will release fixes for them. That’s why your attempt to pro fix failed – there was no patch yet.

Note that using Pro or using Pro tools will make zero difference in this case. As a supported release of Ubuntu, ALL Ubuntu users will get the patched kernel packages when released by the Security Team. 100% automatically. That’s what Unattended Upgrades, enabled by default, does twice each day in the background.

  • Desktop users may see the “need to reboot soon” icon.
  • Server admins may see the “need to reboot” message when they ssh into the server.
  • Pro Livepatch users might not see a “need to reboot” message for obvious reasons.
1 Like

According to the CVE-2026-52955 | Ubuntu, this CVE is fixed in the -28 kernel. Why is it listed?